Lazy Loading Nedir? Görsellerde ve Iframe'lerde Kullanımı

Lazy loading için başlangıç ölçümünü netleştirin

Aynı sayfa farklı cihazlarda farklı sonuç üretir. Normal.

Tek sayı üzerinden acele karar vermek yerine dağılıma bakın. Mobil tarafta düşük işlem gücü ve ağ dalgalanması, masaüstünde görünmeyen gecikmeleri büyütür. Özellikle 3G bağlantıda lazy loading eşiği 200px iken, fiber bağlantıda 800px olabilir.

• Gerçek kullanıcı verisi: Chrome UX Report'tan 75. yüzdelik dilimi takip edin. Ortalama değil, en yavaş %25'lik kesim önemli.
• Laboratuvar testi: Lighthouse'u Moto G4 + Slow 4G profilinde çalıştırın. Masaüstü testi yanıltıcı.
• Cihaz kırılımı: Düşük-orta-yüksek segment ayrımı yapın. Her segment için ayrı eşik belirleyin.
• Zaman karşılaştırması: Aynı saatte, aynı koşullarda haftalık ölçüm. Trend grafiği tutun.

Raporda daha iyi görünen bir skor üretmek yetmez.

Lazy loading darboğazını katman katman ayırın

Gecikme kaynağını bulurken render blocking kaynak denetimi ve JavaScript yükleme düzeni birlikte incelenirse lazy loading etkisi daha doğru ölçülür.

Hız çalışmasını sürdürülebilir yapan şey: sorunun gerçek kaynağını bulmak. Çoğu zaman ilk gözüken semptom asıl sorun değildir.

Lazy loading yavaşsa, hemen loading="lazy" eklemek yerine DevTools Network sekmesini açın. Hangi kaynak ne zaman yükleniyor? Waterfall grafiğinde beklenmedik gecikmeler var mı? Bazen sorun lazy loading değil, öncelik sırasıdır: kritik CSS blokluyorsa, lazy loading hiç devreye girmez.

• Ağır medya: 500KB üzeri görseller varsa önce sıkıştırın. WebP formatına geçin, kalite %85'e düşürün. Lazy loading ağır dosyayı hafifletmez, sadece erteler.
• Bloklayan kaynak: Render-blocking CSS/JS varsa lazy loading etkisiz kalır. Önce blokajı kaldırın, sonra lazy loading ekleyin.
• Ana iş parçacığı yükü: JavaScript 2 saniye çalışıyorsa, lazy loading tetiklenmesi gecikir. Long Task'leri parçalayın.
• Sunucu gecikmesi: TTFB 1.5 saniyenin üzerindeyse, istemci tarafı optimizasyonu sınırlı etki yapar. Önce sunucu yanıt süresini düşürün.

Lazy loading tarafında öncelik sırası kurun

Her iyileştirme adımı aynı değerde değildir.

Bazı değişiklikler 2 saatte uygulanır, %30 hız kazancı sağlar. Bazıları 2 hafta sürer, %3 kazanç getirir. Pratikte en çok atlanan nokta: etki-maliyet matrisini kurmadan işe başlamak. Sonuç: düşük etkili işlere zaman harcanır, yüksek etkili işler ertelenir.

Önceliklendirme yaparken dört faktörü birlikte değerlendirin:

• Etki büyüklüğü: Lighthouse'ta simüle edin. LCP'yi 500ms düşürecek değişiklik, 50ms düşürecek değişiklikten önce gelir.
• Uygulama maliyeti: Kod satırı, test süresi, deployment riski. loading="lazy" eklemek 10 dakika, custom lazy loading kütüphanesi yazmak 3 gün.
• Risk seviyesi: Kritik yolda değişiklik yapıyorsanız, A/B test zorunlu. Viewport dışı görsellerde değişiklik yapıyorsanız, risk düşük.
• Geri dönüş süresi: Sorun çıkarsa ne kadar sürede geri alabilirsiniz? Feature flag kullanıyorsanız 5 dakika, kod değişikliği gerektiriyorsa 2 saat.

Lazy loading değişikliklerini küçük yayınlarla doğrulayın

Büyük değişiklikler risklidir. Küçük adımlar güvenlidir.

Teknik ekipte netleşmesi gereken alan: tüm lazy loading değişikliklerini aynı anda canlıya almak yerine, aşamalı yayın yapın. İlk hafta %10 trafiğe açın, metrik izleyin. Sorun yoksa %50'ye çıkarın. Hala sorun yoksa %100'e çıkarın. Sorun çıkarsa, hemen geri alın ve kök nedeni araştırın.

• Aşamalı yayın: Feature flag kullanın. Trafik yüzdesini dinamik olarak ayarlayın. Sorun çıkarsa kod değişikliği yapmadan geri alın.
• Önce test sonra canlı: Staging ortamında Lighthouse skorunu kontrol edin. 10 puan düşüyorsa, canlıya almayın. Kök nedeni bulun, düzeltin, tekrar test edin.
• Regresyon kontrolü: Her deployment sonrası otomatik Lighthouse testi çalıştırın. Skor 5 puan düşerse, deployment'ı otomatik geri alın.
• Geri alma planı: Her değişiklik için geri alma prosedürü yazın. "Feature flag'i kapat" veya "Önceki commit'e dön" gibi net adımlar.

Raporda daha iyi görünen bir skor üretmek yetmez.

Lazy loading verisini yanlış okumayın

Doğrulama tarafında Lighthouse metrik yorumu ve CDN dağıtım kalitesi birlikte takip edilirse yanıltıcı skor artışları kolayca ayrılır.

Gerçek kullanıcı verisinde açıkça görülen fark: ortalama değer yanıltır.

Lighthouse skorunuz 90 olabilir, ama gerçek kullanıcıların %30'u yavaş deneyim yaşıyor olabilir. Neden? Ortalama değil, dağılım önemli. Özellikle mobil tarafta düşük işlem gücü ve ağ dalgalanması, masaüstünde görünmeyen gecikmeleri büyütür. 75. yüzdelik dilime bakın: en yavaş %25'lik kesim nasıl deneyim yaşıyor?

• Tek ölçüm yanılgısı: Lighthouse'u 10 kez çalıştırın, medyan değeri alın. Tek ölçüm rastgele dalgalanma gösterir.
• Aşırı ortalama kullanımı: Ortalama yerine 75. yüzdelik dilimi takip edin. Google Core Web Vitals de 75. yüzdelik dilimi kullanır.
• Coğrafya farkı: Avrupa'dan hızlı, Asya'dan yavaş olabilir. CDN edge location'larını kontrol edin.
• Cihaz sınıfı etkisi: iPhone 14 Pro'da hızlı, Samsung Galaxy A12'de yavaş. Düşük segment cihazlarda test edin.

Lazy loading için sürdürülebilir kontrol rutini kurun

Tek seferlik iyileştirme çalışmaz. Performans borcu birikir.

İyileştirme kalitesini belirleyen adım: düzenli ölçüm döngüsü kurmak. Her sprint sonunda 15 dakikalık performans kontrolü yapın. Lighthouse skorunu kaydedin, trend grafiğini güncelleyin. Skor 5 puan düşmüşse, hangi değişiklik soruna yol açtı? Git history'yi kontrol edin, sorumlu commit'i bulun, düzeltin.

• Haftalık denetim: Her Cuma öğleden sonra Lighthouse testi çalıştırın. Sonuçları Slack'e gönderin. Skor düşüyorsa, pazartesi sabah ilk iş olarak inceleyin.
• Yayın öncesi kontrol: CI/CD pipeline'a Lighthouse testi ekleyin. Skor 80'in altındaysa, deployment'ı bloke edin. Geliştirici düzeltmeden merge edemez.
• Otomatik alarm: Real User Monitoring (RUM) kurun. LCP 2.5 saniyeyi geçerse, PagerDuty alarm göndersin. 5 dakika içinde müdahale edin.
• Dokümantasyon disiplini: Her performans değişikliğini CHANGELOG.md'ye yazın. "Lazy loading eşiği 200px'den 400px'e çıkarıldı, LCP 300ms düştü" gibi net kayıt tutun.

Raporda daha iyi görünen bir skor üretmek yetmez.

Vaka Notu: Tüm kaynakları ertelemek neden hata?

Bir medya sayfasında tüm görseller aynı kuralla ertelenmişti. İlk yük hafiflese de kullanıcı kaydırırken içerik gecikmeli açıldığı için deneyim bozuluyordu. İncelemede ilk ekran yakınındaki öğelerin de gereksiz ertelendiği görüldü. Eşik değerleri sayfa tipine göre güncellenince kullanıcı akışı kesintisiz hale geldi.

Doğru lazy loading, içerik akışını bozmadan ağ yükünü azaltır. Yanlış kullanım ise teknik kazancı görünür deneyime çeviremez. Bu nedenle her bileşen için tek kural yerine bağlama uygun yükleme stratejisi kullanılmalıdır.