تحسين الصور في 2026: AVIF وWebP والتحميل البطيء

لا تزال الصور أثقل الأصول في معظم صفحات الويب. في مشاريعنا في DigiForge، نرى عادةً أن الصور تشكل جزءًا كبيرًا من الوزن الإجمالي للصفحة. بحلول عام 2026، استقر المشهد: AVIF و WebP هما التنسيقان الحديثان اللذان يجب استخدامهما، والصور المتجاوبة عبر srcset أصبحت أساسية، والتحميل البطيء أصبح معيارًا لدرجة أن تطبيقه بشكل خاطئ قد يضر بالأداء. تلخص هذه المقالة تجربتنا العملية في سير عمل واضح وقائم على الرأي يمكنك تطبيقه على أي مشروع.

اختيار التنسيق المناسب: AVIF مقابل WebP

لسنوات، كان WebP هو التنسيق الحديث المفضل. ظهر AVIF لاحقًا، واعدًا بضغط أفضل ودعم HDR، ولكن بتكلفة تشفير أعلى ودعم متصفح لا يزال غير شامل (كان Safari آخر المتخلفين). إليك الوضع الحالي في 2026:

• AVIF عادةً ما يوفر أحجام ملفات أصغر من WebP لنفس الجودة الإدراكية. يدعم الألوان 10 بت، HDR، الشفافية بدون فقدان، وحتى الرسوم المتحركة. التشفير أبطأ بكثير من WebP، مما يجعله أقل ملاءمة للتوليد في الوقت الفعلي ولكنه مناسب للأصول الثابتة التي تُخبز في وقت البناء.
• WebP مدعوم عالميًا في جميع المتصفحات الحديثة. يوفر جودة يمكن التنبؤ بها، تشفير سريع، وأدوات ممتازة (cwebp، sharp، imagemin). للمواقع الغنية بالمحتوى حيث سرعة التشفير مهمة، لا يزال WebP هو الخيار العملي الافتراضي.
• JPEG XL (JXL) أظهر وعدًا مبكرًا لكنه لم يكتسب زخمًا في المتصفحات. أزال Chromium علامته، ولم يطبقه Safari أبدًا. لا تضيع وقتك عليه حتى يتغير المشهد.

توصيتنا: قم بتقديم AVIF مع fallback إلى WebP. استخدم <picture> للسماح للمتصفحات باختيار AVIF أولاً، ثم WebP، ثم JPEG/PNG الأصلي. هذا يزيد الضغط لمن يمكنهم الحصول عليه مع عدم ترك أي شخص بدون صورة. معظم المتصفحات الحديثة تدعم AVIF، لذا فإن fallback مهم لكنه ليس المسار الأساسي.

<picture>
  <source srcset="image.avif" type="image/avif">
  <source srcset="image.webp" type="image/webp">
  <img src="image.jpg" alt="...">
</picture>

الأحجام المتجاوبة: ليس فقط srcset

السمة srcset مع sizes مفهومة جيدًا، لكن العديد من التطبيقات التي نراجعها تخطئ في استخدام sizes. يستخدم المتصفح sizes لتحديد أي مرشح من srcset سيقوم بتنزيله – إنها ليست مجرد اقتراح. إذا كانت sizes مفقودة، فالقيمة الافتراضية هي 100vw، مما يعني أن المتصفح قد يختار أكبر صورة حتى على شاشة صغيرة، مما يهدر عرض النطاق الترددي.

بالنسبة للصور المتجاوبة البسيطة حيث يتغير حجم الصورة مع منفذ العرض، اكتب:

<img src="image-800.jpg" 
     srcset="image-400.jpg 400w, image-800.jpg 800w, image-1200.jpg 1200w"
     sizes="(max-width: 600px) 100vw, (max-width: 1200px) 50vw, 33vw"
     alt="...">

لكن هناك تفاصيل دقيقة. يجب أن تعكس sizes العرض الفعلي للصورة في CSS عند كل نقطة توقف، وليس جزء الشاشة. بالنسبة لصورة رئيسية تكون دائمًا بعرض كامل، فإن sizes="100vw" صحيح. بالنسبة لمعرض حيث كل صورة تشغل ثلث الصف، استخدم 33vw. إذا كانت الصورة تحتوي على حشوة أو داخل حاوية ذات عرض أقصى، فستحتاج إلى حساب العرض الفعلي المعروض — أحيانًا يكون استخدام calc() في sizes ضروريًا.

مُعرّفات العرض مقابل كثافة البكسل

استخدم مُعرّفات w (مثل 400w) وsizes للصور المرنة التي يتغير حجم عرضها حسب التخطيط. مُعرّفات الكثافة (1x, 2x) مناسبة فقط للصور ذات الحجم الثابت مثل الشعارات أو الأيقونات حيث تعرف الأبعاد الفعلية بدقة. بالنسبة لصور المحتوى، استخدم دائمًا w – فهي تمنح المتصفح المرونة الحقيقية لاختيار أفضل مرشح بناءً على عرض الشاشة ونسبة بكسل الجهاز.

عند استخدام <picture> لاختيار التنسيق، يجب أن يحتوي كل <source> على srcset خاص به وsizes اختيارية. يمكنك مشاركة نفس sizes عبر المصادر إذا كان التخطيط متطابقًا، لكن تجنب تكرارها دون داعٍ.

التحميل البطيء: أصلي، مراقب التقاطع، أم كلاهما؟

التحميل البطيء الأصلي (loading="lazy") مدعوم في جميع المتصفحات الرئيسية منذ عام 2020. إنه بدون جافا سكريبت، ويعمل مع الصور والإطارات المضمنة، وهو أسهل مسار. لكن له خصائص غريبة تهم في الممارسة العملية:

• التحميل البطيء الأصلي يؤجل التحميل حتى يقرر المتصفح أن العنصر قريب من منفذ العرض. العتبة محددة من قبل المتصفح – كروم يستخدم هامشًا سخيًا لبدء التحميل مبكرًا؛ فايرفوكس يستخدم هامشًا أصغر. هذا يعني أن الصور قد تُحمَّل لاحقًا أكثر من المتوقع على فايرفوكس.
• لا يعمل بشكل مثالي مع srcset في بعض التطبيقات المبكرة. الإصدارات القديمة من سفاري (قبل 16.4) كانت بها أخطاء. في عام 2026، هذه نادرة ولكن لا يزال يستحق الاختبار.
• بالنسبة لعناصر <picture>، يجب وضع loading="lazy" على وسم <img>، وليس على وسوم <source>.

نحن نستخدم نهجًا هجينًا: التحميل البطيء الأصلي كأساس، بالإضافة إلى polyfill خفيف لـ Intersection Observer (IO) للمتصفحات القديمة (على الرغم من أن هذا بحلول عام 2026 حالة نادرة). يمكن لـ IO أيضًا تشغيل رسوم متحركة للتلاشي أو تحميل عناصر نائبة منخفضة الجودة. تطبيقنا:

const lazyImages = document.querySelectorAll('img[loading="lazy"]');

if ('loading' in HTMLImageElement.prototype) {
  // Native lazy loading works – do nothing extra
} else {
  const observer = new IntersectionObserver((entries) => {
    entries.forEach(entry => {
      if (entry.isIntersecting) {
        const img = entry.target;
        img.src = img.dataset.src;
        observer.unobserve(img);
      }
    });
  });
  lazyImages.forEach(img => observer.observe(img));
}

تجميع كل شيء معًا: سير عمل عملي

في DigiForge، نتبع هذا المسار لكل مشروع، سواء كان موقعًا ثابتًا، أو موقعًا يعتمد على نظام إدارة المحتوى، أو تطبيق ويب:

1. صور المصدر: يسلمها المصممون بصيغة PNG أو TIFF عالية الدقة. نحتفظ بالأصول في مجلد _originals لإعادة الضغط مستقبلًا إذا ظهرت صيغ جديدة.
2. توليد الصيغ: استخدم سكريبت Node.js مع sharp أو ملف Makefile مع ImageMagick لإنتاج صيغ AVIF وWebP وJPEG/PNG احتياطية بعرض 3-5 أحجام (مثل 480 و800 و1200 و1920). للمشاريع الكبيرة، نقوم بتشغيل هذا بالتوازي باستخدام worker threads لتسريع البناء.
3. ضبط الجودة: تشغيل فحوصات CI تقارن حجم الملف بمقياس إدراكي (SSIM أو Butteraugli). نرفض طلبات السحب إذا تجاوز الوزن الإجمالي للصور لصفحة نموذجية حدًا معقولًا بناءً على نوع المحتوى.
4. الترميز: توليد <picture> بترتيب type (AVIF، WebP، احتياطي) و<img> مع loading="lazy" (باستثناء الصورة الرئيسية الأولى). للأحجام المتجاوبة، نولد sizes بناءً على CSS الفعلي – وهذا غالبًا ما يأتي من ملف رموز التصميم المشترك بين التصميم والتطوير.
5. الخدمة من CDN: للمواقع الثابتة، نخدم الأصول المشفرة مسبقًا من CDN مع رؤوس تخزين مؤقت طويلة (مثل Cache-Control: public, max-age=31536000, immutable). إذا تم استخدام CDN صور مثل Cloudinary أو imgix، فإن العديد من الخطوات تتم آليًا عبر تحويلات URL، لكننا لا نزال نشفر الصور الحرجة مسبقًا لتجنب تكاليف البدء البارد.

مواقع مثل Unsplash [3] وPixabay [1] توفر صورًا عالية الدقة تزن غالبًا عدة ميغابايتات خام. مسارنا يقلصها بشكل كبير دون فقدان ملحوظ. وبالمثل، الصور المولدة بالذكاء الاصطناعي من أدوات مثل ChatGPT Images [4] غالبًا ما تخرج بدقة عالية دون تحسين، لذا فإن تشغيلها عبر نفس سير عمل الضغط أمر بالغ الأهمية. الصور المخزنة من Shutterstock [5] أو Bing Images [2] لها خصائص مماثلة – ملفات كبيرة يمكن أن تضر بالأداء إذا لم يتم تحسينها.

الأخطاء الشائعة التي نراها (ونصلحها)

• عدم تضمين sizes بالكامل: يقوم المتصفح بتنزيل أكبر مرشح srcset لأنه يفترض 100vw. احرص دائمًا على توفير sizes – حتى 100vw البسيطة أفضل من لا شيء.
• استخدام JPEG لكل شيء: لا تزال العديد من الفرق تقدم JPEG كصيغة وحيدة. بحلول عام 2026 لا يوجد عذر – WebP و AVIF ناضجان، والجهد المبذول لإضافتهما ضئيل.
• الإفراط في التحميل الكسول: كل صورة تحمل loading="lazy" تؤخر أول رسم ذي معنى. استخدم loading="eager" للصور الهامة، وفكر في التحميل المسبق للصورة الرئيسية باستخدام <link rel="preload" as="image" href="..."> لتحقيق أقصى سرعة LCP.
• عدم وجود خيار احتياطي للصيغ المتحركة: إذا كنت تستخدم AVIF متحركًا (الذي يتمتع بدعم غير مضمون)، فقدم خيارًا احتياطيًا بصيغة WebP أو GIF عبر <picture>.
• تشفير الصور أثناء الطلب في دوال serverless: تشفير AVIF يستهلك الكثير من وحدة المعالجة المركزية. قد يؤدي تدفق الطلبات إلى انتهاء المهلة أو ارتفاع التكاليف. احرص دائمًا على إنشاء الأصول مسبقًا أثناء البناء لأي شيء بخلاف الصور التي رفعها المستخدم والتي لا يمكن تحضيرها مسبقًا.

رأينا أيضًا فرقًا تعتمد على مصدر صورة واحد دون إصدارات. عندما يقوم المصمم بتحديث شريط رئيسي، يتم استبدال الملف القديم، مما يكسر ذاكرة التخزين المؤقت لشبكة CDN. استخدم تجزئات المحتوى في أسماء الملفات (مثل hero-a1b2c3.avif) بحيث تحصل الإصدارات الجديدة على عنوان URL جديد ويمكن تخزين القديمة إلى أجل غير مسمى.

توصيات الأدوات

للمطورين الذين يفضلون واجهة سطر الأوامر، cwebp (من libwebp) و avifenc (من libavif) أدوات صلبة وقابلة للبرمجة. لخطوط أنابيب Node.js، sharp لا يُضاهى – فهو سريع، ويتعامل مع جميع الصيغ، ويمكنه إخراج AVIF (يتطلب libvips مبنيًا بدعم AVIF). للمقارنات المخصصة، نستخدم Squoosh أو أدوات المقارنة مثل icdif (Image Compare Diff).

للمشاريع واسعة النطاق، فكر في استخدام شبكة توصيل محتوى صور مثل Cloudinary أو imgix أو Fastly’s Image Optimizer. تقوم هذه الأدوات بأتمتة تغيير الحجم والتفاوض على التنسيق عبر معلمات عنوان URL، وغالبًا ما تتعامل مع ترميز AVIF على طبقة التخزين المؤقت الخاصة بها، مما يوفر عليك تكلفة وحدة المعالجة المركزية على الخادم الأصلي. ومع ذلك، كن على دراية بمخاطر الاحتكار والتكلفة – فبالنسبة لموقع يحتوي على العديد من الصور، يمكن أن تكون الفاتورة الشهرية كبيرة. غالبًا ما نوصي بنظام هجين: قم بإنشاء الأحجام والتنسيقات الأكثر شيوعًا مسبقًا، واترك لشبكة CDN التعامل مع نقاط التوقف النادرة أو تحميلات المستخدمين.

إذا كنت تستخدم نظام إدارة محتوى أو مولد موقع ثابت، فهناك إضافات لمعظم الأطر (مثل @next/image لـ Next.js، و gatsby-plugin-sharp لـ Gatsby، و eleventy-img لـ Eleventy). تقوم هذه الإضافات بإنشاء الصور وترميزها تلقائيًا، لكننا نوصي بمراجعة إعدادات الجودة الافتراضية الخاصة بها – فهي تميل إلى أن تكون متحفظة (بدون فقدان أو شبه بدون فقدان) لتجنب الشكاوى، مما قد يهدر البايتات.

الخلاصة

تحسين الصور في عام 2026 يدور حول المفاضلات: AVIF يوفر أكبر عدد من البايتات لكنه يستهلك وحدة معالجة مركزية؛ WebP هو الوسط الموثوق. يجب أن تكون الأحجام المتجاوبة دقيقة، وليست تقريبية. التحميل البطيء أصبح شبه تلقائي، لكنه يحتاج إلى تطبيق مدروس لتجنب الإضرار بـ LCP. يمكن لخط أنابيب صور مضبوط جيدًا أن يقلل وزن الصفحة بشكل كبير – وهذا فوز مباشر لتجربة المستخدم، ومقاييس Core Web Vitals، ومعدلات التحويل.

لقد بنينا خطوط أنابيب لمواقع تخدم عشرات الملايين من الصور المحسّنة شهريًا. المبادئ هي نفسها بغض النظر عن الحجم: الترميز في وقت البناء، والتراجع بأمان، وتحديد الحجم بشكل متجاوب، والتحميل البطيء ولكن ليس الجشع. إذا كنت ترغب في تدقيق استراتيجية الصور الحالية لديك أو تحتاج إلى مساعدة في تنفيذ خط أنابيب، تواصل مع DigiForge – يمكننا عادةً تقليل وزن الصفحة بشكل كبير في المرة الأولى.