Lazy Loading (Sunucu Tarafı): Performans Etkisi ve Doğru Kurulum

Lazy loading (tembel yükleme), web sayfalarında görünmeyen içeriklerin yüklenmesini erteleyerek kullanıcı deneyimini hızlandırmayı hedefler. Ancak lazy loading yalnızca tarayıcı tarafı bir teknik değildir; sunucu tarafında da istek sayısı, cache davranışı, üretim (render) maliyeti ve veri aktarımı üzerinde doğrudan etkiler yaratır. Bu yazıda, lazy loading’in sunucu performansına etkisini net ölçümlerle ele alacak; hangi senaryolarda kazanç sağladığını, hangi senaryolarda ters teptiğini açıklayacağız.

Amaç: Lazy loading kararını “teori” yerine ölçümle vermek. Bunun için log, cache ve CDN davranışını beraber izleyeceksiniz.

Lazy loading sunucu tarafında neyi değiştirir?

Lazy loading’in tarayıcıda gördüğünüz etkisi (sayfanın ilk yüklenmesi hızlı görünür) olsa da asıl değişim, sayfanın sonraki aşamalarında sunucuya giden HTTP isteklerinin türü ve zamanlamasıdır.

Sunucu tarafında başlıca değişenler:

İstek sayısı (request count): Görünmeyen görseller/iframe/video bileşenleri başlangıçta yüklenmez; sonradan ayrı isteklerle gelir.
Zamanlama (timing): İlk TTFB (Time To First Byte) gecikebilir veya değişebilir; asıl kullanıcı etkileşimiyle birlikte ikinci dalga istek oluşur.
Cache isabet oranı (cache hit ratio): Özellikle görsel URL’leri farklıysa veya varyant (sürüm/dil/format) sayısı artıyorsa cache hit düşebilir.
Sunucu tarafı üretim maliyeti: Image resize, thumbnail üretimi, template render veya stream üzerinden gelen içeriklerde “lazy aşaması” ek yük getirebilir.
Bant ve concurrency: İsteklerin başlangıçta ertelenmesi bant kullanımını azaltabilir; fakat ikinci dalga eşzamanlılık (concurrency) oluşturursa CPU/IO ve bağlantı havuzunu zorlayabilir.

“Sunucu daha az çalışır” her zaman doğru mu?

Hayır. Lazy loading genellikle ilk sayfa ağırlığını azaltır; bu, ilk dalgada sunucunun daha az iş üretmesi anlamına gelebilir. Fakat şu koşullarda sunucu toplamda daha çok iş yapabilir:

Lazy yüklenen içerikler için resize/transform pipeline her istekle yeniden çalışıyorsa (cache kapalıysa veya değişken URL yüzünden isabet düşükse), toplam CPU artar.
Lazy içerikler “tek bir paket” halinde gelirken (ör. aynı endpointten toplu) şimdi ayrı endpointlere bölünüyorsa istek sayısı artar.
Kullanıcılar sayfayı hızlıca aşağı kaydırdığında, ikinci dalga kısa sürede çok fazla istek oluşturur; bu da worker sayısı ve bağlantı limitlerini zorlar.

Hangi metriklerle sunucu etkisini net ölçmelisiniz?

Lazy loading değerlendirmesi “sayfa hızı” gibi tek bir metriğe bırakılmamalıdır. Sunucu etkisini doğrulamak için en az şu üç katmanı ölçün: CDN/edge, uygulama (app) ve sistem (OS/IO).

Uygulama ve trafik metrikleri

Toplam istek sayısı (requests/sec): İkinci dalgada belirgin artış var mı?
5xx/4xx oranı: Zorlanma varsa hata kodları yükselir.
TTFB ve upstream time (ör. Nginx upstream response time): İlk yanıt değişiyor mu?
İstek başına CPU zamanı: Dinamik içeriklerde (ör. görsel resize) artış görürsünüz.

Cache davranışı metrikleri

Cache hit/miss oranı: Lazy yüklenen görsel URL’leri cache’i vuruyor mu?
Bölgeler arası varyant: Aynı görselin farklı format (WebP/AVIF) veya boyut varyantları cache hit’i düşürür.

Sistem metrikleri (Linux)

CPU load / %user-%system: En yoğun an ikinci dalgada mı geliyor?
Disk IOPS ve wait: Thumbnail üretimi diskten besleniyorsa IO bekleme artabilir.
Network throughput: İstek sayısı artsa da ilk dalga hafifse bant toplamı yine de yükselir mi?

Pratik hedef: Lazy loading’i devreye aldıktan sonra “toplam” (p95/p99) değerleri izleyin. Ortalama değer tek başına yanıltır.

Senaryolara göre lazy loading’in etkisi: Kazanç mı yük mü?

Aşağıdaki tablo, sunucu tarafında beklenen yönü hızlı görmeniz için hazırlanmıştır. “Etki” ifadesi, doğru cache ve CDN kurulumuna göre değişir.

Senaryo	Varsayım	Sunucu tarafı olası etkisi	Risk/İpucu
Sayfada çok sayıda görsel (thumbnail hazır)	CDN + doğru cache header var	İyi senaryoda: ilk dalga hafifler, toplam bant benzer kalır	Görsel URL’leri sabit kalmalı; varyant sayısını kontrol edin
Image resize/transform dinamik	Resize sonucu cache edilmiyor	Kötü senaryoda: ikinci dalga CPU/IO’yu artırır	Resize’ı üretim sonrası cache edin (cache-aside)
HTML içinde inline embed (iframe/video)	Lazy ile iframe kaynakları ayrı	Orta: istek sayısı artar, TTFB/ilk render toparlar	Rate limit ve bağlantı havuzu ayarlarını kontrol edin
Çoklu dil + görsel boyut/format varyantı	Cache varyant sayısı yüksek	Kötü senaryoda: cache miss yükselir	Varyantları azaltan URL stratejisi uygulayın
Backend API çağrıları lazy tetikleniyor	API cevapları cache’siz	Kötü senaryoda: backend sorguları patlar	API’lere kısa süreli cache katmanı ekleyin

Hangi iş türleri özellikle etkilenir?

Lazy loading ile genelde şu bileşenler ertelenir: görseller, script harici bileşenler, iframe’ler ve bazı veri istekleri.

Görsel pipeline: Resize/format (WebP/AVIF) üretimi varsa en kritik alan burası.
Template veya proxy akışları: Görsel/iframe içerikleri proxy’den geliyorsa upstream bekleme artabilir.
Backend API: Sayfa scroll ile yeni endpointler çağırıyorsa, sorgu optimizasyonu ve cache şart olur.

Doğru kurulum: Sunucu yükünü artırmadan lazy loading

Lazy loading başarısı, “lazy tag koyma” değil; isteklerin sunucu üzerinde nasıl yönetildiğine bağlıdır. Aşağıdaki kontrol maddeleri sunucu tarafı performansı korumaya yöneliktir.

1) Görsel transform ve cache stratejisini netleştirin

Görselleri sunucuda yeniden boyutlandırıyorsanız (ör. ImageMagick, libvips veya uygulama içi transform), sonuçların cache edilmesi gerekir.

Uygulanacak net adımlar: - Lazy ile gelen görsellerin aynı URL üzerinden sunulmasını hedefleyin. - CDN veya uygulama katmanında “resize sonucu” cache edilsin. - Cache sürelerini statik sayılara bağlayın: görsel içeriği değişmiyorsa uzun süreli cache (ör. günler) mantıklıdır.

Örnek kontrol: - Lazy yüklenen bir görseli açtığınızda, ilk istek transform üretip “miss” veriyor; ikinci denemede “hit” görüyor musunuz? - “Miss” sürekli devam ediyorsa URL varyantları veya cache header sorunludur.

2) CDN ile edge’den servis alın

Lazy ile ikinci dalgada gelecek istekler, CDN tarafından karşılandığında sunucu üzerindeki yük azalır.

Net kontrol: - CDN loglarında bu görsel/iframe isteklerinin bir kısmı edge’den dönüyor mu? - Upstream (origin) oranı yükseliyor mu?

CDN kullanmak tek başına çözüm değildir; cache ayarları doğru olmalıdır. Örneğin aynı görselin farklı query string’lerle gelmesi cache’i bozar.

3) Rate limit ve concurrency yönetimini gözden geçirin

Lazy loading ikinci dalgada yoğun istek üretir. Kullanıcılar aynı sayfayı hızlıca gezdiğinde, aynı anda birçok görsel/iframe talebi birikebilir.

Sunucu tarafı önlem: - Web sunucusu (Nginx/Apache) ve uygulama katmanında worker/thread limitleri ile upstream timeout değerlerini test edin. - Uygulama endpointlerinde (özellikle resize/thumbnail veya API) kısa süreli cache yoksa, ikinci dalgada backend sorguları artar.

4) “Sahneye göre erteleme” uygulayın

Her içerik aynı gecikme toleransına sahip değildir.

Net yaklaşım: - Kritik içeriği (ilk ekranın anlaşılması için gerekli görseller) ilk aşamada verin. - Aşağı kaydıkça görünen galeriler, ek modüller, yorum görselleri gibi bileşenleri lazy yapın.

Bu sayede ikinci dalgada gelen istek sayısı kontrol edilebilir seviyede kalır.

5) Ölçüm planı kurun: A/B değilse bile karşılaştırma şart

Lazy loading’i devreye aldığınızda şu şekilde ilerleyin:

Değişiklik öncesi ve sonrası arasında aynı saatlerde ölçüm yapın.
Yalnızca ortalama değil p95/p99 istek gecikmelerini izleyin.
Cache hit ratio, upstream time, 5xx oranı gibi sunucu metriklerini yan yana görün.

Eğer ikinci dalgada p99 upstream time yükseliyorsa, lazy loading “ilk sayfa hızını” iyileştiriyor olsa bile sunucu tarafında toplam performans düşüyor olabilir.

NetKıyas ile karşılaştırma yaparken lazy loading etkisini sağlayıcıdan nasıl ayırırsınız?

Lazy loading’in sunucu performansına etkisi, seçtiğiniz hosting türüne göre değişir. Ancak bunu yanlış yorumlamak kolaydır; bu nedenle sağlayıcı karşılaştırmasında şunları ayırın:

Uygulama performansı (CPU/IO ve worker kapasitesi)
Cache/CDN altyapısı
Aktarım ve gecikme (latency) karakteristiği

VDS/VPS vs Shared: nerede daha farklı görülür?

Faktör	Shared ortam	VDS/VPS/dedicated	Etki
İkinci dalga istek yoğunluğu	Aynı sunucuda diğer sitelerden etkilenme artar	Kaynaklar daha öngörülebilir	Lazy loading faydası daha net ölçülebilir
CPU/IO paylaşımları	“Komşu” etkisi görebilirsiniz	Daha kontrol edilebilir	Transform/resize daha stabil olur
Cache yönetimi	Kısıtlar olabilir	Konfigürasyon daha esnektir	Görsel cache stratejisi uygulanabilir

Bu nedenle lazy loading optimizasyonuna başlamadan önce, mevcut kurulumunuzda cache ve CDN davranışı düzgün mü sorusunu netleştirin. Sonra kaynak yönetimi (worker, limit, IO) tarafına geçin.

Sık yapılan 6 hata (sunucu tarafı performansı bozar)

Sürekli cache miss: Görsel URL varyantları yüzünden cache hiç dolmuyor.
Dinamik resize’ı cache etmemek: Lazy ile ikinci dalgada CPU/IO patlıyor.
Çok agresif lazy: İlk ekranın anlaşılmasını bozan, ama sunucudan tekrar tekrar istek çıkaran bir yapı kuruluyor.
API cevaplarını cache etmemek: Scroll ile tetiklenen istekler backend’i yüklüyor.
Timeout/keep-alive uyumsuzluğu: İkinci dalgada bağlantılar uzuyor, workerlar bekliyor.
Yanlış metrikle karar vermek: Sadece ilk sayfa hızı ölçülüp p95/p99 ve upstream time izlenmiyor.

Son kontrol listesi: Lazy loading’i devreye almadan önce ve sonra

Aşağıdaki listeyi, kendi sitenize uygun şekilde doldurun.

Devreye almadan önce

[ ] Lazy yüklenen görseller için transform (resize/format) varsa sonucu cache ediliyor
[ ] CDN cache davranışı test edildi (hit/miss gözlendi)
[ ] Lazy ile artacak istek sayısı için concurrency limitler planlandı
[ ] URL stratejisi sabit ve varyant sayısı kontrol altında
[ ] Kritik içerikler ilk ekrana taşınıyor (her şey lazy yapılmıyor)

Devreye aldıktan sonra

[ ] p95/p99 upstream time ikinci dalgada artıyor mu?
[ ] 5xx oranı yükseldi mi?
[ ] CPU/IO yükü pik yapıyor mu ve zamanlaması lazy tetiklerine denk mi?
[ ] Cache hit ratio stabil mi?
[ ] Kullanıcı scroll senaryosunda (hızlı gezinti) sistem yavaşlıyor mu?

Sonuç: Lazy loading kararını “istek dalgaları” üzerinden verin

Lazy loading sunucu tarafında tek başına iyi ya da kötü değildir. Kazancı, ikinci dalgada gelecek isteklerin CDN ve cache ile karşılanması; dinamik üretim işlerinin (özellikle görsel resize) cache’e alınması ve concurrency limitlerinin doğru yönetilmesi sağlar. Aksine, cache miss ve dinamik transform yoksa sunucu toplamda daha zorlanır.

En doğru aksiyon: Lazy loading’i planladığınız bileşenler için önce cache/CDN davranışını test edin; sonra A/B şart değil ama önce-sonra ölçüm yaparak p95/p99 upstream time ve cache hit ratio sonuçlarını karşılaştırın. Bu ölçüme göre devam edin ya da kapsamı (hangi içerikleri lazy yaptığınız) daraltın.