لماذا تحدّد الصور سرعة صفحتك
في معظم الصفحات، تمثّل الصور النصيب الأكبر من البايتات التي يحمّلها المتصفّح. وهذا يجعلها الهدف الأول لموقع أسرع — والسبب الرئيسي في رسوب صفحة في Core Web Vitals، لأن أكبر صورة غالبًا ما تكون عنصر LCP (أكبر عنصر محتوى مرئي) الذي يقيسه Google. وتحسين الصور لا يعني جودة أقل؛ بل يعني تقديم الصورة نفسها ببايتات أقل بكثير. اضبط هذا جيدًا فيتحسّن كل شيء آخر دفعةً واحدة — LCP، ودرجات الجوال، واستهلاك البيانات.
اضبط الحجم واجعلها متجاوبة
أشيع أنواع الهدر هو تقديم صورة ضخمة في مساحة صغيرة — فصورة بعرض 4000 بكسل تُعرض بعرض 800 بكسل تُحمَّل كاملةً بـ 4000 بكسل. صدّر الصور بحجم قريب من الحجم الذي تُعرض به فعلًا. ثم قدّم أحجامًا مختلفة لشاشات مختلفة باستخدام srcset وsizes، فيحصل الهاتف على ملف صغير ويحصل سطح المكتب على ملف أكبر.
صور متجاوبة باستخدام srcset
<img
src="/hero-800.jpg"
srcset="/hero-400.jpg 400w, /hero-800.jpg 800w, /hero-1600.jpg 1600w"
sizes="(max-width: 600px) 400px, 800px"
alt="Product hero"
width="800" height="500">انتقل إلى صيغ الجيل التالي: WebP وAVIF
ينتج WebP — وAVIF حيثما كان مدعومًا — ملفات أصغر بنسبة 25-50% من JPEG أو PNG بالجودة البصرية نفسها. وهذا هو التغيير الذي يزيل توصية "قدّم الصور بصيغ الجيل التالي" في PageSpeed Insights. قدّمها باستخدام عنصر picture لتحصل عليها المتصفّحات الداعمة للصيغة الجديدة بينما تعود المتصفّحات الأقدم إلى الصورة الأصلية تلقائيًا.
قدّم AVIF/WebP مع بديل احتياطي
<picture>
<source srcset="/photo.avif" type="image/avif">
<source srcset="/photo.webp" type="image/webp">
<img src="/photo.jpg" alt="Photo" width="1200" height="800">
</picture>التحميل الكسول — لكن ليس لصورتك الرئيسية
يؤجّل التحميل الكسول الصورَ حتى توشك على دخول منطقة العرض، فلا تحمّل الصفحة الطويلة كل شيء مقدّمًا. وتفعل معظم المنصّات ذلك افتراضيًا. والاستثناء الوحيد هو صورتك الرئيسية أو صورة الغلاف، وهي عادةً عنصر LCP: حمّلها بشكل فوري (وفكّر في fetchpriority="high") ليُرسَم أهمّ بكسل بأسرع ما يمكن. استخدم التحميل الكسول لكل ما هو أسفل الطيّة، وأعطِ الأولوية للشيء الوحيد فوقها.
وصّل من الحافة — وحوّل تلقائيًا
حتى الصورة المضغوطة ضغطًا مثاليًا تكون بطيئة إذا قطعت المسافة من خادم بعيد. تخزّن شبكة CDN صورك عند الحافة وتخدم كل زائر من أقرب موقع، فتصل البايتات بسرعة أينما كانوا. يفعل cdn.com.tr ذلك لكل أصل، عبر HTTP/2 وBrotli الحديثين، مع SSL تلقائي أمامها.
ولست مضطرًا إلى تحويل الصيغ يدويًا. ففي WordPress، تنشئ إضافة CDNTR المجانية صور WebP (وAVIF حيثما يدعمها خادمك) على خادمك أنت وتقدّمها من الـ CDN عبر عنصر picture، مع الأصل كبديل احتياطي تلقائي. ولا تقدّم ملفًا محوّلًا إلا حين يكون أصغر فعلًا، فلا تُكبَّر صورة مضغوطة جيدًا أبدًا، ويمكنها تحويل مكتبة الوسائط كاملةً دفعةً واحدة.
قِس وتأكّد
مرّر صفحتك عبر PageSpeed Insights قبل التغيير وبعده. أنت تبحث عن أمرين: اختفاء توصيتَي "قدّم الصور بصيغ الجيل التالي" و"اضبط أحجام الصور بشكل صحيح"، وانخفاض مقياس LCP لديك. وإذا ظلّت أكبر صورة بطيئة، فتأكّد أنها ليست محمّلة تحميلًا كسولًا وأنها تُقدَّم بصيغة الجيل التالي من الـ CDN. مقارنة سريعة قبل/بعد تُبقيك صادقًا حيال ما ساعد فعلًا.
أين يؤتي أكبر ثماره
صفحات المنتجات مثقلة بالصور؛ فالصور الأصغر بصيغ الجيل التالي تُحمَّل أسرع وترفع معدلات التحويل.
صور المقالات الرئيسية والمعارض تهيمن على وزن الصفحة؛ وتحسينها يصلح LCP ودرجات الجوال.
تشعر الهواتف على الشبكات الأبطأ بكل كيلوبايت إضافي؛ والصور المضبوطة الحجم بصيغ الجيل التالي تساعد أكثر ما تساعد هناك.
الأسئلة الشائعة حول تحسين الصور
هل يقلّل WebP أو AVIF من جودة الصورة؟
لا. فبالجودة البصرية نفسها ينتجان ببساطة ملفًا أصغر. يضغط AVIF عادةً على نحو أفضل، وWebP قريب منه وأوسع دعمًا؛ ويتيح لك عنصر picture تقديم كليهما والعودة إلى الأصل للمتصفّحات القديمة.
هل عليّ تحويل كل صورة بنفسي؟
لا. ففي WordPress تحوّل إضافة CDNTR المجانية وتقدّم WebP/AVIF تلقائيًا، ويمكنها تحويل مكتبتك دفعةً واحدة. وفي الحزم التقنية الأخرى، يمكن لأدوات وقت البناء أو خطّ معالجة صور فعل الأمر نفسه؛ والمهمّ أن يستقبل الزوّار الصيغة الأصغر.
أيّهما أهمّ، الصيغة أم الحجم؟
كلاهما، لكن ضبط الحجم يأتي عادةً أولًا: فتقديم صورة بعرض 4000 بكسل في مكان بعرض 800 بكسل يهدر أكثر بكثير ممّا توفّره الصيغة أصلًا. اضبط الحجم، ثم حوّل إلى صيغة الجيل التالي، ثم وصّل من الـ CDN.