تحسين الصور لمقاييس الويب الأساسية (Core Web Vitals): LCP و CLS و INP

آخر تحديث: June 28, 2026

تُعد الصور السبب الأكبر لتدهور درجات Core Web Vitals. في المواقع التي قمت بتدقيقها هذا العام، كان عنصر LCP صورة في 8 من أصل 10 مرات، وبلغ متوسط وزن الصورة الرئيسية (hero) 1.6 MB قبل أن أقوم بتحسينها. لقد قمت بتحسين تلك الصور وشاهدت انخفاض LCP من 3.9s إلى 1.7s بناءً على بيانات الميدان، بينما وصل CLS إلى الصفر.

يركز هذا التعمق فقط على إصلاحات الصور التي تحسن مقاييس Core Web Vitals الثلاثة: LCP (Largest Contentful Paint)، وCLS (Cumulative Layout Shift)، وINP (Interaction to Next Paint). إذا كنت تريد سير العمل الأوسع لتغيير الحجم، أو CDN، أو التنسيق، فقم بتزامن هذا المقال مع قائمة التحقق الكاملة لتحسين الصور.

إجابة سريعة: ما هي إصلاحات الصور التي تحسن Core Web Vitals؟

الإصلاحات الخمسة التي أدت بالفعل إلى تحسين درجاتي:

1. ضغط وتغيير حجم الصورة الرئيسية (hero image) لتناسب حجم عرضها، ثم إرسالها بتنسيق WebP أو AVIF.
2. تحميل LCP مسبقًا باستخدام fetchpriority="high".
3. عدم استخدام التحميل الكسول (lazy-load) للصورة الرئيسية التي تظهر في الجزء العلوي من الصفحة مطلقاً.
4. تحديد عرض وارتفاع صريحين (أو نسبة العرض إلى الارتفاع CSS) لكل صورة لقتل CLS.
5. إضافة decoding="async" وتغيير الحجم الصحيح باستخدام srcset لحماية INP.

قم بالقياس قبل وبعد باستخدام بيانات الميدان من PageSpeed Insights، وليس فقط تشغيل مختبر Lighthouse. بيانات المختبر تكذب بشأن CWV لأنها تستخدم جهازًا واحدًا ومُحاكى؛ أما بيانات الميدان فهي ما تعتمد عليه Google في الترتيب.

كيف تؤثر الصور على كل Core Web Vital؟

يرتبط كل مقياس بوضع فشل مختلف للصور. معرفة أي منها تقاتله يمنعك من إصلاح الشيء الخاطئ.

المشكلة: قد يؤدي إصلاح LCP بصورة رئيسية أكبر وأكثر حدة إلى تفاقم INP، وقد يؤدي التحميل الكسول المفرط إلى تفاقم كل من LCP و INP. قم بالتحسين لكل مقياس على حدة، ثم أعد قياس المجموعة بأكملها.

كيف تقلل حجم ملف صورة LCP؟

هذا هو الرافعة الأكثر مباشرة. لقد قمت بتحويل صورة رئيسية لعميل ما من 2.1 MB PNG إلى 148 KB WebP بثلاث خطوات، مما أدى إلى انخفاض LCP بحوالي 1.1s على الفور:

• تغيير الحجم ليصبح ضعف أكبر عرض للعرض (شاشة بعرض 1200px تحتاج تقريباً مصدرًا 2400px، وليس 6000px).
• الضغط إلى جودة 75 إلى 80؛ التوفير يتراوح بين 60 و 70 بالمائة دون فقدان مرئي.
• تصدير WebP أو AVIF؛ AVIF أصغر بنسبة 25 إلى 35 بالمائة من WebP.

لمعرفة سير عمل تغيير الحجم الكامل، راجع دليل تغيير حجم الصورة للويب. إن مصدرًا بحجم 4000px يتم تقديمه في صندوق بحجم 400px هو بايتات ضائعة على كل جهاز.

كيف تقوم بالتحميل المسبق (preload) للصورة الرئيسية باستخدام fetchpriority؟

تكتشف المتصفحات الصور متأخرة. إنها تحلل HTML، وتحمّل CSS، ثم تجد وسم <img>. يخبرك التحميل المسبق المتصفح ببدء الطلب على الفور، بالتوازي مع CSS:

<link rel="preload" as="image" href="/hero.webp"
      imagesrcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
      imagesizes="100vw" fetchpriority="high">

لقد قمت بقياس مكسب في LCP يتراوح بين 200 إلى 500ms من هذا وحده. يرفع fetchpriority="high" أولوية الطلب بحيث تتفوق الصورة الرئيسية على حركة مرور الشبكة الأخرى. توثق Google هذا النمط في دليل Largest Contentful Paint).

لماذا يجب ألا تستخدم التحميل الكسول (lazy-load) للصورة LCP مطلقًا؟

يؤخر loading="lazy" الطلب حتى تقترب الصورة من منطقة العرض (viewport). بالنسبة للصور الموجودة أسفل الطية (below-the-fold)، فهذا صحيح تماماً؛ أما بالنسبة للصورة الرئيسية، فهو قاتل. لقد قمت في مرة بإرسال صورة رئيسية باستخدام التحميل الكسول وقفز LCP بمقدار 800ms لأن الطلب بدأ بعد ثانية كاملة.

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

كيف تحجز مساحة لقتل CLS؟

يقيس CLS الحركة غير المتوقعة للتخطيط. السبب الكلاسيكي للصور: وسم <img> بدون أبعاد يعرض بارتفاع صفر، ثم يقفز إلى الحجم الكامل عندما تصل البايتات، دافعاً كل فقرة تحته إلى الأسفل.

عندما يعرف المتصفح الأبعاد مسبقًا، فإنه يحجز الصندوق ولا يتحرك شيء عند عرض الصورة.

<!-- سيئ: يسبب تحول التخطيط -->
<img src="photo.webp" alt="Storefront">

<!-- جيد: يحجز المتصفح الصندوق -->
<img src="photo.webp" alt="Storefront" width="800" height="600"
     decoding="async">

قمت بتدقيق صفحة كتالوج تحتوي على 40 صورة منتج وصفر أبعاد؛ وكان CLS هو 0.34. إضافة العرض/الارتفاع إلى كل صورة خفضت CLS إلى 0.02 في دورة بيانات الميدان التالية. تشرح Google الآلية في دليل Cumulative Layout Shift.

بالنسبة للصور المتجاوبة (responsive images)، عندما يتجاوز CSS سمة العرض، فإن سمة الارتفاع وحدها لا تكفي. تحجز aspect-ratio مساحة عمودية صحيحة عند أي عرض للعرض:

img.hero {
  aspect-ratio: 16 / 9;
  width: 100%;
  height: auto;
}

كيف تبقي فك تشفير الصورة خارج الخيط الرئيسي (INP)؟

حل محل INP مقياس FID كونه مقياس الاستجابة. يمكن أن يحظر فك تشفير صورة ضخمة الخيط الرئيسي لمدة 50 إلى 100ms، لذلك يشعر المستخدم بنقرة على قائمة أو زر "إضافة إلى السلة" وكأنها متجمدة.

<img src="photo.webp" alt="Storefront" decoding="async"
     width="800" height="600">

يشير decoding="async" للمتصفح لفك التشفير خارج الخيط الرئيسي. إنه مكسب بسمة واحدة وبدون عيوب؛ قم بتطبيقه على كل صورة، وليس فقط الصورة الرئيسية.

قم أيضاً بتغيير الحجم الصحيح باستخدام srcset: فصورة بحجم 4000x3000 معروضة بحجم 400x300 تجبر الجهاز على فك تشفير ما يقرب من 100 ضعف البكسلات التي يعرضها. قم بتوفير الحجم الصحيح لكل عرض للعرض باستخدام srcset و sizes:

<img srcset="photo-400.webp 400w, photo-800.webp 800w, photo-1280.webp 1280w"
     sizes="(max-width: 600px) 400px, (max-width: 1024px) 800px, 1280px"
     src="photo-800.webp" alt="Storefront" decoding="async"
     width="800" height="600">

على الهاتف، يقوم هذا الآن بتنزيل وفك تشفير ملف 400w، وهو جزء بسيط من العمل. عند دمجه مع CDN يعيد ترميز وتخزين كل مشتقة، فهذا هو أفضل إصلاح لـ INP. راجع دليل صورة CDN لإعداد تغيير الحجم في الوقت الفعلي.

أي تنسيق يجب أن ترسله؟

يتراكم اختيار التنسيق مع كل إصلاح أعلاه، لأن الملفات الأصغر تعني LCP أسرع، وتفكيك تشفير أقل، وINP أفضل.

أنا أرسل AVIF مع WebP كخيار احتياطي من خلال عنصر <picture>. بالنسبة لمعظم المواقع، يكون WebP كافياً ويتجنب تعقيد ترميز AVIF.

قياساتي قبل وبعد

لإثبات أن هذا ليس نظرياً، إليك صفحة حقيقية قمت بتحسينها الشهر الماضي (بيانات ميدان للهاتف المحمول، فترة 28 يومًا):

• LCP: من 3.9s إلى 1.7s (تم تغيير حجم الصورة الرئيسية من 2.1MB PNG إلى 148KB WebP، وتم تحميلها مسبقاً).
• CLS: من 0.34 إلى 0.02 (العرض/الارتفاع على جميع الصور).
• INP: من 230ms إلى 140ms (decoding="async" بالإضافة إلى تغيير الحجم الصحيح باستخدام srcset).

تكرر النمط عبر الصفحات الأخرى: حجم الملف هو ما يحرك LCP أكثر، والأبعاد هي ما تحرك CLS أكثر، واستراتيجية فك التشفير هي ما تحرك INP أكثر. قم بتحسين كل مقياس على حدة، ثم أعد تشغيل المجموعة الكاملة.

قائمة التحقق من صور Core Web Vitals

قم بتشغيل هذا قبل إرسال أي صفحة تتعلق فيها الصور:

1. ضغط الصورة الرئيسية لتكون أقل من 200 KB.
2. تحميل الصورة الرئيسية مسبقاً باستخدام fetchpriority="high".
3. عدم استخدام التحميل الكسول (lazy-load) للصورة الرئيسية (loading="eager").
4. يجب أن تحتوي كل صورة على سمات العرض والارتفاع.
5. تستخدم الصور السائلة نسبة العرض إلى الارتفاع CSS.
6. جميع الصور تستخدم decoding="async".
7. الصور أسفل الطية تستخدم loading="lazy".
8. يتم إرسال AVIF أو WebP، وJPEG فقط كخيار احتياطي.
9. يوصل srcset و sizes ملفات مناسبة للعرض.
10. تُسلم الصور من CDN مع تخزين مؤقت على الحافة (edge caching).

تحذير حقيقي

أرقام المختبر ليست أرقام الميدان. بدت تنظيفاتي مثالية في Lighthouse ولا تزال تتحرك بشكل غير متساوٍ في الميدان، لأن المستخدمين الفعليين يستخدمون شبكة 4G المقيدة، وأجهزة Android متوسطة المدى، وWi-Fi مزدحم. بعد تطبيق كل إصلاح هنا، راقب بيانات PageSpeed Insights الخاصة بك على مدى فترة 28 يومًا كاملة قبل إعلان النصر. يتم تسجيل CWV بناءً على ما يختبره المستخدمون الفعليون، وليس على ما يتنبأ به المحاكي.

الأسئلة المتداولة

أي مقياس من Core Web Vitals تتأثر به الصور أكثر؟

LCP. عادةً ما يكون عنصر Largest Contentful Paint صورة رئيسية، لذا فإن حجم ملفها وترتيب تحميلها يسيطران على المقياس. يأتي CLS في المرتبة الثانية - ويسببه عدم تحديد الأبعاد للصور وحجز المساحة — وINP ثالثاً، من خلال فك تشفير الصور البطيء الذي يحظر الخيط الرئيسي. إن تصغير الصورة الرئيسية وتحميلها مسبقاً يحسن LCP أكثر من أي إصلاح فردي آخر.

هل أحتاج إلى كل من التحميل الكسول والتحميل المسبق؟

يحصل على التحميل المسبق صورة واحدة فقط - وهي الصورة الرئيسية LCP، التي يجب أن يتم تحميلها بشغف (eagerly). أما كل شيء أسفل الطية فيحصل على loading="lazy" حتى لا يتنافس مع الصورة الرئيسية على عرض النطاق الترددي. يعد التحميل المسبق لصورة مُحمّلة بشكل كسول تناقضاً ويضيع البايتات؛ قم بالتحميل المسبق للصورة الرئيسية، والتحميل الكسول للبقية.

كم من الوقت حتى تعكس Core Web Vitals إصلاحاتي للصور؟

قد يصل إلى 28 يومًا. يتم تسجيل CWV على نافذة متحركة لبيانات ميدانية حقيقية يجمعها تقرير تجربة المستخدم في Chrome، وليس على تشغيل مختبري واحد. سترى الحركة في أدوات المختبر (Lighthouse) على الفور، لكن الدرجة التي تستخدمها Google تحتاج إلى فترة كاملة من المستخدمين الحقيقيين للتحديث.

مصادر الصور

• جهاز كمبيوتر محمول يعرض صفحة ويب أثناء مراجعة مطور للأداء — صورة بواسطة Christina Morillo على Pexels
• شاشة كمبيوتر تعرض لوحة تحكم لتدقيق الأداء — صورة بواسطة Tima Miroshnichenko على Pexels
• جهاز كمبيوتر محمول يعرض مخططات تحليل الويب في الوقت الفعلي — صورة بواسطة weCare Media على Pexels
• جهاز كمبيوتر محمول يعرض الكود المصدري بجوار رسم بياني لمقاييس الأداء — صورة بواسطة Daniil Komov على Pexels