المستوى: مبتدئ — ما تحتاجش تعرف غير إنك بتتعامل مع صور على موقعك وعندك صلاحية تعدّل ملف NGINX أو إعدادات السيرفر.

WebP للمبتدئ: وفّر 60% من حجم صور موقعك في 5 دقائق

لو الصفحة الرئيسية فيها 12 صورة JPEG بمتوسط 400KB للصورة، الزائر بيحمّل 4.8MB كل زيارة. تحويل نفس الصور لـ WebP بينزّل المجموع لـ 1.9MB، يعني وفّرت 60% bandwidth بسطرين أمر و 3 سطور NGINX، من غير ما القارئ يحس فرق في الجودة.

المشكلة باختصار

الصور بتمثّل في المتوسط 50% من حجم أي صفحة ويب حديثة، حسب تقرير HTTP Archive Web Almanac 2024. لو لسه بتخدم JPEG و PNG بس، إنت بتحمّل الزائر بيانات أكثر بـ 25 إلى 35% من اللي محتاجه فعلاً، وده بيظهر مباشرة في زمن التحميل على شبكات 3G و 4G، وفي فاتورة الـ CDN آخر الشهر.

الفكرة بمثال بسيط: شنطة السفر

تخيل إنك بتسافر ومعاك 10 قمصان. لو حطيت كل قميص متفرد في الشنطة هيشغّل مساحة كبيرة. لو طويتهم بطريقة منظّمة هتاخد نص المساحة من غير ما تتخلّى عن أي قميص. WebP هو الطريقة المنظّمة دي للصور: نفس الصورة، نفس البيكسلات اللي عينك بتشوفها، بس متخزّنة بشكل أذكى.

الفرق إن JPEG بيتبع طريقة طي قديمة من 1992، و WebP بيستخدم خوارزميات حديثة من 2010 طوّرتها Google بناءً على ضغط الفيديو في codec اسمه VP8.

التعريف العلمي

WebP هو صيغة صور طوّرتها Google في 2010 ونشرتها كمعيار مفتوح. بتعتمد على نفس تقنيات ضغط الـ keyframes في codec VP8، وبتدعم نوعين من الضغط:

• Lossy: ضغط مع فقدان بسيط للبيانات. بيوفّر 25–34% أصغر من JPEG على نفس مستوى الجودة المرئية، حسب القياسات الرسمية لـ Google على عيّنة 1 مليون صورة.
• Lossless: ضغط بدون فقدان. بيوفّر 26% أصغر من PNG في المتوسط.
• Animation: بيدعم صور متحركة بحجم أصغر من GIF بنسبة 64% في معظم الحالات.

كل المتصفحات الحديثة بتدعمه: Chrome من 2014، Firefox من 2019، Safari من iOS 14 (سبتمبر 2020). نسبة الدعم العالمية الآن أكثر من 96% حسب Can I Use.

الخطوة 1: تحويل صورة واحدة

أداة cwebp هي الأداة الرسمية من Google. ثبّتها على Ubuntu بأمر واحد:

sudo apt install webp
cwebp -q 80 photo.jpg -o photo.webp

الرقم 80 هو مستوى الجودة من 0 لـ 100. القيمة 80 هي التوصية الرسمية لـ Google للصور على الويب: فرق الجودة عن الأصل غير محسوس بالعين، والحجم أصغر بـ 30% في المتوسط مقارنة بـ JPEG عند نفس مستوى الجودة المرئية.

الخطوة 2: تحويل مجلد كامل دفعة واحدة

لو عندك 200 صورة في مجلد images/، السطر ده بيحوّلهم كلهم:

for f in images/*.jpg; do
  cwebp -q 80 "$f" -o "${f%.jpg}.webp"
done

على لاب توب متوسط، 200 صورة JPEG بمتوسط 500KB بتاخد حوالي 45 ثانية للتحويل. الناتج هيكون كل صورة JPEG جنبها نسخة WebP بنفس الاسم.

الخطوة 3: خدمة WebP من NGINX مع fallback لـ JPEG

المشكلة إن مش كل المتصفحات بتدعم WebP بنسبة 100%. الحل إن السيرفر يبعت WebP لو المتصفح بيدعمه، و JPEG لو لأ. NGINX بيعمل ده بـ 6 سطور:

map $http_accept $webp_suffix {
  default   "";
  "~*webp"  ".webp";
}

location ~* \.(jpg|jpeg|png)$ {
  add_header Vary Accept;
  try_files $uri$webp_suffix $uri =404;
}

اللي بيحصل: المتصفح بيبعت في الـ request header شيء اسمه Accept فيه قائمة الصيغ اللي بيدعمها. لو فيه image/webp، NGINX بيدوّر على نسخة WebP من الصورة، ولو لاقاها بيبعتها. لو الزائر فاتح من Safari قديم على iOS 13 مثلاً، NGINX بيرجع لـ JPEG العادي تلقائيًا.

الأرقام الفعلية من قياسات حقيقية

قياسات منشورة من Google على صفحات تجارية حقيقية:

• Etsy: صفحة منتج بـ 12 صورة، الحجم نزل من 4.2MB لـ 1.7MB (وفّروا 59%).
• Tinder: تطبيق الويب وفّر 31% من إجمالي الـ bandwidth الشهري بعد التحويل.
• Cloudinary benchmark: على عيّنة 5000 صورة JPEG عند جودة 80، WebP وفّر 30% في المتوسط، و AVIF وفّر 50% (لكن AVIF أبطأ في الـ encoding بـ 10x).

على شبكة 4G متوسطة في القاهرة (سرعة 12 Mbps)، صفحة بـ 4MB بتاخد 2.7 ثانية في التحميل. نفس الصفحة بـ 1.6MB بعد WebP بتاخد 1.1 ثانية. الفرق 1.6 ثانية بيقلّل نسبة الـ bounce بحوالي 11% حسب دراسة Google عن Core Web Vitals.

الـ Trade-offs اللي لازم تعرفها

1. زيادة في مساحة التخزين

هتحتفظ بنسختين من كل صورة: JPEG و WebP. لو عندك 50,000 صورة بمتوسط 400KB، ده 20GB إضافي من التخزين. على AWS S3 ده بيكلف حوالي 0.46 دولار شهريًا - رخيص جدًا، لكن لازم تكون عارف.

2. زمن المعالجة الأولي

تحويل الصور القديمة بياخد وقت. 100,000 صورة بتاخد حوالي 6 ساعات على ماكينة 4-core. الحل: شغّلها في الخلفية ليلة الجمعة وخلاص.

3. صعوبة التعديل اليدوي

Photoshop بيدعم WebP من 2022 بس عبر plugin. لو الفريق بتاع التصميم بيتعامل مع الصور باستمرار، خلّيهم يصدّروا JPEG واتركوا التحويل لـ WebP لمرحلة الـ build التلقائية على السيرفر، مش يدوي.

4. مشاكل الكاش لو الإعداد غلط

لو نسيت header Vary: Accept، الـ CDN بياخد نسخة WebP أول مرة، وبعدين بيرجّعها لمتصفح قديم ميقدرش يفتحها. ده بيكسّر الموقع لشريحة من المستخدمين. السطر add_header Vary Accept; في الإعداد فوق بيمنع الكارثة دي.

متى لا تستخدم WebP

• الصور القابلة للتحميل من المستخدم: لو الموقع بيعرض زر "تحميل الصورة"، خلّيها JPEG. لأن لو المستخدم نزّل WebP، Photoshop القديم على ماكينته مش هيفتحها.
• صور صغيرة جدًا (أقل من 10KB): الفرق ضعيف وأحيانًا WebP بيطلع أكبر من JPEG لأن overhead الـ header.
• محرّرات احترافية تتطلب جودة كاملة: لو الموقع لشركة تصوير محترفة بتبيع الصور بدقتها الأصلية، استخدم PNG أو TIFF.
• SVG icons: SVG أفضل بكثير من WebP للأيقونات والرسوم اللي مش فوتوغرافية، لأنه vector وحجمه دايمًا أصغر.

الخطوة التالية

افتح صورة واحدة من موقعك دلوقتي، وحوّلها بأمر cwebp -q 80 image.jpg -o image.webp. قارن الحجمين بأمر ls -lh. لو الفرق أقل من 20%، جرّب جودة 75 بدل 80. لو طلع أكبر من 30%، انت كده جاهز تطبّقها على 200 صورة دفعة واحدة بالـ loop اللي فوق. بعد ما توصل للنتيجة دي، حطّ إعداد NGINX، اعمل reload، وافتح Network tab في DevTools علشان تتأكد إن الصور بترجع Content-Type: image/webp.

المصادر

• Google WebP official documentation: developers.google.com/speed/webp
• HTTP Archive Web Almanac 2024 - Media chapter
• Can I Use - WebP browser support data: caniuse.com/webp
• Cloudinary 2023 benchmark: "WebP vs AVIF vs JPEG quality comparison"
• Etsy engineering blog: "WebP at Etsy" (2018)
• Google Core Web Vitals study on bounce rate (2021)
• NGINX official docs: nginx.org/en/docs/http/ngx_http_map_module.html