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

Lazy loading nedir ve tarayıcı bunu nasıl işler?

Lazy loading, bir kaynağın yalnızca kullanıcının göreceği zamana yakın yüklenmesi anlamına gelir. Tüm sayfa içeriğini tek seferde indirmek yerine, görünür alan dışındaki öğeler ertelenir; kullanıcı o bölüme yaklaştığında yükleme başlar. Bu yaklaşım ilk yük süresini kısaltır ve gereksiz veri transferini önler.

Modern tarayıcılar, görseller için yerleşik lazy loading desteği sunar. HTML img etiketine loading="lazy" özelliği eklenmesi yeterlidir; tarayıcı Intersection Observer API'sini içsel olarak kullanarak kaynağın ne zaman yükleneceğine kendisi karar verir. Bu yaklaşım JavaScript gerektirmez ve çok düşük uygulama maliyetiyle anlamlı performans kazancı sağlayabilir.

Intersection Observer API ise özel senaryolarda JavaScript ile lazy loading uygulamak için kullanılır. API, bir elemanın görünür alana girip girmediğini gözlemler ve belirlenen eşiğe ulaşıldığında bir callback fonksiyonu çalıştırır. Bu sayede geliştiriciler yükleme tetikleme zamanını, eşik değerini ve kaç piksel öncesinde başlaması gerektiğini tam olarak kontrol edebilir. Varsayılan tarayıcı davranışının yeterli olmadığı carousel, sonsuz liste ve sekme paneli gibi bileşenlerde tercih edilir.

Görsellerde lazy loading: doğru ve yanlış kullanım

Görsel lazy loading uygulaması basit görünse de birkaç kritik hata sık tekrarlanır. En yaygın ve en maliyetli hata, LCP (Largest Contentful Paint) görseline lazy loading uygulamaktır. LCP görseli sayfanın en büyük görsel öğesidir ve tarayıcının mümkün olduğunca erken yüklemesi beklenir. loading="lazy" eklenmesi bu görselin yüklenmesini geciktirir ve LCP metriğini doğrudan kötüleştirir.

Kural olarak: ilk görüntü alanında (above-the-fold) görünebilecek tüm görseller loading="eager" veya hiç loading özelliği eklenmeden bırakılmalıdır. Yalnızca ekranın altında kalan görseller lazy loading adayıdır. Hero görseli, logolar, navigasyon ikonları ve sayfa üst bölümündeki tüm görseller bu kuraldan etkilenir.

Görsellere width ve height özelliklerini eklemek de lazy loading ile birlikte değerlendirilmesi gereken bir konudur. Bu özellikler olmadan tarayıcı görselin boyutunu bilemez ve sayfada yer ayıramaz. Görsel yüklendiğinde sayfa yerleşimi değişir; bu da CLS (Cumulative Layout Shift) sorununa yol açar. Boyut özelliklerini HTML'de belirtmek hem CLS'i önler hem de lazy loading'in daha sağlıklı çalışmasını sağlar.

• LCP görseline lazy loading eklemeyin: Sayfanın hero ya da en büyük görseli eager yüklenmelidir; aksi hâlde LCP skoru bozulur.
• width ve height her zaman belirtin: Görselin aspect ratio'su tarayıcı tarafından bilinirse yer tutucu doğru boyutlandırılır, layout kayması önlenir.
• Eşiği duruma göre ayarlayın: Varsayılan tarayıcı eşiği çoğu durumda yeterlidir; özelleştirme yalnızca ölçüm verisiyle sorun tespit edildiğinde yapılmalıdır.
• Placeholder kullanın: Görsel yüklenirken gösterilen düşük çözünürlüklü yer tutucu veya renk bloğu, kullanıcının içeriğin yükleneceğini anlamasına yardımcı olur.

Iframe'lerde lazy loading ve video gömme stratejisi

Iframe'ler, sayfanın en ağır yükleyicileri arasında yer alır. YouTube videosu, harita gömme veya sosyal medya widget'ı gibi iframe bileşenleri yüzlerce kilobayt JavaScript ve CSS yükleyebilir. Bu yük doğrudan ilk yüklenme süresini ve ana iş parçacığı meşguliyetini artırır.

HTML5 standardıyla birlikte loading="lazy" özelliği iframe etiketleri için de kullanılabilir hâle geldi. Kullanım sözdizimi görsellerin aynıdır: <iframe loading="lazy" src="...">. Bu sayede sayfa altındaki harita veya video bileşenleri, kullanıcı o bölüme kadar kaydırmadan yüklenmez.

Video gömmelerde daha agresif bir strateji mümkündür: gerçek iframe yerine önce statik bir önizleme görseli göstermek ve kullanıcı tıklayana kadar iframe'i hiç yüklememek. Bu yaklaşım "lite YouTube embed" olarak bilinir. Sayfa ilk yüklendiğinde yalnızca küçük bir görsel dosyası indirilir; kullanıcı oynat düğmesine bastığında gerçek YouTube player yüklenir. Bu yöntem özellikle birden fazla video içeren sayfalarda 100-400ms arasında kazanım sağlayabilir.

• Harita iframe'leri: Google Maps veya benzeri harita gömmeleri kullanıcı sayfaya ulaşmadan yüklenmemelidir; loading="lazy" veya tıklama tetiklemeli yükleme tercih edilmeli.
• Video thumbnail stratejisi: YouTube embed yerine önizleme görseli gösterin, tıklamada gerçek player yükleyin; ilk yük büyük ölçüde hafifler.
• Sosyal medya widget'ları: Twitter, Instagram gibi widget'lar çok fazla kaynak yükler; mümkünse statik ekran görüntüsüyle değiştirin veya etkileşim anında yükleyin.
• Üçüncü taraf iframe denetimi: Sayfanızdaki tüm iframe'leri listeleyin, her birinin ne kadar ağırlık eklediğini ölçün ve yalnızca gerekli olanları tutun.

Eşik kararından önce ölçüm ve cihaz profilini 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.

Gecikmenin kaynağını yükleme zincirinde bulun

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.

Sorun her zaman lazy loading katmanında değildir. Görünür semptom genellikle öncelik sıralaması ya da bloklayan başka bir kaynaktan kaynaklanır.

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.

Her bileşen için eşik ve yükleme stratejisi ayrı belirlenir

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

Bazı değişiklikler 2 saatte uygulanır, önemli hız kazancı getirir. Bazıları 2 hafta sürer ve çok az kazanç sağlar. Etki-maliyet matrisini kurmadan işe başlamak en yaygın zaman kaybı kaynaklarından biridir; düşük etkili adımlar öncelik alırken yüksek etkilileri 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.

Kademeli yayın olası regresyonu erken yakalar

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

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. 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.

Araç skoru ile gerçek kullanıcı deneyimi ayrışabilir

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.

Araç skoru 90 gösterse de kullanıcıların önemli bir kesimi yavaş deneyim yaşıyor olabilir.

Dağılım belirleyicidir, ortalama değil. 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.

Düzenli kontrol olmadan kazanım geri döner

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

Her sprint sonunda kısa bir performans kontrolü yapın. Lighthouse skorunu kaydedin, trend grafiğini güncelleyin. Skor aniden 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.