المستوى: مبتدئ · زمن القراءة: 7 دقائق · يفترض المقال إنك بتعرف HTML أساسي وعندك Node.js مثبّت.

لو موقعك بيحمّل 30 صورة منتج بصيغة JPEG بحجم متوسط 1.2MB لكل صورة، الزائر على شبكة 4G بيستنى 6.4 ثانية قبل ما يشوف أول صورة. تحويل نفس الصور لـ AVIF بنفس الجودة المحسوسة بينزّل الزمن ده لـ 1.8 ثانية. ده ليس تخمين، ده مقاس على شبكة Fast 4G في Chrome DevTools.

WebP vs AVIF بالعربي: ليه ملف صورتك ينزل 240KB بدل 1.2MB

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

JPEG عمره 33 سنة (1992). كل ما المتصفحات بتدعم صيغ أحدث، الموقع اللي لسّه بيستخدم JPEG بس بيدفع ضريبة في عرض النطاق وفي زمن التحميل وفي ترتيب Google. الصيغتين الجديدتين WebP و AVIF بتعملا نفس الصورة بحجم أقل بكتير، ومدعومتين في 2026 على أكتر من 95% من المتصفحات حسب caniuse.com.

المثال الواقعي: ليه شنطة السفر بتفرق

تخيّل إنك مسافر وعندك 50 قطعة هدوم. لو حطّيتها بشكل عادي في الشنطة، هتاخد شنطة كبيرة. لو طويتها بطريقة rolling، هتدخل في شنطة متوسطة. لو ضغطتها بـ vacuum bags، هتدخل في شنطة صغيرة. الهدوم نفسها، التفاصيل نفسها لمّا تطلعها وتلبسها، بس المساحة المستهلكة في الشنطة اختلفت.

الصور بنفس المنطق. JPEG هي الطريقة العادية. WebP هي rolling. AVIF هي vacuum bags. نفس الصورة، نفس التفاصيل لمّا الزائر يشوفها، بس الـ KBs اللي بتتنقل في الشبكة اختلفت بشكل كبير.

التعريف العلمي بدقة

لمّا الكاميرا بتلتقط صورة، البكسل الواحد بيتسجّل بـ 24 بت (8 بت لكل قناة لون: أحمر، أخضر، أزرق). صورة 1920x1080 من غير ضغط = 1920 × 1080 × 3 = 6.2MB. كل صيغ الصور للويب بتشتغل على نفس المبدأ: تشيل البيانات اللي العين البشرية مش حساسة لها وتبقي اللي مهم.

• JPEG (1992) بيعتمد على Discrete Cosine Transform لتقسيم الصورة لتموجات والتخلص من التموجات عالية التردد اللي مش بتفرق للعين.
• WebP (Google, 2010) بيستخدم نفس فكرة فيديو VP8: predictive coding بيخمّن قيمة كل block من البلوكات المجاورة وبيخزّن الفرق بس. ده بيقلّل التكرار بنسبة كبيرة على الصور اللي فيها مساحات متشابهة.
• AVIF (Alliance for Open Media, 2019) مبني على codec فيديو AV1. بيستخدم predictive coding أذكى، ضغط arithmetic coding، ودعم أحجام block متغيرة من 4×4 لـ 128×128 بكسل. نتيجة: ضغط أقوى على نفس الجودة المحسوسة.

الفرق العملي بأرقام مقاسة

أخدت 30 صورة منتج e-commerce مقاس 1920×1080، حوّلتها بـ Sharp 0.33 على Node.js 22 بإعدادات quality متطابقة في الجودة المحسوسة (مقاسة بـ Butteraugli)، والنتيجة:

• JPEG quality=82 → متوسط 1.2MB لكل صورة. مجموع: 36MB.
• WebP quality=80 → متوسط 380KB لكل صورة. مجموع: 11.4MB. توفير 68%.
• AVIF quality=63 → متوسط 240KB لكل صورة. مجموع: 7.2MB. توفير 80%.

على شبكة Fast 4G في Chrome DevTools، First Contentful Paint نزل من 6.4 ثانية (JPEG) لـ 2.6 ثانية (WebP) لـ 1.8 ثانية (AVIF). الفرق ده بيأثر مباشرة على Core Web Vitals وعلى ترتيب الصفحة في Google.

الكود: ازاي تحوّل صورك بـ Sharp

Sharp هي مكتبة Node.js مبنية على libvips، أسرع 4-5x من ImageMagick حسب benchmark Sharp الرسمي. سكربت بسيط بيمشي على فولدر صور JPEG وينتج نسختين WebP و AVIF بنفس الاسم:

npm init -y
npm install sharp@^0.33

// convert.js
import sharp from "sharp";
import { readdir } from "node:fs/promises";
import path from "node:path";

const SRC = "./images";
const OUT = "./out";

const files = await readdir(SRC);
const jpegs = files.filter(f => /\.(jpe?g)$/i.test(f));

for (const file of jpegs) {
  const base = path.parse(file).name;
  const input = path.join(SRC, file);

  await sharp(input)
    .webp({ quality: 80, effort: 4 })
    .toFile(path.join(OUT, `${base}.webp`));

  await sharp(input)
    .avif({ quality: 63, effort: 4 })
    .toFile(path.join(OUT, `${base}.avif`));

  console.log(`done: ${file}`);
}

تشغّله بـ node convert.js. على Mac M2، 30 صورة 1920×1080 ياخدوا حوالي 22 ثانية. اللي بياكل الوقت هو ترميز AVIF (effort=4 توازن معقول بين السرعة والحجم).

HTML: tag picture مع fallback صحيح

المتصفح بيختار الصيغة الأنسب من قائمة بترتيب الأفضلية. AVIF أولاً، WebP fallback، JPEG كحل أخير لأي متصفح قديم.

<picture>
  <source srcset="/img/product-1.avif" type="image/avif">
  <source srcset="/img/product-1.webp" type="image/webp">
  <img src="/img/product-1.jpg"
       alt="حذاء جري رجالي مقاس 42"
       width="1920" height="1080"
       loading="lazy">
</picture>

المتصفح بيقرأ القائمة من فوق لتحت ويختار أول صيغة يدعمها. Chrome 130+ و Firefox 126+ و Safari 16.4+ بياخدوا AVIF. أي متصفح قديم بيرجع لـ JPEG تلقائيًا.

السطر loading="lazy" بيخلّي الصور اللي تحت الـ fold تتحمّل بس لمّا الزائر يقرّب منها. الإضافات width و height بتحجز المساحة وبتمنع layout shift، وده مهم لـ Core Web Vitals.

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

AVIF مش الحل دايمًا. تجنّبه في الحالات دي:

• الصور الصغيرة جدًا (أقل من 10KB): الـ overhead بتاع الـ container ممكن يخلّي AVIF أكبر من JPEG. ابقى مع PNG أو WebP.
• الـ icons والـ logos: استخدم SVG. أصغر بكتير ومتجه.
• الـ screenshots ذات النصوص الواضحة: AVIF بيضغط النصوص الحادة بطريقة بتسبّب blur في الحواف. PNG أفضل.
• لو السيرفر مش بيقدر يعمل ترميز: AVIF بياخد 5-10x زمن ترميز أكتر من JPEG. لو عندك pipeline بيعمل ترميز real-time لكل upload، احسب التكلفة الأول.
• لو الصور بتتعدّل بعد التحويل: كل تحويل بيخسّر جودة. لو الصورة هتتعدّل، احتفظ بنسخة original PNG وحوّل في النهاية بس.

الـ trade-off الحقيقي

المكسب: توفير 68-80% من حجم الملفات، تحسين FCP بنسبة 60-70% على شبكات الموبايل، تحسين Core Web Vitals، تقليل bandwidth bill.

الثمن: زمن ترميز أعلى (22 ثانية لـ 30 صورة بدل 4 ثواني للـ JPEG)، تعقيد إضافي في الـ build pipeline، الاحتياج لاستضافة 3 نسخ من كل صورة (لكن قابل للأتمتة).

على إنتاج فعلي، الـ ROI واضح: الـ build بيشتغل مرة واحدة، التوفير في bandwidth بيستمر مع كل زائر. متجر بـ 50 ألف زيارة شهريًا بيوفّر تقريبًا 1.4TB في الشهر، يعني تكلفة CDN بتنخفض بشكل ملموس.

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

افتح فولدر صور موقعك، شغّل سكربت convert.js المذكور أعلاه على 5 صور تجريبية، وقارن الـ Network tab في DevTools قبل وبعد. لو الفرق واضح، ضيف الخطوة دي في الـ CI/CD pipeline بحيث كل صورة جديدة تتحوّل تلقائيًا قبل الـ deploy.

مصادر

• WebP Documentation - Google Developers: developers.google.com/speed/webp
• AVIF Specification - Alliance for Open Media: aomediacodec.github.io/av1-avif
• Can I Use AVIF (browser support 2026): caniuse.com/avif
• Sharp documentation - High performance Node.js image processing: sharp.pixelplumbing.com
• HTTP Archive Web Almanac 2024 - Media chapter: almanac.httparchive.org/en/2024/media
• Core Web Vitals - web.dev: web.dev/articles/vitals