تقنيات تحسين الصور التي تُحدث فرقاً حقيقياً
تقنيات عملية لتحسين الصور وأداء الويب: الصيغ الحديثة مثل WebP، وضبط الأحجام المتجاوبة، والتحميل الكسول، ومنع انزياح التخطيط.

الصور عادةً هي أثقل عنصر في صفحة الويب. في موقع تسويقي نموذجي أو متجر إلكتروني، تستهلك الصور وحدها بايتات تحميل أكثر من حجم ملفات الـ HTML والـ CSS والـ JavaScript مجتمعةً. لذلك عندما تشعر الصفحة الرئيسية بالبطء على هاتف أندرويد متوسط الإمكانيات عبر اتصال محمول ضعيف في الرياض أو القاهرة، فالسبب نادراً ما يكون في الكود. السبب غالباً صورة رئيسية بحجم 2.4 ميجابايت صُدّرت مباشرةً من جهاز المصمم ووُضعت في الصفحة بدقتها الكاملة.
تحسين الصور هو أعلى أنواع العمل في web performance من حيث العائد مقابل الجهد، ومع ذلك معظم الفرق لا تصل إليه أبداً. لا يتطلب إعادة كتابة منصتك التقنية ولا توظيف فريق جديد. وإذا أُحسن تنفيذه، فإنه يقلّص وزن الصفحة بشكل كبير، ويحسّن مؤشرات Core Web Vitals، ويرفع المقاييس التي تهمك فعلاً: معدل الارتداد، ومعدلات التحويل، وترتيبك في نتائج البحث. فيما يلي التقنيات التي تُحدث فرقاً حقيقياً، مرتّبة تقريباً حسب حجم تأثيرها.
قدّم الصيغ الحديثة: WebP و AVIF
أكبر مكسب منفرد لمعظم المواقع هو تغيير صيغة الملف. اعتمد الويب على JPEG و PNG لعقدين، وكلتاهما باتت متجاوَزة اليوم.
- WebP ينتج عادةً ملفات أصغر بنسبة 25-35% من JPEG عند جودة بصرية مكافئة، ويدعم الشفافية (فيمكنه أن يحل محل PNG أيضاً). وهو مدعوم في كل المتصفحات التي تحتاج للاهتمام بها اليوم.
- AVIF يذهب أبعد من ذلك، فغالباً يكون أصغر بنسبة 50% من JPEG، مع معالجة أفضل للتدرجات اللونية والتفاصيل الدقيقة. دعم المتصفحات له قوي على الأجهزة الحديثة، مع شريحة أقدم محدودة.
ولست مضطراً للاختيار. يتيح عنصر <picture> للمتصفح أن يختار أفضل صيغة يدعمها مع تراجع سلس إلى البديل:
<picture>
<source srcset="hero.avif" type="image/avif">
<source srcset="hero.webp" type="image/webp">
<img src="hero.jpg" alt="فريق يراجع لوحة بيانات مشروع" width="1200" height="675">
</picture>
يجرّب المتصفح صيغة AVIF أولاً، ثم WebP، ثم JPEG كبديل شامل. الأجهزة القديمة تحصل على صورة تعمل، والبقية تحصل على نسخة أخفّ بكثير.
لا تنسَ مؤشر الجودة
الصيغة وحدها ليست القصة كاملة. تُصدَّر معظم الصور بإعدادات جودة أعلى بكثير مما تستطيع العين تمييزه. للمحتوى الفوتوغرافي، تكون صورة WebP أو AVIF بجودة 70-80 غالباً غير قابلة للتمييز عن الأصل، وبجزء بسيط من الحجم. اختبر على صور حقيقية وثِق بعينيك، لا بإعداد التصدير الافتراضي.
اضبط حجم الصور وفق طريقة عرضها الفعلية
قدر مذهل من النطاق الترددي المهدور ينشأ من تقديم صورة بعرض 4000 بكسل داخل مساحة تُعرض بعرض 600 بكسل. يُنزّل المتصفح كل بكسل، ثم يتخلص من معظمها.
أداتان تحلان هذه المشكلة:
srcsetوsizesتتيحان لك توفير عدة دقّات وإخبار المتصفح بالعرض الذي ستُعرض به الصورة، فيُنزّل الدقة المناسبة للجهاز ولحجم نافذة العرض.- نقاط التوقف المتجاوبة (responsive breakpoints) تعني أن الهاتف لن يُنزّل أبداً ملفاً بحجم سطح المكتب.
<img
src="product-800.webp"
srcset="product-400.webp 400w, product-800.webp 800w, product-1600.webp 1600w"
sizes="(max-width: 600px) 100vw, 50vw"
alt="سماعات لاسلكية باللون الأسود المطفي"
width="800" height="800">
الهاتف على اتصال بطيء يسحب نسخة 400 بكسل، وسطح المكتب بشاشة retina يحصل على النسخة الواضحة بدقة 1600 بكسل. لا أحد يدفع أكثر من حاجته.
التحميل الكسول (lazy loading): حمّل فقط ما يراه الناس
معظم الزوّار لا يصلون أبداً إلى أسفل الصفحة، ومع ذلك فالسلوك التقليدي للمتصفح هو تنزيل كل صورة مسبقاً. يؤجّل التحميل الكسول الصور خارج الشاشة حتى يوشك المستخدم على الوصول إليها، ما يسرّع العرض الأولي ويوفّر البيانات لمن يغادرون مبكراً.
والخبر الجيد أن lazy loading الأصلي أصبح الآن سمة من سطر واحد:
<img src="gallery-3.webp" alt="معرض المشروع" loading="lazy" width="600" height="400">
قاعدتان عمليتان:
- طبّق التحميل الكسول على الصور أسفل الطية — المعارض، والتذييلات، ومتون المقالات الطويلة، وشبكات المنتجات في أسفل الصفحة.
- لا تطبّق التحميل الكسول أبداً على الصورة الرئيسية أو صورة LCP. أكبر عنصر مرئي عند أول رسم للصفحة يجب أن يُحمّل في أبكر وقت ممكن. تأجيله يضرّ فعلياً بدرجة Largest Contentful Paint لديك. لتلك الصورة الحرجة، استخدم
fetchpriority="high"بدلاً من ذلك.
احجز المساحة وامنع انزياح التخطيط
التحميل السريع نصف التجربة فقط. فإذا ظهرت الصور فجأةً ودفعت النص جانباً أثناء تحميل الصفحة، شعر المستخدم أن الموقع معطوب حتى لو كان سريعاً. يُقاس هذا الاهتزاز بمؤشر Cumulative Layout Shift (CLS)، أحد مؤشرات Core Web Vitals من Google.
الحل بسيط وكثيراً ما يُغفل: حدّد دائماً سمتَي width و height صراحةً (أو خاصية aspect-ratio في الـ CSS) لكل صورة. هذا يتيح للمتصفح حجز المساحة الصحيحة قبل وصول الملف، فلا يقفز شيء. ستلاحظ أننا أدرجنا width و height في كل مثال أعلاه. هذا مقصود.
اجعله جزءاً من خط الإنتاج، لا بنداً في قائمة المهام
التحسين اليدوي ينجح مرة واحدة ثم يتآكل. ففي المرة التالية التي يرفع فيها أحد المسوّقين بانراً عبر الـ CMS، تعود من جديد إلى ملف PNG بحجم 3 ميجابايت. لا بد أن يكون التحسين تلقائياً.
- استخدم إطار عمل يتولى الأمر. يأتي Next.js بمكوّن Image يولّد الأحجام المتجاوبة والصيغ الحديثة والتحميل الكسول تلقائياً. ومعظم أطر العمل الحديثة لديها مكافئ له.
- ضع CDN أو خدمة صور في المقدمة. الأدوات التي تحوّل الصور لحظياً تتيح لك طلب الصيغة والحجم والجودة التي تحتاجها من ملف مصدر واحد، مع تخزين مؤقت عالمي قريب من مستخدميك في منطقة الخليج وخارجها.
- اضغط الملفات عند المصدر. مرّر الملفات المرفوعة عبر ضغط آلي (أدوات في خطوة البناء أو إضافة في الـ CMS) كي لا تصل الملفات غير المحسّنة إلى الإنتاج أبداً.
- حدّد ميزانية لوزن الصفحة وراقبها ضمن أدوات مراقبة الأداء لديك. فحص يفشّل عملية البناء عندما يتضخم حجم الصور أثمن من أي تنظيف لمرة واحدة.
بالنسبة للفرق التي تخدم عملاءها عبر السعودية والإمارات ومصر — حيث تأتي شريحة معتبرة من الزيارات عبر بيانات الهاتف المحمول — فهذا الانضباط ليس رفاهية. إنه الفرق بين موقع يُحمّل قبل أن يتشتت الانتباه وآخر لا يفعل.
أهم النقاط
- ابدأ بتغيير الصيغة. تقديم WebP و AVIF مع بديل JPEG عبر عنصر
<picture>هو أسرع تغيير وأعلاها أثراً يمكنك القيام به. - اضبط حجم كل صورة عبر
srcsetوsizesكي لا تُنزّل الأجهزة بكسلات أكثر مما تعرض. - طبّق التحميل الكسول أسفل الطية فقط، لكن لا تطبّقه أبداً على الصورة الرئيسية أو صورة LCP — واستخدم
fetchpriorityلتحميل الصورة الحرجة أولاً. - حدّد العرض والارتفاع دائماً للقضاء على انزياح التخطيط وحماية مؤشرات Core Web Vitals.
- أتمت العملية بالكامل عبر مكوّن Image في إطار العمل، وخدمة CDN، وميزانية لوزن الصفحة، كي يصمد التحسين أمام الرفع التالي.
تحسين الصور من تلك التحسينات النادرة التي يكون فيها الجهد الهندسي متواضعاً والعائد — صفحات أسرع، و SEO أفضل، وزوّار أكثر رضا — فورياً وقابلاً للقياس. إذا كان موقعك يشعر بالثقل ولست متأكداً من أين تبدأ، فيمكننا المساعدة. ألقِ نظرة على خدماتنا و أعمالنا، أو تواصل معنا وسنراجع وزن صفحتك ونضع خط تحسين متكاملاً في مكانه الصحيح.
عن الكاتب
SummationWorks
SummationWorks is a software development company building web apps, mobile apps, and AI tools for startups and growing businesses across the US, UK, and GCC.
المزيد عنّامقالات ذات صلة
engineeringبناء تطبيقات ويب سريعة في 2026
كيف نطلق تطبيقات ويب جاهزة للإنتاج تُحمّل فورًا وتتوسع — التقنيات، والمفاضلات، والعادات التي تقف خلف ذلك.
engineeringتحديد معدل الطلبات والحماية من الإساءة في الـ API: دليل عملي
كيف يحافظ rate limiting والحماية من الإساءة على استقرار الـ backend: استراتيجيات throttling ودفاعات متعددة الطبقات وحدود لا تعاقب المستخدمين الحقيقيين.
engineeringالنشر على App Store و Play Store: كيف تتجنّب الرفض
معظم حالات رفض التطبيقات يمكن تفاديها. دليل عملي لاجتياز مراجعة App Store و Play Store من أول محاولة، من الخصوصية إلى المدفوعات.