الصور هي في الغالب أثقل العناصر على أي صفحة ويب. صورة رئيسية واحدة غير محسّنة قد تكون أكبر حجمًا من جميع ملفات JavaScript وCSS مجتمعةً. إذا كنت قد أتقنت كتابة الكود لكن صفحاتك لا تزال بطيئة، فالصور هي المشكلة على الأرجح — والتحويل إلى صيغ ضغط حديثة هو من أكثر التغييرات تأثيرًا التي يمكنك إجراؤها.
في هذا المقال، نشرح كيف يعمل كل من WebP وAVIF، وكيف يُقارنان بالصيغ القديمة مثل JPEG وPNG، وكيف تطبّقهما فعليًا دون أن تُسبّب مشاكل للمتصفحات القديمة.
لماذا تؤثر صيغة الصورة في تحسين وقت تحميل الصفحة؟
حين يحمّل المتصفح صفحةً ما، يُنزّل كل صورة بطلب HTTP منفصل. كلّما كانت الملفات أثقل، احتاجت الصفحة وقتًا أطول لتُعرض. هذا يؤثر مباشرةً على نتيجة Largest Contentful Paint (LCP) — وهو أحد مؤشرات Core Web Vitals لدى Google — لأن LCP يستهدف في الغالب صورةً كبيرة.
الحسابات بسيطة: صورة JPEG حجمها 400KB إذا حوّلتها إلى WebP ستتقلّص عادةً إلى 150–200KB. بنفس الجودة. دون أي فرق يراه العين البشرية. هذا يعني توفيرًا يتجاوز 50% من البيانات التي يجب على المتصفح تنزيلها قبل أن يعرض المحتوى.
تحسين وقت تحميل الصفحة ليس مجرد مسألة تجربة مستخدم. Google تستخدم سرعة الصفحة كإشارة ترتيب. الصفحات الأسرع ترتبط مباشرةً بمعدلات ارتداد أقل، وتحويلات أعلى، ومراكز أفضل في نتائج البحث. تخفيف حجم الصور هو من التحسينات النادرة التي تُحقق فوائد في المجالات الثلاثة في آنٍ واحد.
JPEG وPNG: لماذا أصبحا متجاوزَين؟
صُمّم JPEG عام 1992، وجاء PNG عام 1996. كلاهما كان حلًّا رائعًا في وقته، لكن تقنيات الضغط تطوّرت تطورًا هائلًا منذ ذلك الحين.
يعتمد JPEG على الضغط مع فقدان البيانات (lossy compression)، أي أنه يحذف بعض بيانات الصورة لتقليل الحجم. المشكلة أن خوارزمية الضغط المستخدمة غير فعّالة بالمعايير الحديثة — إذ تُنتج تشويهات واضحة عند مستويات الضغط العالية، لذا يجب التحفّظ في استخدامها للحفاظ على الجودة. أما PNG فيستخدم الضغط بدون فقدان (lossless) ويتعامل جيدًا مع الشفافية، لكن أحجام ملفاته أكبر من اللازم في الصور الفوتوغرافية.
لم تُصمَّم أيٌّ من الصيغتين مع مراعاة الشاشات عالية الكثافة اليوم، أو عروض العرض الكبيرة، أو مستخدمي الموبايل الحساسين لاستهلاك الإنترنت.
WebP: الحل العملي المتوازن
قدّمت Google صيغة WebP عام 2010، وباتت مدعومةً من جميع المتصفحات الرئيسية — بما فيها Safari منذ الإصدار 14. تدعم الضغط بنوعيه lossy وlossless، إضافةً إلى الشفافية (خلافًا لـ JPEG) والصور المتحركة (خلافًا لـ JPEG وPNG).
بكم تكون ملفات WebP أصغر؟
تُظهر معايير Google الخاصة أن صور WebP المضغوطة بأسلوب lossy أصغر بنسبة 25–34% تقريبًا من ملفات JPEG المقابلة. أما WebP بأسلوب lossless فهي أصغر بنسبة 26% من PNG المكافئة. النتائج الفعلية تتفاوت، لكن حتى في أدنى التقديرات، التوفير يكون كبيرًا على نطاق واسع.
إذا كانت صفحتك الرئيسية تحتوي على 10 صور منتجات بمتوسط 300KB لكل منها بصيغة JPEG، فالتحويل إلى WebP قد يُقلّص هذا الحجم الإجمالي من 3MB إلى حوالي 2MB. على اتصال موبايل، هذا الفارق هو الحدّ الفاصل بين بقاء المستخدم ومغادرته.
متى تستخدم WebP؟
- صور المنتجات والصور الرئيسية (بديلًا عن JPEG)
- لقطات الشاشة ورسومات الواجهة التي تحتاج شفافية (بديلًا عن PNG)
- البانرات المتحركة (بديلًا عن GIF — ملفات WebP المتحركة أصغر بكثير)
- أي صورة حيث يكون دعم المتصفحات الأوسع أهم من الضغط الأقصى
AVIF: الخطوة التالية
صيغة AVIF (AV1 Image File Format) أحدث وأكثر كفاءةً. تعتمد على ترميز الفيديو AV1 وتوفر ضغطًا أفضل بشكل ملحوظ من WebP — عادةً أصغر بـ 50% من JPEG وأصغر بـ 20% من WebP مع جودة بصرية مماثلة.
المقايضة هي وقت التشفير. إنشاء ملفات AVIF يستغرق وقتًا أطول من WebP أو JPEG، وهذا يهمّ إذا كنت تُشفّر كميات كبيرة من الصور أثناء التشغيل. لكن للمواقع الثابتة أو pipelines معالجة الصور المُسبقة، هذا نادرًا ما يكون مشكلة.
دعم المتصفحات لـ AVIF
AVIF مدعوم في Chrome وFirefox وEdge وSafari 16 فأعلى. لا يحظى بعد بالتغطية الشاملة التي تتمتع بها WebP، ولهذا فالنهج الموصى به هو تقديم AVIF أولًا، ثم WebP كخيار بديل، وأخيرًا JPEG/PNG كملاذ أخير. التفاصيل في قسم التطبيق أدناه.
متى تتألق AVIF؟
- التصوير الفوتوغرافي عالي الدقة حيث تظهر جودة الضغط بوضوح
- الصور ذات التدرجات المعقدة أو التفاصيل الدقيقة
- المواقع التي تستهدف مستخدمين على اتصالات موبايل محدودة النطاق الترددي
- أي سياق تقوم فيه بتوليد الصور مسبقًا وتخزينها في cache
كيف تطبّق كلا الصيغتين دون أن تُعطّل المتصفحات القديمة
عنصر HTML <picture> هو أفضل أداة لديك هنا. يتيح للمتصفحات اختيار أفضل صيغة تدعمها دون الحاجة لأي JavaScript.
<picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" alt="Hero image" width="1200" height="600"> </picture>المتصفحات تقرأ عناصر <source> بالترتيب. إذا كان يدعم AVIF، يأخذها. إن لم يدعمها، يجرّب WebP. إذا لم تنجح أيٌّ منهما، يعود إلى وسم <img>. صفر JavaScript، صفر صور معطّلة، وأقصى قدر من التوافق.
احرص دائمًا على تضمين خاصيّتَي width وheight في وسم <img>. هذا يتيح للمتصفح حجز المساحة قبل تحميل الصورة، مما يمنع اهتزاز التخطيط ويُحسّن مباشرةً نتيجة Cumulative Layout Shift (CLS).
تحسين وقت تحميل الصفحة: سير عمل التشفير
تحتاج إلى طريقة لتحويل صورك الحالية. إليك الخيارات الرئيسية:
أدوات سطر الأوامر
للمعالجة الجماعية، cwebp (من Google) وavifenc سريعتان وقابلتان للأتمتة:
# تحويل JPEG إلى WebP cwebp -q 80 input.jpg -o output.webp # تحويل JPEG إلى AVIF avifenc --min 20 --max 40 input.jpg output.avifأدوات البناء وخدمات CDN
- Sharp (Node.js) — سريعة وقابلة للبرمجة، تتعامل مع تحويل WebP وAVIF في CI pipelines
- Squoosh CLI — ممتازة للمعالجة الجماعية مع تحكم دقيق في الجودة
- Cloudflare Images / Imgix / Cloudinary — تُقدّم الصيغة المناسبة تلقائيًا بناءً على headers القبول في المتصفح، دون أي تحويل يدوي
- WordPress — إضافات مثل Imagify وShortPixel وEWWW Image Optimizer تُحوّل الصور المرفوعة تلقائيًا إلى WebP أو AVIF
التقديم من cache
بمجرد أن تكون صورك بالصيغ الصحيحة، تأكد من تخزينها في cache بصورة مكثّفة. الصور لا تتغير كثيرًا، لذا فإن مدد cache الطويلة — 30 يومًا أو أكثر — تعني أن الزوار العائدين يُحمّلونها فورًا من cache المحلي دون طلبات جديدة. إذا كان stack الاستضافة لديك يعالج الطلبات عبر طبقة cache، فإن ردود الصور المخزّنة تتجاوز الخادم الأصلي كليًّا، مما يُقلّل كلًّا من الكُمون وحمل الخادم.
أخطاء شائعة يجب تجنّبها
تغيير الصيغة وحده لن يحلّ كل شيء. خطأ شائع هو تحويل الصور إلى WebP مع الإبقاء على تقديمها بأبعاد خاطئة. صورة عرضها 3000px يتم تصغيرها بـ CSS لا تزال صورة بعرض 3000px يتم تنزيلها. استخدم خاصية srcset لتقديم صور بأحجام مناسبة عند نقاط توقف مختلفة:
<img srcset="image-480w.webp 480w, image-800w.webp 800w, image-1200w.webp 1200w" sizes="(max-width: 600px) 480px, (max-width: 1000px) 800px, 1200px" src="image-1200w.jpg" alt="Responsive image" width="1200" height="800" >أيضًا: لا تضغط صورًا سبق ضغطها. تحويل ملف JPEG إلى AVIF بعد حفظه بجودة 60% لن يُستعيد ما فُقد أصلًا. اعمل دائمًا من أعلى جودة أصلية متاحة لديك.
قياس التأثير
قبل أي عمل على تحسين الصور وبعده، قِس النتائج بأدوات حقيقية:
- Google PageSpeed Insights — يُشير مباشرةً إلى الصور غير المحسّنة ويُقدّر التوفير المحتمل
- WebPageTest — يعرض مخططات waterfall لترى بالضبط أي الصور تُعيق تحسين وقت تحميل الصفحة
- Chrome DevTools Network tab — فلتر حسب نوع الصورة لرؤية الأحجام وترتيب التحميل
- Lighthouse — مراجعة "Serve images in next-gen formats" تُخبرك بالضبط أي الصور يجب تحويلها
هدف واقعي: إذا كان Lighthouse يُشير إلى صور تحتاج تحسين وقت تحميل الصفحة، استهدف تقليل الحجم الإجمالي لصورك بنسبة 40–50% على الأقل من خلال تحويل الصيغة وحده، قبل أن تتناول أي شيء آخر. معظم المواقع تستطيع تحقيق ذلك دون أي خسارة ملحوظة في الجودة.
خلاصة القول
التحوّل من JPEG وPNG إلى WebP وAVIF هو من أكثر تحسينات وقت تحميل الصفحة فعاليةً — ولا يستلزم أي تغييرات على خادمك أو كودك أو تصميمك. عنصر <picture> يتعامل مع التوافق مع الإصدارات القديمة تلقائيًا، وأدوات تحويل الصور مجانية وقابلة للأتمتة، والتوفير في حجم الملفات حقيقي وفوري.
ابدأ بأثقل صورك — البانرات الرئيسية، وصور المنتجات، وصور المعارض — ثم نزّل بالتسلسل. استخدم Lighthouse لتحديد الأولويات. قِس قبل وبعد. النتائج تتكلم عن نفسها.
