Lazy Loading sunucu tarafında nasıl etki eder? Performans rehberi

Lazy loading (tembel yükleme) denince çoğu kişinin aklına görsellerin kullanıcı kaydırdıkça gelmesi gelir. Ancak gerçek performans etkisi yalnızca tarayıcıda değil; CDN, uygulama katmanı, web sunucusu (Nginx/Apache), hatta geriye kalan önbellek ve sıkıştırma davranışları üzerinden de şekillenir. Bu rehberde lazy loading’in sunucu tarafında neyi değiştirdiğini, hangi metriklerle doğrulanacağını ve hangi ayarların gecikmeyi artırmadan fayda sağlayacağını net şekilde göreceksiniz.

Aşağıdaki başlıklarda: - Lazy loading’in ilk istek / sonraki istek maliyetini sunucu perspektifinden nasıl etkilediğini - Sunucu yükünü azaltırken neden bazen artırdığını - HTTP önbellekleme, CDN cache hit oranı, sıkıştırma ve bağlantı sayısı gibi somut noktaları - Uygulama ve sunucu tarafında uygulanabilir kontrol listesini adım adım anlatıyorum.

Lazy loading aslında “sunucuya” ne yapar?

Lazy loading; içeriğin tamamını sayfa açılır açılmaz istemek yerine, belirli öğelerin görünür hale gelmesiyle ek istekler üretmeyi hedefler. Bu “ek istekler” sunucu tarafında şu değişkenleri doğrudan etkiler:

1) İstek dağılımı: İlk sayfa ağırlığı azalır, toplam istek sayısı değişebilir

• Önceden (lazy olmadan): Sayfa HTML + tüm görsel/medya referansları tek seferde dolaşır. Görseller ayrı dosya olduğunda yine HTTP istekleri vardır; fakat kullanıcı davranışına göre istekler değişmeden gelir.
• Lazy ile: İlk sayfa yükü azalır; ancak sayfa scroll edildikçe daha fazla “zamansal kümelenmiş” istek oluşur.

Sunucu açısından iki kritik sonuç çıkar: - İlk an için CPU ve ağ bant genişliği azalabilir. - Scroll anlarında kısa periyotlarda pik istek oluşabilir. Bu pik, origin (asıl sunucu) yerine CDN’e giderse sorun olmaz; CDN origin’e her şeyi kaçırıyorsa maliyet yükselir.

2) Cache davranışı: Aynı dosya ama farklı zamanlama

Lazy loading’in çoğu zaman yaptığı şey URL’leri değiştirmekten ziyade, “ne zaman isteneceğini” değiştirmektir. Cache hit oranı şu yüzden etkilenebilir: - Görsel ilk anda istenmediği için, CDN cache warming gecikebilir. - Kullanıcı kitlesi bölgesel ve farklı zamanlarda scroll ettiği için, aynı görsel aynı anda değil, parça parça istenebilir.

Eğer CDN üzerinde “cache süresi (TTL)” yeterliyse toplam cache hit oranı korunur. TTL kısa ise ve origin sık sık devreye giriyorsa sunucu tarafı yük artar.

3) Bağlantı ve sıra (queueing): Çoklu dosya istemi sunucuyu sıra kuyruğuna sokabilir

Lazy loading genellikle görselleri tek tek yükler. Bu, tarayıcı tarafında paralellik ve istek sırası (request concurrency) ile birleşince sunucu tarafında şu durumlardan birine yol açabilir: - CDN katmanı yeterli ölçekle çalışır: origin’e az istek gider. - CDN kaçırırsa origin üzerinde worker/thread sayısı dolabilir, yanıt süreleri uzar.

Bu etkiyi anlamak için “toplam istek sayısı” kadar “origin’e gelen istek” ve “origin yanıt süreleri” metriklerine bakmak gerekir.

Sunucu tarafında performans etkisini ölçmek için net metrikler

Lazy loading’in faydasını doğru yorumlamak için yalnızca sayfa yüklenme süresine bakmak yeterli değildir. Sunucu tarafını açıklayan metrik seti aşağıdadır.

En kritik 6 metrik

1. CDN Cache Hit Ratio (CDN isabet oranı): Lazy ile istenen dosyalarda düşüş var mı?
2. Origin Requests / Origin Response Time: Origin’e giden istek sayısı ve gecikme.
3. TTFB (Time to First Byte): Özellikle HTML için. Lazy’nin HTML üzerindeki etkisi sınırlı olmalıdır.
4. Toplam transfer edilen bayt (ingress/egress): Scroll ile artan veri miktarı.
5. Web server worker/CPU kullanımı: Nginx/Apache CPU spike’leri.
6. 5xx oranı ve upstream timeouts: Pik zamanlarında artış var mı?

Ölçüm senaryosu: A/B değil, davranış eşleştirme

Lazy loading kullanıcı etkileşimine bağlıdır. Bu nedenle ölçümü şöyle yapın: - Aynı cihaz sınıfı (mobil/masaüstü) ve aynı tarayıcı - Aynı sayfa akışı (ör. ilk ekran + birinci viewport dışı görseller) - Aynı coğrafi CDN bölgesi (mümkünse)

Bu sayede “scroll anında” oluşan pikleri origin tarafında görürsünüz.

Lazy loading ne zaman sunucu yükünü azaltır? Ne zaman artırır?

Aşağıdaki karşılaştırma, sunucu tarafında karar verirken en çok iş gören çerçeveyi sunar.

Sunucu ve CDN tarafında uygulanacak net ayarlar

Lazy loading’i tek başına “sayfa performansı” problemi gibi düşünmeyin. Sunucu katmanında doğru cache ve teslim politikası yoksa lazy, tersine çevrilebilir.

1) Görseller için cache politikasını standardize edin

Aşağıdaki ilke pratikte origin yükünü belirler: - Görsel dosyaları statikse kalıcı cache hedeflenmelidir. - Dosyalar güncellendiyse URL versiyonlaması (örn. dosya hash’i) ile cache kırılmalıdır.

Net sonuç: Cache-Control: public, max-age=31536000, immutable gibi kalıcı cache yaklaşımı, lazy loading’de görülen scroll piklerini origin yerine CDN üzerinde dağıtır.

Not: Bu değerleri kullanmadan önce dosya isimlendirme/versiyonlama stratejinizi test edin. Güncellenen dosya aynı URL ile dönüyorsa kalıcı cache yanlış davranır.

2) CDN cache anahtarı: Vary ve sorgu parametreleri

Lazy loading “aynı URL” ile giderken bile cache anahtarı yanlışsa her istek origin’e düşebilir. Kritik noktalar: - Vary başlıkları aşırı geniş mi? (Örn. Vary: Accept-Encoding normaldir; gereksiz alanlar cache’i böler.) - URL query parametresi (örn. ?t=...) her istekte değişiyor mu?

Kontrol: CDN panelinde aynı görsel için isabet oranı (hit/miss) scroll öncesi ve sonrası karşılaştırın.

3) Web sunucusu (Nginx/Apache) tarafında sık kullanılan ayarlar

Lazy loading doğrudan sunucuyu “az çalıştırır” demek değildir; asıl belirleyici origin’e gelen istek miktarıdır. Origin’e gelen istekler artıyorsa aşağıdaki başlıklar önem kazanır:

Dosya teslimi için doğru cache ve etag ayarları

• Statik dosyalarda expires (veya eşdeğer) + Cache-Control uyumlu olmalı.
• ETag/Last-Modified doğrulama gereksiz dolaşıma yol açmamalı.

Sıkıştırma (gzip/brotli) ve görsel türleri

• Görsel dosyaları (JPEG/PNG) sıkıştırması sınırlı fayda verir; zaten sıkıştırılmış formattır.
• HTML/CSS/JS için brotli/gzip devam eder.

Net test: Origin CPU spike yaşanıyorsa “sıkıştırma ne için yapılıyor?” sorusunu yanıtlayın.

Range istekleri ve parçalı yükleme

Bazı tarayıcı davranışları ya da video/ileri seviye görsel akışları Range ile çalışabilir. Origin tarafında range desteği ve cache uyumu yoksa artan maliyet oluşur.

4) Uygulama katmanı: Lazy olayı hızlandırın, sunucuya ek iş bindirmeyin

Lazy yüklenen görseller için sunucu tarafında şu hatalar performansı düşürür: - Her istek için dinamik dönüştürme (örn. on-the-fly görsel resizing) ve bunu origin üstleniyorsa - Her görsel için arka planda veritabanı sorgusu yapılması

Net yaklaşım: Dönüşüm gerekiyorsa bunu build/pipeline aşamasında üretin ya da CDN edge tarafında tutarlı bir şekilde yönetin.

“Doğru lazy” ile “yanlış lazy” farkı: somut teknik ipuçları

Lazy loading’in sunucu tarafına etkisini belirleyen asıl unsur, lazy’nin nasıl kurulduğudur.

1) Görsellerde loading="lazy" tek başına yetmez

Sadece tarayıcının yerel lazy davranışına güvenmek, bazı senaryolarda pikleri artırabilir. Sunucu tarafında kritik etkiler için şu düzen önemlidir: - Görsel boyutlarını belirleyin (ör. width/height). Bu, layout thrash’i azaltır ve tarayıcı davranışını daha öngörülebilir kılar. - Çok sayıda görsel varsa kademeli yükleme (ör. intersection tabanlı tetik) ile istek yoğunluğunu kontrol edin.

2) Önbellek uyumlu URL’ler: değişmeyen içerik = cache dostu

Lazy yükleme ile sayfa açılışında istenmeyen dosyalar için “ilk istek” scroll ile başlar. O dosyalar cache dostu URL’lere sahip değilse her kullanıcı yeni istek üretir ve origin’i yorar.

3) HTTP/2/HTTP/3 ve paralellik yönetimi

Lazy, scroll ile çok sayıda görseli ardışık istemeye iter. HTTP/2 veya HTTP/3 varsa tek bağlantı üstünden multiplex daha verimli olur.

Net hedef: Origin’de connection sayıları ve upstream queue büyüyor mu? Eğer artıyorsa HTTP sürümü ve CDN-oriigin bağlantı ayarları gözden geçirilmelidir.

Pratik kontrol listesi (sunucu tarafında)

Lazy loading’i devreye aldınız ya da test ediyorsunuz. Aşağıdaki listeyi “pass/fail” mantığıyla kullanın.

CDN ve cache

• [ ] Lazy ile istenen görsellerde CDN hit oranı scroll öncesine yakın mı?
• [ ] Görseller için Cache-Control statik içerik gibi mi davranıyor?
• [ ] URL versiyonlama var mı? Güncelleme sonrası cache bozuluyor mu?
• [ ] Vary başlıkları gereksiz bölüyor mu?

Origin (sunucu) gözlemi

• [ ] Scroll piklerinde origin CPU ve worker/thread kullanımı artıyor mu?
• [ ] Origin response time piki, CDN’deki hit düşüşüyle mi örtüşüyor?
• [ ] 5xx/timeout oranları zirveye çıkıyor mu?

Uygulama tarafı

• [ ] Lazy yüklenen görseller dinamik dönüştürme ile üretilmiyor mu? (DB/CPU bağımlılığı yok mu?)
• [ ] Görseller doğru boyutlarla ve tekil URL’lerle mi servis ediliyor?

Sonuç: Aksiyon planı

Lazy loading, doğru yapılandırıldığında ilk sayfa yükünü hafifletir ve kullanıcı deneyimini iyileştirir; ancak sunucu tarafında asıl belirleyici olan CDN cache politikası ve origin’e giden isteklerin zamanlama/pik davranışıdır. Bu rehbere göre ilk adım olarak: CDN hit oranı ve origin response time’ı “scroll öncesi vs scroll sonrası” karşılaştırın; hit düşüyorsa cache header ve URL versiyonlama stratejinizi düzeltin. Sonra HTTP/2/HTTP/3, görsel boyutlandırma ve istek sayısını kontrol ederek pikleri CDN üzerinde tutacak şekilde ilerleyin.