Cache Prewarming ile Site Hızını Sürekli Yüksek Tutma Rehberi

15.09.2026 itibarıyla kullanıcı beklentisi tek bir şeye dayanıyor: sayfanın ilk yanıtı hızlı gelmeli. CDN ve sunucu cache’leri (bellek/edge) gecikmeyi ciddi azaltır; ancak cache “boşken” ilk istekler bekletir. Cache prewarming (ısınma) tam olarak bu boşluğu kapatır: cache oluşturma sürecini ziyaretçi gelmeden önce tetikleyip TTFB ve yüklenme sürelerini daha tutarlı hale getirir.

Bu rehberde; prewarming’in ne yaptığını, hangi katmanlarda işe yaradığını, doğru kapsamı nasıl seçeceğinizi, hatalı ısınmanın nasıl maliyet doğurduğunu ve pratik bir otomasyon şemasını öğreneceksiniz. Amaç “her şeyi ısıtmak” değil; ölçülebilir biçimde cache hit oranını yükseltmek ve ilk isteklerin yavaş olduğu pencereleri minimize etmektir.

Cache prewarming tam olarak nedir?

Cache prewarming, belirli URL ve varyasyonlar için cache anahtarlarını oluşturmaya yönelik kontrollü istekler (warm-up requests) çalıştırmaktır.

Neyi ısıtır?

Prewarm genellikle şu katmanlardan birinde ya da birkaçında cache oluşturur: - CDN edge cache: Cloudflare benzeri edge katmanında (varsa) içerik hazır olur. - Uygulama cache: Uygulama seviyesinde (ör. sayfa fragmentleri, template çıktıları) önceden üretim. - Veritabanı/bellek cache: Bazı mimarilerde uygulama tarafı cache dolunca DB yükü de düşer (ör. Redis’te key üretimi). - Reverse proxy cache: Nginx/HAProxy gibi katmanlarda “cache fill” süreci.

Prewarm neyi değiştirmez?

Prewarm, bant genişliği veya ağ sorunlarını tek başına çözmez. Aynı zamanda dinamik içeriği “sonsuz” hale getirmez; cache politikasına (TTL, cache-control, varyasyon kuralları) bağlıdır. Yanlış TTL ile yapılan prewarm, cache’i çabuk boşaltır ve etkisi sınırlı kalır.

Neden site hızını sürekli yüksek tutar?

Cache hit oranı yükseldikçe isteklerin daha büyük kısmı “hazır” içerikten servis edilir. Bu da özellikle şu metrikleri etkiler: - TTFB (Time To First Byte): İlk bayt daha erken döner. - P95/P99 gecikmeler: Sadece ortalamayı değil “kuyruk” gecikmelerini iyileştirir. - Origin yükü: CDN veya uygulama cache’i doğru dolunca origin (web server + uygulama + DB) üzerindeki ani yük azalır.

Cache boşluğu hangi durumlarda olur?

Yeni cache oluşturulacak URL’ler ilk kez çağrılır.
Cache TTL dolunca içerik tekrar üretim sürecine girer.
Deploy (kod/tema) sonrası cache anahtarları değişir.
Yeni ülke/dil/cihaz varyasyonları devreye girer.

Bu boşluklar, “özellikle sabah ilk saatler” veya “kampanya başladığında” kullanıcı deneyimini bozar. Prewarm, bu pencereleri kapatır.

Hangi cache’lerde prewarming mantıklı, hangilerinde değil?

Prewarming’in etkisi, cache’in gerçekten yeniden üretilebilir ve deterministik (aynı girişten benzer çıktı üreten) olmasıyla artar. Aşağıdaki tablo, kararınızı hızlandırır.

Durum	Prewarm etkisi	Neden	Yapılacak doğrulama
CDN edge’de cache’lenebilen sayfalar	Yüksek	Edge hit olursa origin beklemez	Edge cache hit % ve TTFB P95
Uygulama seviyesinde template çıktı cache’i	Orta-Yüksek	HTML üretimi azalır	Uygulama CPU ve render süresi
DB sorguları sonuç cache’i (ör. Redis)	Orta	Doğru key üretimi gerekir	Redis hit % ve DB QPS
Tamamen kişiselleştirilmiş sayfalar (kullanıcı bazlı)	Düşük	Varyasyon sayısı aşırı büyür	Varyasyon kartı büyüme hızı
Çok kısa TTL (ör. 5-10 sn)	Düşük	Isınma yetişmeden TTL bitiyor	Etki ölçümü: TTFB farkı
Sürekli değişen stok/fiyat widget’ları	Düşük-Orta	Cache bozulması sık	Widget ayrı cache politikasına alınır

Prewarm “doğru” hedef nasıl seçilir?

Şu öncelik sırasını kullanın: 1. Toplam trafik payı yüksek URL’ler 2. TTFB’si en kötü olan ve cache kaçıran URL’ler 3. Kampanya/yenilenme sırasında hızlı artan sayfalar 4. Cache anahtar sayısı kontrollü olan sayfalar (varyasyon kontrolü)

Prewarming stratejisi: kapsam, varyasyon ve zamanlama

Prewarm başarısı üç şeye bağlıdır: kapsam, varyasyon ve zamanlama. Bunların biri yanlışsa maliyet artar, fayda düşer.

Kapsam: “tüm siteyi” ısıtmayın

Önerilen yaklaşım: - Önce %80 trafik üreten üst sayfaları ısıtın. - Sonra haftalık/iki haftalık periyotla genişletin. - Yeni URL keşfi için otomatik bir “gözlem → ekleme” döngüsü kurun.

Örnek hedef: İlk etapta 200-500 URL ile başlayın. Bu rakam, sisteminizin cache fill süresini gözlemlemek için yeterli sinyali üretir.

Varyasyon: dil, ülke, cihaz, oturum

Cache anahtarlarını belirleyen header/cookie/varyasyonları doğru modellemezseniz prewarm “boş” kalır.

Kritik varyasyon örnekleri: - Dil (Accept-Language veya path/query) - Ülke (geolocation veya header) - Cihaz (mobile/desktop ayrımı) - Oturum/kullanıcı etkisi (cookie ile kişiselleştirme)

Net kontrol: - CDN cache davranışında “Vary” ayarlarını inceleyin. - Cache fill isteklerini, gerçek kullanıcıdan gelen en temsili header setiyle atın.

Zamanlama: cache boşalmadan önce

Prewarm zamanını, cache TTL ve yeniden üretim maliyetine göre ayarlayın: - TTL uzun ise: TTL bitmeden 5-15 dakika önce başlatın. - TTL kısa ise: prewarm sıklaşır; bu maliyet doğurur. Bu durumda TTL’i değil, ayrı cache katmanını veya varyasyonu düzeltin.

Aşırı ısınma maliyeti nasıl olur?

Prewarm yanlış kurgulanırsa: - Origin CPU yükselir (template üretimi artar) - DB QPS artar (yanlış sorgu pattern’i çalışır) - CDN rate limit veya origin limitlere takılabilirsiniz

Bunu önlemek için: - Eşzamanlı istek sayısını (concurrency) kademeli artırın - İlk etapta düşük sayıda URL ile başlayın - Sonuç metriklerinde otomatik rollback planı hazırlayın

Uygulama: Prewarming nasıl otomatikleştirilir?

Aşağıdaki şema; en sık kullanılan ve teknik olarak doğrulanabilir yaklaşımdır.

1) Hedef URL listesini üretin

URL listesini trafik loglarından çıkarın: - Son 7/30 gün içinde en çok ziyaret alan sayfalar - Cache hit’i düşük olan sayfalar - TTFB P95 en yüksek sayfalar

Format önerisi: JSON veya CSV. Örnek satır mantığı: - URL - Dil/ülke varyasyonu - Gerekliyse header seti

2) Prewarm isteğini doğru header ile gönderin

Örneğin CDN’in cache anahtarında kullandığı header’lar varsa aynılarını verin. Ayrıca şu ayrımları yapın: - Statik HTML mi, API response mu ısınıyor? - Kişiselleştirmenin girdiği cookie’ler istekten dışarıda mı tutulacak?

3) Eşzamanlılığı kontrollü tutun

Öneri: - İlk denemede 5-10 eşzamanlı istek - Sürekli modda 1-3 eşzamanlı - Origin CPU/Memory ve error oranı izlenerek artırma

4) Sonuçları ölçün

Prewarm sonrası ölçüm planı: - Prewarm öncesi ve sonrası TTFB P95 farkı - CDN edge cache hit oranı - Origin CPU ve DB QPS - 4xx/5xx hata oranı

Prewarm’ın gerçek etkisini görmek için “sadece ortalama”ya bakmayın. Kuyruk gecikmeleri (P95/P99) asıl kriterdir.

Örnek otomasyon senaryosu (Nginx/CDN fark etmeksizin mantık)

Bu bölüm “evrensel” bir mantık sunar. Sistemde hangi katman cache’liyorsa prewarm isteği o katmanda cache fill’i tetikleyecek şekilde ayarlanır.

Uygulama akışı

Cron/CI job her gece başlar.
URL listesini okur.
Her URL için ön tanımlı header ile isteği gönderir.
Başarılı olanları işaretler.
Metrikler eşik altındaysa bir sonraki partiye geçer.

Kontrol edilecek eşikler (net öneri)

5 dakika içinde 5xx oranı %1’i aşarsa dur
Origin CPU ısısı belirlenen limitin üstüne çıkarsa dur
İstek süresi (latency) hedefin üstüne çıkarsa concurrency düşür

İstek örnek mantığı

Aşağıdaki örnek sadece teknik bir “niyet” gösterir; gerçek ortamda endpoint ve header setleri sizdeki cache anahtarına göre uyarlanır.

# Örnek warm-up çağrıları (mantık örneği)
# - İsteği gerçek kullanıcı header’larıyla uyumlu yapın
# - Çok sayıda URL’yi aynı anda göndermeyin
curl -sS -o /dev/null \
  -H "Accept-Language: tr-TR" \
  -H "User-Agent: Mozilla/5.0" \
  "https://ornek-site.com/urunler"

Prewarming ile cache politikası ilişkisi

Prewarming, cache politikanızla birlikte çalışmazsa sonuç zayıflar.

TTL ve cache-control uyumsuzluğu

Örneğin: - TTL 10 dakika ise prewarm 30 dakika önce yapılırsa fayda azalır. - Cache-control “private” ise edge cache doldurma davranışı beklediğiniz gibi olmayabilir.

Kontrol listesi: - HTTP response header’larında Cache-Control ve Vary davranışı doğru mu? - CDN davranışında “cache key” hangi header/cookie ile oluşuyor?

Önceliklendirme: statik içerik vs dinamik parçalar

Prewarm’ın maliyetini düşürmek için dinamik parçaları ayırın: - Sayfa iskeleti cache’lenebilir - Sadece “widget” kısmı kısa TTL veya kişiselleştirme ile gelir

Böylece prewarm yalnızca yoğun üretim gerektiren parçaları ısıtır.

Net kontrol listesi (başlamadan önce)

Aşağıdaki maddeler, gereksiz maliyeti ve boşa çalışmayı engeller.

[ ] Prewarm hedef URL’leri trafik ve TTFB verisiyle seçildi (en az 200 URL)
[ ] CDN/Reverse proxy cache anahtarı hangi header/cookie ile oluşuyor net (Vary ve cache key)
[ ] Kişiselleştirilen içerik, prewarm hedef listesinden çıkarıldı
[ ] Zamanlama TTL’e göre yapıldı (TTL bitmeden 5-15 dk önce)
[ ] Concurrency sınırı var (ilk etap 5-10)
[ ] Origin ve DB metrikleri izleniyor (CPU, QPS, hata oranı)
[ ] Prewarm etkisi ölçülüyor (TTFB P95 + edge hit)
[ ] Rollback planı var (5xx %1, latency eşiği vb.)

Sonuç: Bugün yapılacak aksiyon planı

Cache prewarming, “ilk istekleri” optimize ederek site hızını dalgalanmasız hale getirir. Bugün atabileceğiniz net adımlar şunlar: 1. Son 30 günden en çok gelen 200-500 URL’yi belirleyin. 2. Cache anahtarını oluşturan Vary ve cache-control davranışını kontrol edin. 3. TTL’e göre belirlediğiniz zamanda düşük concurrency ile warm-up otomasyonu başlatın. 4. Prewarm öncesi/sonrası TTFB P95 ve edge cache hit oranını karşılaştırın; eşiklerin üstüne çıkarsa concurrency’i düşürün.

Bu döngüyü kurduğunuzda, cache boşaldığı anlarda bile kullanıcılar daha tutarlı bir hız deneyimi yaşar.