Lazy Loading’i Sunucu Tarafında Doğru Kurgulayın (Performans Etkisi)

Lazy loading (gecikmeli yükleme), kullanıcı sayfayı açtığında her kaynağı hemen çekmek yerine yalnızca görünür alan için içerik/asset getirmeyi hedefler. Ancak performans sonucu tek başına tarayıcıdaki loading="lazy" veya IntersectionObserver’a bağlanmaz; isteklerin nereden geldiği (sunucu/CDN), nasıl cache’lendiği ve hangi kaynakların tetiklendiği belirleyicidir. Bu yazıda lazy loading’in sunucu tarafında TTFB, CDN cache hit oranı, bant genişliği ve origin yükü üzerindeki etkilerini net şekilde ayıracağız; ölçülebilir hedefler ve uygulanabilir ayarlar paylaşacağız.

Lazy loading sunucuya hangi yükleri getirir?

Lazy loading genellikle “frontend görünümü” gibi düşünülür. Fakat sonuç, sunucunun yanıt verdiği isteklerin sayısı ve bu isteklerin cache durumuna göre şekillenir.

Sunucu tarafında tipik senaryolar

Aşağıdaki davranışlar lazy loading’in “sunucu etkisini” doğrudan belirler:

1. Görsel/iframe/script gibi kaynaklar, viewport dışında kaldığı için geç istenir. Bu, origin’e ilk anda daha az istek gitmesi demektir.
2. Geç gelen istekler farklı cache anahtarlarıyla (query string, varyant, dil) gelir. Cache hit oranı düşerse origin yükü artar.
3. Geç gelen istekler tek tek küçük dosyalar döndürür. HTTP başlık maliyeti büyür; özellikle düşük bantlı senaryolarda belirginleşir.
4. Video veya büyük iframe içerikleri kısmi yükleme ister. Range request (byte aralığı) veya CDN edge fonksiyonu devreye girer; sunucu tarafında yanlış ayar varsa hata/yeniden deneme oranı artar.

Net ölçüm için: Lazy loading kullandığınız sayfalarda “ilk yükleme” ile “kullanıcı aşağı kaydırdıktan sonra” gelen istekleri ayrı ayrı inceleyin. Kıyas kriterini sadece sayfa hızına değil, origin’in aldığı istek hacmine bağlayın.

CDN varsa origin yükü azalır ama cache koşulu şart

CDN (Content Delivery Network) kullanıyorsanız lazy loading genelde origin trafiğini azaltır. Fakat CDN cache ayarlarınız yanlışsa, geç gelen istekler edge’de tutulmak yerine origin’e “taşınır” ve beklenen kazanç kaybolur.

Aşağıdaki kontrol noktaları sunucu tarafında kritik:

• Cache-Control: Görseller için public, max-age=... gibi değerler doğru mu?
• Vary: Accept-Encoding, User-Agent gibi gereksiz varyantlar üretip üretmediğinizi kontrol edin.
• Query string davranışı: CDN cache anahtarı query’e göre değişiyor mu? Lazily yüklenen kaynaklar aynı URL ama farklı query ile mi geliyor?

Lazy loading nerede işe yarar: veri türlerine göre net tablo

Lazy loading herkeste aynı performansı vermez. Kaynak türüne göre sunucu tarafında “kazanç” farklı olur.

Sunucu tarafında performans metriği: TTFB, cache hit ve origin RPS

Lazy loading’in doğru kurgulanıp kurgulanmadığını anlamak için üç metriği ayrı takip edin.

1) TTFB (Time to First Byte) ne zaman etkilenir?

Lazy loading tek başına TTFB’yi “garanti” düşürmez. TTFB; sunucunun ilk istek için iş yükünü (uygulama render, DB sorgusu, template, auth) yansıtır. Lazy loading genelde “ilk sayfa isteği”nde kaynağı geciktirir; bu da ilk sayfa için toplam işi azaltabilir.

Net çıkarım: - Eğer sayfa HTML’i render edilirken her görsel/iframe için sunucuda ekstra işlem yapılıyorsa (örn: dynamic thumbnail, kişiselleştirilmiş embed token), lazy loading kazanımı sınırlıdır. - Eğer görseller statik dosya olarak servis ediliyorsa, lazy loading en net kazancı verir.

2) Cache hit oranı: Lazy loading’in esas kırılım noktası

Lazy loading’in sunucu tarafındaki kaderi cache hit oranıdır. Çünkü geç istenen kaynaklar, cache’lenmediyse origin’e yük bindirir.

Pratik hedef: - Görsellerde CDN cache hit oranını yükseltmek için aynı URL’nin cache’lenmesini sağlayın. - Sonuçları “ilk kullanıcı akışı” ile “ikinci dalga” olarak ayrı inceleyin: yukarı kaydırma öncesi ve sonrası.

3) Origin’in aldığı RPS ve hata oranı

Lazy loading, belirli bir anda daha fazla istek doğurabilir (kullanıcı aşağı kaydırdığında). Bu yüzden: - Origin RPS piklerini izleyin. - 429/502/503 oranları artıyor mu kontrol edin. - Timeout ve yeniden deneme (retry) sayısı büyüyorsa CDN edge ayarları veya upstream keep-alive sorunu olabilir.

Sunucu yapılandırması: lazy loading için net ayar seti

Lazy loading’i sunucu tarafında “güvenli” ve “tahmin edilebilir” yapmak için aşağıdaki ayarları standart hale getirin.

Görseller ve statik dosyalar

Hedef: Görsel istekleri mümkün olduğunca cache’ten gelsin.

1. Dosya isimlerini sürümleyin (asset fingerprint). Örn: /img/banner-9f3a2c.webp gibi.
2. Cache-Control: Statik görsellerde uzun max-age kullanın. Son sürüm değişince URL de değişsin.
3. Vary: Gereksiz varyantları azaltın.
4. JPEG/WEBP/AVIF: Tarayıcıya uygun formatı doğru seçmek için content negotiation tarafını doğru kurgulayın.

Net kontrol listesi

• [ ] Görsel URL’leri aynı kaldıkça CDN’de cache’leniyor mu?
• [ ] Query string (utm, tracking param) yüzünden cache miss oluyor mu?
• [ ] HEAD/GET cache davranışı tutarlı mı?

Sayfa içi endpoint’ler (API, feed, embed token)

Lazy loading ile geç gelen iframe/video embed’leri genellikle “sunucu endpoint” çağırır.

• Embed içeriklerini statikleştirin veya “kullanıcıya özel token üretimi” gerekmiyorsa bunu azaltın.
• Token gerekiyorsa token üretiminde DB yükünü ve session bağımlılığını minimize edin.
• API yanıtlarında cache (ör: ETag, Last-Modified, kısa TTL) kullanın.

Net örnek yaklaşım: - Üretim maliyeti yüksek endpoint’ler için: stale-while-revalidate ile edge’den servis yapın.

Range request ve büyük dosyalar (video/PDF)

Video streaming ve büyük PDF/ZIP’te Range request performansı belirler.

• CDN edge’in Range desteğini test edin.
• Origin tarafında Range davranışı doğru değilse kullanıcı “takılma + yeniden istek” yaşar.
• Streaming modunda (HLS/DASH) segment cache süresini netleştirin.

Ölçüm rehberi (kopyala-uygula): lazy loading kaynaklarını tek tek ayırın

Net teşhis için test akışını standardize edin.

Adım 1: Ölçüm ortamını sabitleyin

• Aynı cihaz/aynı tarayıcı sürümü
• İnternet hızını aynı band aralığında tutun
• Aynı şehir/ISP koşullarını hedefleyin

Adım 2: Network panel ile “ilk tur” ve “ikinci tur”u ayırın

• İlk yükleme sırasında görünen istekleri kaydedin.
• Aşağı kaydırma veya etkileşim sonrası gelen istekleri ayrı işaretleyin.

Sonra şu sorulara cevap verin: - İkinci turda gelen görsellerin cevapları CDN’den mi geliyor? (Header/via işaretleri) - Yanıt süreleri (TTFB veya Download time) ani artıyor mu? - Cache miss sayısı belirgin mi?

Adım 3: Origin tarafında eş zamanlı izleme yapın

Sunucu tarafında şunları aynı zaman penceresinde izleyin: - CPU load (özellikle uygulama sunucusunda) - DB connection sayısı - Nginx/Apache upstream response süreleri - 5xx/4xx hata dağılımı

Net karar kuralı: - İkinci turda origin’e istek artıyorsa ve CDN miss oranı yükseliyorsa: cache ayarı sorunudur. - Origin yük artmadan yalnızca istemci yavaşlıyorsa: CDN edge/format/bitrate sorunu olabilir.

Yaygın yanlışlar ve net düzeltmeler

Yanlış 1: Lazy loading’i yaptım, sadece hız arttı sanmak

Lazy loading, bazı kaynakları geciktirir; toplam iş bazen aynı kalır, dağılım değişir. Bu nedenle kullanıcı etkileşimiyle “ikinci dalga” oluştuğunu varsayın.

Yanlış 2: Query string ile cache’i öldürmek

Örn: /image.jpg?ver=123&token=... gibi sık değişen parametreler CDN cache’i bozar.

Net düzeltme: - Token’ı URL’den ayırın (header/cookie veya kısa ömürlü signed URL kullanımı) ve cache anahtarını sabitleyin.

Yanlış 3: Çok fazla küçük istek

Lazy loading ile 1 büyük dosya yerine 50 küçük görsel/segment yükleyebilirsiniz. Bu, HTTP başlık maliyeti ve TLS overhead nedeniyle toplam süreyi uzatabilir.

Net düzeltme: - Görselleri uygun boyutta düzenleyin. - Uygunsa sprite/şemsiye görsel veya daha az sayıda segment stratejisi kullanın.

Yanlış 4: Embed içeriklerinde kişiselleştirilmiş render

İframe veya embed yüklenirken her kullanıcı için sunucuda ağır işlem yapılıyorsa lazy loading faydasını azaltır.

Net düzeltme: - Aynı içerik için mümkün olduğunda önbellek (cache) katmanı ekleyin. - Token üretimini hızlandırın ve DB sorgu sayısını düşürün.

Son kontrol: Sunucu tarafında “lazy loading bütçesi” belirleyin

Lazy loading’i ölçülebilir hale getirmek için performans bütçesi koyun.

Hedef örnekleri (net ve uygulanabilir)

• İlk sayfa HTML yanıtı için TTFB: uygulamanızın mevcut değerinden belirli bir sınırın üstüne çıkmayacak şekilde (örn: %10-15 tolerans).
• Görsel segment indirme için ikinci turda CDN hit oranı: hedeflediğiniz minimumu sağlamalı (ör: %80+).
• Origin’e giden istek sayısı: yalnızca ilk yük değil, aşağı kaydırma sonrası toplamda da kontrol altında olmalı.

Bu hedefleri NetKıyas’ta kıyas ettiğiniz hosting seçenekleriyle uyumlu kurun. Aynı mimaride (CDN + cache + doğru header) çalışan kurulumlarda performans daha öngörülebilir olur.

Sonuç: Lazy loading’i “frontend ayarı” değil, cache mimarisi olarak ele alın

Lazy loading sunucu tarafında doğru kurgulanmadığında, yalnızca istekleri erteleyip cache’i bozar ve origin yükünü ikinci dalgada artırır. Bu yüzden kontrol sırası net olmalı: önce CDN cache ayarlarını ve cache anahtarlarını sabitleyin, sonra ikinci tur isteklerde origin RPS ve 5xx oranını izleyin. Bugün bir aksiyon planı olarak; (1) statik görsellerde cache-control’ı gözden geçirin, (2) query/token yüzünden cache miss olan URL’leri tespit edin, (3) aşağı kaydırma testinde CDN’den gelen istek oranını ölçün. Bu üç adım, lazy loading’in performans etkisini kısa sürede “ölçülebilir” hale getirir.