Lazy loading (sunucu tarafı): Performansı gerçekçe nasıl etkiler?

Lazy loading, kullanıcı sayfayı görüntülemeye başladığında hemen görünmeyen içerikleri gecikmeli getirme tekniğidir. Ancak bu iş sadece tarayıcı tarafında bitmez: Sunucu tarafındaki HTML üretimi, istek yolları (URL tasarımı), cache (önbellek) ve arka uç veritabanı sorguları da performansı belirler. Bu yazıda sunucu tarafında lazy loading’in hangi metrikleri etkilediğini, hangi durumlarda fayda sağladığını hangi durumlarda ise “sadece karmaşa” ürettiğini net sayılar ve kontrol adımlarıyla ele alacağız.

Lazy loading sunucuda ne değiştirir?

Lazy loading uygulandığında tarayıcı, ilk sayfa yüklemesi sırasında tüm görselleri/iframe’leri hemen indirmez; sayfa içinde görünürlük yaklaşınca ek istekler üretir. Sunucu açısından değişen temel şeyler şunlardır:

• İlk yanıtın (HTML) boyutu ve üretim maliyeti: Görsellerin/iframe’lerin yer tutucularla değiştirilmesi HTML ağırlığını düşürebilir.
• İlk sayfa akışının (request waterfall) dağılımı: Daha az kaynak ilk anda gelir; sonraki istekler kullanıcı etkileşimine göre zamanlanır.
• Yeni isteklerin sayısı ve türü: Sayfa başına “ek istek” sayısı artabilir (ör. her görsel için ayrı endpoint).
• Cache davranışı: Görsel dosyaları cache’lenirse bant genişliği ve backend yükü azalır. Endpoint cache’lenmezse tersine backend yığılabilir.
• Veritabanı sorguları: Lazy yüklenen içerik sunucu tarafından dinamik üretiliyorsa (ör. resim boyutlandırma, ürün kartı, kişiselleştirme), her lazy istek yeni sorgu anlamına gelir.

Bu nedenle “lazy loading iyi midir?” sorusu tek başına cevaplanmaz. Cevap, lazy yüklenen kaynakların sunucuda nasıl üretildiği ve cache’in nasıl çalıştığına bağlıdır.

Hangi metrikler etkilenir?

Lazy loading’in etkisini ölçmek için dört metrik seti kullanın:

1. TTFB / TTFB (Time To First Byte): HTML’in ilk byte’ı ne kadar erken gelir?
2. Toplam transfer (KB/MB) ve istek sayısı: İlk yüklemede indirilenden tasarruf var mı?
3. Backend CPU süresi ve DB sorgu sayısı: Lazy endpoint’ler backend’e yük biniyor mu?
4. İstemci tarafı render gecikmesi: Kullanıcı içeriği görünce “görsel boşluğu” geç geliyor mu?

Sunucu tarafında beklenen fayda: bant genişliği ve backend yükü

Lazy loading’in en net faydası, ilk sayfa yüklemesinde gereksiz büyük varlıkların (özellikle görseller) indirilmemesidir. Bu faydayı sunucuda görmek için iki koşul gerekir:

• Lazy içerik istekleri static dosya gibi davranmalıdır (CDN ve cache’den hızlı dönmeli).
• Bu istekler backend veritabanı üretimine dayanıyorsa, üretim cache’lenmelidir.

Örnek senaryo (tipik bir içerik sayfası): - İlk yüklemede 12 görselin 3’ü görünür. - Geri kalan 9’u lazy ile gelir.

Eğer görseller doğrudan dosya olarak servis ediliyorsa ve CDN’de cache’leniyorsa, ilk anda sunucu bant genişliği azalır; sunucu sadece HTML + görünen 3 görseli taşır. Kullanıcı aşağı kaydırdıkça CDN üzerinden kalan görseller gelir. Bu, sunucuda CPU ve DB yükünü de azaltır.

Doğru cache stratejisi olmadan sonuç tersine dönebilir

Lazy endpoint “dinamik” üretim yapıyorsa (ör. “görseli şu boyuta göre DB’den çekip resize ederek döndür”), her ek istek backend’i çalıştırır. Bu durumda: - Toplam istek sayısı arttığı için yanıt kuyruğu (queueing) oluşabilir. - TTFB aynı kalabilir ama backend saturation (tampon/disk/CPU) yüzünden yanıt süreleri uzayabilir.

Bu yüzden sunucu tarafında lazy loading değerlendirirken şu soruyu sorun:

• Lazy yüklenen içerik cache hit alıyor mu?
• Hit yoksa istek başına maliyet nedir? (DB sorgusu, dosya sistemi okuma, resize işlemi vb.)

Riskler: Neden “lazy loading” bazı sitelerde yavaşlatır?

Lazy loading’in sunucu tarafında performansı bozduğu tipik durumlar aşağıdaki gibidir.

1) Lazy endpoint’ler dinamik ve cache’siz

Lazy ile gelen her istek, sunucu üzerinde yeni iş üretiyorsa (ör. her görsel için API çağrısı, her kart için kişiselleştirilmiş HTML), toplam iş yükü artabilir.

Kontrol: - Sunucu loglarında lazy endpoint’ler için saniyede istek (RPS) ve yanıt süresi trendlerine bakın. - Aynı sayfanın ilk yüklemesi ile kullanıcı kaydırdığında backend metriklerini karşılaştırın.

2) Yanlış URL tasarımı: cache’i bozan query parametreler

Görsel endpoint’inde ?w=400&h=300&ts=... gibi her istekte değişen parametreler kullanılıyorsa cache atlanır. Sonuç olarak CDN/Reverse proxy hit yerine miss olur.

Kontrol (net test): - Aynı parametrelerle (sadece test) 10 kez istek gönderin. - CDN’de hit oranı belirgin şekilde düşüyorsa lazy loading, bant genişliği tasarrufunu boşa çıkarır.

3) “Üstteki boşluk” etkisi: LCP ve kullanıcı algısı

Sunucu tarafında HTML üretimi “height”/“aspect-ratio” ayarlamıyorsa tarayıcı görsel yer tutucuyu doğru hesaplayamaz. Bu durum kaydırma ile birlikte layout shift (CLS) doğurur. Sonuç olarak kullanıcı sayfayı “yavaş” hissedebilir.

Not: Bu risk tarayıcıda görülür ama nedeni çoğu zaman sunucunun verdiği HTML/etiket düzenidir.

4) Batch yerine tekil istekler: HTTP/2 ile bile maliyet

Lazy içerikleri “tek bir toplu endpoint” yerine her parça için ayrı istek şeklinde döndürmek istek sayısını artırır. HTTP/2 ile kısmen azalır; yine de sunucu tarafında bağlantı yönetimi ve uygulama katmanı maliyetleri doğabilir.

Sunucu tarafında uygulanabilir bir performans kontrol listesi

Aşağıdaki kontrol listesini, kurduğunuz lazy loading yaklaşımına göre birebir uygulayın.

1) İlk yükleme: HTML maliyeti ve TTFB

• Uygulama: HTML içinde lazy olan bileşenleri yer tutucu ile temsil edin.
• Ölçüm: TTFB değerini baseline ile karşılaştırın (aynı sayfa, aynı içerik).

Hedef: - HTML üretimi ağırlaşmamalı. Lazy, HTML’i büyütüyorsa (ör. ek veri gömülüyorsa) ters etki yapar.

2) Lazy içerik istekleri: cache var mı?

Aşağıdaki örnek başlıklar “hedeflenen davranış” için tipiktir (değerler sunucuya göre değişebilir): - Static görseller için Cache-Control: public, max-age=... - Dinamik ama cache’lenebilir endpoint’ler için varyant stratejisi (örn. Vary: Accept-Encoding)

Kontrol: - CDN / reverse proxy üzerindeki cache hit oranı düşmemeli. - Sunucu tarafında lazy endpoint’lerde CPU kullanımı kullanıcı scroll’ı ile birlikte artıyorsa, cache ya yoktur ya da etkisizdir.

3) Görsel üretimi: resize (img proxy) maliyeti

Eğer lazy görseller boyutlandırılarak servis ediliyorsa şu kuralları uygulayın: - Boyutlandırma sonuçlarını cache’leyin (örn. w/h kombinasyonu başına dosya cache’i). - Aynı kombinasyon için tekrar üretim yapmayın.

Net test: - Aynı görsel için aynı boyutlarla 5 kez istek gönderin. - İlk istekten sonra üretim süresi belirgin şekilde düşmüyorsa cache üretiminde sorun vardır.

4) Log bazlı ayrıştırma: lazy isteklerini ayırın

Analizde hangi isteklerin lazy olduğunu ayırın. Pratik yöntemler: - Lazy endpoint URL’lerine belirgin bir prefix koyun: /lazy/ veya /media/l/ - CDN loglarında uri-stem üzerinden gruplama yapın.

Aşağıdaki tablo, hedef davranış ile riskli davranışı hızlı görmenizi sağlar.

Karşılaştırmalı örnek: cache’li vs cache’siz lazy endpoint

Bu bölümde sayısal olarak mantığı netleştirelim. Varsayalım ki kullanıcı başına sayfa görüntüleme sırasında: - Görsel sayısı: 12 - İlk ekranda görünen: 3 - Lazy ile gelen: 9

Durum A: Lazy görseller CDN’den cache’leniyor

• İlk yükleme: Sunucu 3 görsel + HTML gönderir.
• Lazy yükleme: CDN’den (cache hit) 9 görselin çoğu sunulur.

Beklenen sonuç: - Sunucuda transfer düşer. - Lazy isteklerde uygulama katmanı (PHP/Node vb.) devreye girmez veya çok az girer. - DB sorguları aynı kalır.

Durum B: Lazy görseller cache’siz dinamik üretiliyor

• İlk yükleme: Sunucu yine HTML gönderir.
• Lazy yükleme: 9 görsel için her kaydırmada backend resize/DB çağrısı olur.

Beklenen sonuç: - Kullanıcılar sayfayı scroll ettikçe RPS artar. - CPU ve disk/DB yükü yükselir. - Aynı görsel tekrar talep edilirse yeniden işlenir.

Bu karşılaştırma, lazy loading’in “her zaman hızlandırdığı” iddiasının neden hatalı olduğunu gösterir: Sunucu tarafında cache ve üretim maliyeti belirleyicidir.

Uygulama önerisi: Lazy loading’i sunucu tarafında doğru tasarlayın

Lazy loading’i performans açısından sağlam yapmak için şu net tasarım kurallarını izleyin:

1) Lazy içerikler için “cache’lenebilir” mimariyi hedefleyin

• Mümkünse görselleri static dosya olarak servis edin.
• Resize gerekiyorsa sonuçları cache’leyin (dosya cache veya object cache).

2) Lazy istek başına işi küçültün

• Her lazy istek yeni bir “ağır sayfa render”ı yapmasın.
• Ürün kartı gibi parçalar gerekiyorsa template fragment’ları cache’leyin.

3) Ölçüm olmadan optimizasyon yapmayın

Aşağıdaki şekilde ilerleyin:

1. Lazy’yi kapatın, 24 saat ölçün (baseline).
2. Lazy’yi açın, aynı trafikle ölçün.
3. Şu üç metriği karşılaştırın: - Sunucu TTFB (HTML üretimi değişti mi?) - Lazy endpoint’lerde cache hit oranı - Backend CPU/DB sorgu seviyesi

4) Hedef metrikleri belirleyin (tek metrikle yetinmeyin)

Önerilen hedef seti: - TTFB: belirgin kötüleşmeyecek - Toplam KB: ilk yüklemede düşecek - Sunucu CPU/DB: lazy açıldıktan sonra kontrol edilebilir artış gösterecek - LCP/CLS: kullanıcı algısını bozmayacak (sunucunun HTML yer tutucu düzeni etkiler)

Sonuç: Lazy loading’i sunucu tarafında “cache ve üretim” belirler

Lazy loading, sunucu tarafında doğru tasarlanırsa ilk yüklemede bant genişliği ve backend yükünü azaltır; yanlış tasarlanırsa lazy istekleri backend’i boğarak genel performansı düşürür. Bu yüzden aksiyon planınız net olmalı: Lazy endpoint’leri ayırın, cache hit oranını ve lazy isteklerin CPU/DB etkisini ölçün. Cache’lenebilir mimari kurmadan lazy’i “her yerde” uygulamayın; en yüksek maliyetli varlıklardan başlayın ve her iterasyonda log temelli karşılaştırma yapın.