Lazy Loading للصور: حمّل 12 صورة بدل 200 وقدّم الصفحة في 1.8 ثانية بدل 6.4

متى يفشل native lazy loading

الـ native lazy loading بيفشل في 3 حالات شائعة لازم تعرفها:

• الصور فوق الـ fold: لو حطيت loading="lazy" على صورة الـ hero أو الـ banner الرئيسي، هتأخّر LCP (Largest Contentful Paint) بـ 200-400ms لأن المتصفح بيستنى يقرر هل الصورة في الـ viewport ولا لأ. خليها loading="eager" أو سيبها بدون attribute.
• صور في carousel: المتصفح بيحسب الـ visibility بناءً على الـ viewport، مش الـ slide الظاهر. الصور المخفية في الـ slides التانية بتتحمّل كلها مرة واحدة في غالبية مكتبات الـ carousel. لازم تتعامل معاهم يدويًا.
• iframes ثقيلة (يوتيوب): التاج <iframe loading="lazy"> بيشتغل، لكن iframe اليوتيوب بيحمّل ~600KB من JavaScript حتى لو الفيديو مش بيشتغل. استبدله بصورة thumbnail عادية وحمّل الـ iframe بـ JavaScript عند الضغط فقط.

الأرقام الفعلية — صفحة منتجات تجريبية

قِست الفرق على صفحة فيها 80 منتج، كل صورة بحجم 24KB متوسط، شبكة 4G محاكاة (1.6 Mbps) في DevTools throttling:

• قبل: 80 طلب صورة، إجمالي 1.92MB، LCP = 6.4 ثانية، Time to Interactive = 9.1 ثانية.
• بعد: 12 طلب صورة في أول تحميل (اللي ظاهرة فعلاً)، إجمالي 288KB، LCP = 1.8 ثانية، Time to Interactive = 2.4 ثانية.

التوفير: 85% من الـ bytes في أول تحميل. الزائر اللي مش بيعمل scroll بياخد الصفحة في 1.8 ثانية بدل 6.4. الـ bandwidth توفير حقيقي على السيرفر بتاعك كمان لو زوارك بالملايين.

Intersection Observer — للحالات المتقدمة

لو محتاج تحكّم أكتر زي تحميل background images أو تشغيل animation عند ظهور عنصر، استخدم Intersection Observer مباشرة:

الـ HTML المرافق بيستخدم data-src بدل src:

الـ rootMargin: '200px' بيخلّي التحميل يبدأ قبل ما الصورة تدخل الـ viewport بـ 200 بكسل. Trade-off: قيمة أكبر = الصور بتظهر أسرع للزائر، لكن بتحمّل صور أكتر مش ضرورية. قيمة أقل = توفير أكتر، لكن الزائر هيشوف صور بتظهر فجأة وهو بيعمل scroll. ابدأ بـ 200px وعدّل بناءً على القياس.

Trade-offs لازم تعرفها

Lazy Loading مش مجاني. الثمن اللي بتدفعه:

• SEO: Googlebot بيرندر الصفحة دلوقتي، لكن لو الـ JavaScript فاشل أو الـ Intersection Observer مش شغّال، الصور المتأخرة ممكن متتفهرسش في Google Images. الـ loading="lazy" الـ native آمن مع SEO. الـ custom Intersection Observer لازم تختبره بـ Mobile-Friendly Test.
• تجربة الـ scroll: لو الـ rootMargin قليل، الزائر هيشوف صور بتظهر فجأة وهو بيعمل scroll سريع. اضبطه على 200-400px للموبايل و 600px للديسكتوب.
• Print: طباعة الصفحة ممكن تطلع بدون الصور المتأخرة. الحل: حمّل الكل قبل window.print() عبر window.matchMedia('print').addListener(...).

متى لا تستخدم Lazy Loading

متستخدمهاش في الحالات دي:

• صور الـ hero أو أي حاجة فوق الـ fold (هيأذي LCP).
• صفحات فيها 5 صور أو أقل — الفرق هيكون بضع كيلوبايتات، مش يستاهل أي تعقيد.
• تطبيقات داخلية (intranet) على شبكة سريعة جدًا — الـ lazy loading بيضيف latency بسيط لما الزائر يعمل scroll، وده ممكن يبان في تطبيق داخلي بيعتمد على سرعة الاستجابة.
• Single Page Applications اللي بتعتمد على framework بيحقن الـ DOM ديناميكيًا بدون مراعاة loading attribute (لازم تتأكد من الـ rendering pipeline).

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

افتح أكبر صفحة في موقعك دلوقتي وعدّ عدد الصور فيها. لو أكتر من 10، ضيف loading="lazy" على كل صورة تحت الـ fold فقط. شغّل Lighthouse قبل وبعد، وقارن LCP و Total Blocking Time. لو الفرق أقل من 500ms، كده الصور مش هي bottleneck الأداء عندك، ابحث في الـ JavaScript bundle بدلًا منها.

المصادر

• web.dev — Lazy loading images
• MDN — img loading attribute
• MDN — Intersection Observer API
• Can I use — loading="lazy"
• web.dev — Largest Contentful Paint (LCP)
• Chrome Platform Status — Native Lazy Loading