Cache Prewarming ile TTFB’yi İstikrarlı Düşürme Rehberi (2026)

Cache prewarming (ön ısıtma), CDN ve uygulama önbelleği boşken oluşan ilk istek gecikmesini azaltmak için tasarlanmış bir tekniktir. Son kullanıcı açısından ölçülen sonuç genellikle TTFB (Time to First Byte) ve sayfa yüklenme tutarlılığıdır. Bu rehberde, prewarming’in hangi katmanda yapılacağını, hangi uçları (URL) ısıtmanız gerektiğini, ne zaman/kaç kez koşmanız gerektiğini ve doğrulamayı net bir kontrol listesiyle öğreneceksiniz.

Aşağıdaki adımlar, “ilk ziyaretlerde yavaşlık” problemi yaşayan; CDN miss oranı, origin (ana sunucu) yükü veya ölçeklenebilirlik açısından daha öngörülebilir performans isteyen ekipler içindir.

Cache prewarming neyi çözer?

Cache prewarming, cache’in “boş geldiği” anlarda oluşan ilk kullanıcı cezasını hedefler. Bu boş durumlar şunlarla tetiklenir: - Yeni dağıtım (deployment) sonrası uygulama cache’inin boşalması - Sunucu/VM ölçekleme (scale-out) ve yeni instance başlatılması - CDN’de purge (temizleme), bant genişliği tasarrufu için TTL dolumu veya invalidation - Yeni bir bölge (region/POP) veya yeni edge cache havuzu devreye girmesi - Bakım/yeniden başlatma sonrası application cache’in sıfırlanması

Önemli nokta: Prewarming tek başına “daha hızlı internet” değildir. Asıl hedef, uygulama ve kenar (edge) katmanında cache miss’i azaltmaktır. Sonuç olarak: - İlk isteklerde origin’den veri çekilmesi azalır - TTFB daha kısa olur - CDN’den yanıt dönme olasılığı yükselir - Origin üzerindeki ani yük tepe noktaları düşer

Prewarming hangi önbellek türlerinde işe yarar?

Prewarming stratejisi, kullandığınız cache katmanına göre değişir. - CDN cache: Statik içerik (CSS/JS/IMG) ve bazı dinamik yanıtlar edge’de tutuluyorsa etkisi büyüktür. - Reverse proxy cache (Nginx/LiteSpeed/varnish): Uygulama önünde cache tutuluyorsa doğrudan hızlanma sağlar. - Uygulama cache’i (ör. Redis/Memcached): Öğrenilen veriler veya hesaplanan şablonlar cache’leniyorsa işe yarar; ancak doğru anahtar (key) ve TTL gerektirir. - Tarayıcı cache’i: Genellikle sunucu tarafı prewarming ile değil, doğru HTTP header’larıyla çözülür.

Hangi metriklerle “başarılı” olduğunu anlarsınız?

Prewarming planlaması, ölçüm olmadan tahmine döner. Şu metrikleri hedefleyin:

1) CDN cache hit oranı ve miss oranı

• Hedef: Prewarming öncesi miss gören URL gruplarında hit oranını artırmak.
• Ne zaman raporlayın: Prewarming başlamadan önce baseline alın, prewarming sonrası 5-15 dakika içinde doğrulayın.

2) TTFB dağılımı (median + p95)

• Median: Ortalama kullanıcı deneyimi için.
• p95: Stres anlarını veya varyansı görmek için.
• Hedef: En azından p95 TTFB’yi düşürmek.

3) Origin (ana sunucu) istek sayısı ve CPU/RAM

• Hedef: Prewarming ile birlikte origin’e giden isteklerin azalması.
• Özellikle: “ölçekleme sonrası ilk dakika” gibi dönemlerde origin yükünü düşürmek.

4) 4xx/5xx ve doğrulama başarısı

Prewarming istekleri kaynakları tüketebilir. Bu yüzden: - Hedef: 200/204 oranı yüksek, 4xx/5xx düşük. - Yanlış cache header’ı veya auth durumu varsa prewarming “yarardan çok zarar” üretebilir.

URL seçimi: Tüm sayfaları ısıtmak gereksizdir

En sık yapılan hata, tüm URL’leri tek seferde prewarm etmektir. Bu yaklaşım hem maliyeti artırır hem de etkisiz URL’leri ısıtarak değer üretmez.

Aşağıdaki URL tipleri genelde en yüksek getiriyi verir: - Ana sayfa, kategori sayfaları, landing sayfaları - Popüler blog yazıları / rehberler - Arama sonuçlarında cachelenebilen statik parametreli sayfalar (tasarıma bağlı) - Ürüne giriş / en çok görüntülenen SKU sayfaları - Büyük görsel/indirilebilir dosyaların bulunduğu sayfalar

Aşağıdaki URL tiplerinde dikkat: - Kullanıcıya özel içerik (kişiselleştirme): Auth/cookie ile değişen çıktı genellikle prewarm için uygun değildir. - Çok dinamik ve sürekli değişen sayfalar: TTL kısa ise prewarming hız kazandırmayabilir. - Aşırı sayıda benzersiz URL üretenler (ör. tracking parametreleri): Cache parçalanması (fragmentation) yaratır.

Cache parçalanmasını engelleme (fragmentation)

Prewarming yaparken varyans (vary) ve cache anahtarı davranışını netleştirin: - Cache anahtarında hangi header/cookie’ler var? Vary eden her şey cache’i böler. - CDN’de “Cache key” ayarınız URL path mi yoksa query string mi kullanıyor? - Query string’leri azaltmak için routing/redirect stratejileri uygulanabiliyor mu?

Ne zaman prewarm yapmalısınız? (Zamanlama kuralı)

Prewarming’in etkisi, cache boşken gelirseniz maksimum olur. Bu yüzden doğru tetikleme stratejisini uygulayın.

A) Deployment sonrası

Kural: Deployment tamamlandıktan sonra önce “sağlık kontrolü (health check)” geçsin, sonra prewarm başlasın. - Yarar: Yeni instance’larda cache en kısa sürede dolar. - Uygulama: CI/CD pipeline içinde “cache warmup job” ekleyin.

B) Ölçekleme (scale-out) sonrası

Kural: Yeni instance trafik almadan önce ısıtın. - Otomasyon: Auto-scaling hook ile warmup çalıştırın. - Not: Warmup süresince instance hedef kapasiteye göre yüklenebilir; rate limit koyun.

C) CDN purge/invalidation sonrası

Kural: Purge sonrası kısa süre içinde warmup yapın. - Yarar: İlk kullanıcıların miss yaşamasını engeller. - Pratik: Purge ettiğiniz içerik setine göre sadece ilgili URL gruplarını ısıtın.

Uygulama stratejileri: “nasıl” yapılır?

Prewarming’i manuel yapmak yerine tekrarlanabilir bir süreç haline getirin. Burada hedef; kontrol, ölçek ve ölçüm.

1) Warmup job (HTTP isteği) yaklaşımı

Çalışan bir job, hedef URL’lere istek gönderir ve cache’in doldurulmasını tetikler.

Örnek mantık (gerçek ortamda domain/IP ve path’leri uyarlayın): - Hedef URL listesi: home, category/*, top-articles/* - İstek hızı: saniyede X istek (ör. 10-50) ile sınırlayın - Timeout: ör. 2-5 saniye - Bekleme: bazı URL’lerin cachelenmesi için küçük gecikme yeterli olabilir

Aşağıdaki gibi bir pseudo örnek akıl verir:

# Warmup listesi örneği: urls.txt
# Her satır bir URL
# Not: Gerçek kullanımda rate limit ve timeout ayarlayın.
while read -r url; do
  curl -sS -o /dev/null -w "%{http_code} %{time_total}\n" "$url" &
  # Paralel istek sayısını sınırlamak için uygun mekanizma kullanın
  sleep 0.2
done < urls.txt
wait

2) Cache anahtarlarını (key) doğru oluşturma

Eğer uygulama cache kullanıyorsanız prewarming’in değeri, doğru key’lere veri yazabilmesine bağlıdır. - Redis’te key formatı: “tenant + path + parametre + sürüm” gibi bileşenler içeriyor mu? - Sürümleme: Yeni sürüm sonrası eski key’ler cache’lenmiş içerik üretiyor mu? Veya doğru şekilde temizleniyor mu? - TTL: Prewarming ile gelen veri ne kadar süre taze kalacak?

3) Cache header’larıyla uyum

Prewarming bazen “işlem yapıldı ama cache dolmadı” şeklinde sonuç verir. Bunun tipik nedenleri: - Yanlış Cache-Control değerleri: no-store, private veya kısa TTL - CDN’de cachelenmeme kuralları (ör. bazı status kodlarında cache etmeme) - Vary ayarları (ör. Vary: Cookie yanlışlıkla key’i böler)

Kontrol: Prewarming sonrası ilgili URL için yanıt header’larını inceleyin. - CDN tarafında: “HIT/MISS” işaretleri görünür olmalı - Origin/uygulama tarafında: Cache-Control, ETag, Last-Modified mantıklı çalışmalı

Ölçüm ve doğrulama: Prewarm gerçekten hızlandırıyor mu?

Prewarming’i başarıya bağlamak için şu test planını kullanın.

1) Baseline alın

• Prewarming öncesi: seçtiğiniz 20-100 URL’de TTFB ölçün.
• Aynı kullanıcı davranışı gerekmez; URL başına ölçüm yeterlidir.

2) Cache boşaltmayı kontrol edin

• CDN purge sonrası prewarming mi yapıyorsunuz, deployment sonrası mı?
• Cache boşaltma tam mı? (bazı katmanlarda dolu kalabilir)

3) Prewarm çalıştırın ve 10-20 dakika bekleyin

• Her URL hemen cache’e düşmeyebilir. Uygulama ve CDN propagation süresi vardır.

4) Prewarming sonrası raporlayın

• TTFB p95 düşmüş mü?
• CDN cache hit oranı yükselmiş mi?
• Origin CPU/RAM ve istek sayısı azalmış mı?

Prewarming için pratik kontrol listesi (net)

Aşağıdaki listeyi “hazır” kabul etmeyin; her maddede “evet/hayır” yanıtı alın.

Hazırlık

• [ ] Öncelikli URL seti belirlendi (top sayfalar + en çok gelen landing’ler)
• [ ] Auth/kişiselleştirme içeren URL’ler listeden çıkarıldı
• [ ] Cache key parçalanmasına neden olan query/cookie davranışları gözden geçirildi

Uygulama

• [ ] Warmup job rate limit ile çalışıyor (ör. saniyede 10-50 istek)
• [ ] Timeout ve retry politikası var (ör. 2-5 sn timeout, maksimum deneme)
• [ ] Deployment/scale-out/purge tetiklerine bağlandı

Ölçüm

• [ ] Baseline TTFB ve hit oranları prewarm öncesi kaydedildi
• [ ] Prewarm sonrası p95 TTFB ve CDN hit oranı doğrulandı
• [ ] Origin yükü takip ediliyor (ani tepe azalıyor mu?)

Yaygın hatalar ve net çözümler

Hata 1: “Her şeyi ısıtmak”

Belirti: Warmup job aşırı uzun sürer, origin load yükselir, CDN maliyeti artar. Çözüm: En yüksek trafik/gelir etkisi olan URL’leri seçin; geri kalanını gerçek trafik gelsin.

Hata 2: Yanlış cache header’ları

Belirti: Warmup sonrası CDN’de yine miss görülür. Çözüm: Cache-Control, Vary ve CDN cache rule setini düzeltin. Warmup, cache’lenmiyorsa anlam taşımaz.

Hata 3: Auth ile değişen içerikleri ısıtmak

Belirti: Cookie varyansı nedeniyle cache parçalanır; bazı istekler 401/403 döner. Çözüm: Cookie’ye bağlı çıktıları hedeflemeyin. Public sayfalar için warmup yapın.

Hata 4: Uygulama cache TTL çok kısa

Belirti: Prewarm sonrası düzelme kısa sürer. Çözüm: TTL stratejisini güncelleyin; cache invalidation ile uyumlu hale getirin.

Sonuç: Sürekli yüksek performans için “ölçümlü warmup” kurun

Cache prewarming, doğru URL seti ve doğru cache header uyumu ile TTFB tutarlılığını belirgin şekilde artırır. Aksiyon planı olarak şu sırayı izleyin: (1) Baseline ölçümü alın, (2) sadece en değerli URL’leri seçin, (3) deployment/scale-out/purge tetiklerine warmup job bağlayın, (4) prewarm sonrası p95 TTFB ve CDN hit oranını doğrulayın. Bu döngüyü kurduğunuzda “ilk kullanıcı yavaşlığı” problemi kontrol altına girer ve performans dalgalanması azalır.

Eğer NetKıyas’ta kıyasladığınız bir altyapı (VDS/VPS, CDN, reverse proxy) için cache katmanlarını birlikte ele almak isterseniz, kullandığınız sistemde cache nerede tutuluyor (CDN mi, reverse proxy mi, Redis mi) bilgisini netleştirerek prewarming listesini buna göre daraltın.