Browser Cache Nasıl Çalışır? Cache-Control Rehberi

Browser cache nasıl çalışır?

Tarayıcı önbelleği, daha önce indirilen kaynakları yerel olarak saklayarak sonraki ziyaretlerde aynı dosyayı sunucudan tekrar indirmeden kullanmayı sağlar. Bu sayede ikinci ziyarette sayfa çok daha hızlı yüklenir; ağ trafiği azalır, sunucu yükü düşer.

Bir kaynak tarayıcıya ilk kez ulaştığında sunucu, yanıt başlıklarıyla o kaynağın ne kadar süre geçerli kalacağını bildirir. Tarayıcı bu talimatı okur ve kaynağı önbelleğe alır. Sonraki ziyarette tarayıcı önce kendi önbelleğine bakar: kaynak hâlâ "taze" (fresh) ise ağa hiç istek göndermeden doğrudan önbellekten kullanır. Kaynak "bayatlamışsa" (stale) ise sunucuya doğrulama isteği gönderir.

Doğrulama süreci iki mekanizma üzerinden yürür. ETag başlığı kaynağın parmak izini içerir; tarayıcı If-None-Match başlığıyla bu değeri sunucuya gönderir. Kaynak değişmemişse sunucu yalnızca "304 Not Modified" yanıtı döndürür; dosyanın tamamı tekrar indirilmez. Last-Modified başlığı benzer biçimde çalışır; tarih karşılaştırması yaparak kaynağın güncellenip güncellenmediğini belirler.

Cache-Control direktifleri ne anlama gelir?

Cache-Control başlığı, önbellek davranışını kontrol eden en temel araçtır. Birden fazla direktif birlikte kullanılabilir; ancak bunların birbirini nasıl etkilediğini anlamak doğru politika kurmak için şarttır.

max-age direktifi, kaynağın kaç saniye boyunca taze sayılacağını belirtir. max-age=31536000 bir yıllık geçerlilik süresi demektir; versiyonlanmış statik dosyalar için uygundur. no-cache adından yanıltıcı biçimde önbelleği tamamen devre dışı bırakmaz; kaynağı önbelleğe alır ama her kullanımda sunucuyla doğrulama yapılmasını zorunlu kılar. no-store ise kaynağı hiç önbelleğe almaz; hassas veriler içeren yanıtlar için kullanılır.

immutable direktifi modern bir eklentidir. Tarayıcıya "bu dosya hiçbir zaman değişmeyecek, yeniden doğrulama yapma" talimatı verir. Versiyonlanmış dosyalarda kullanıldığında sayfa yenilemelerinde bile gereksiz ağ isteklerini önler. public direktifi kaynağın CDN dahil tüm ara önbellek katmanlarında saklanabileceğini; private ise yalnızca tarayıcı önbelleğine alınması gerektiğini belirtir.

• Statik varlıklar (versiyonlu): Cache-Control: public, max-age=31536000, immutable — bir yıl, CDN dahil her yerde, değişmez.
• HTML sayfaları: Cache-Control: no-cache — önbelleğe alınır ama her seferinde sunucuyla doğrulama yapılır.
• Hassas içerikler (ödeme, oturum): Cache-Control: no-store — hiç önbelleğe alınmaz.
• API yanıtları (kısa ömürlü): Cache-Control: public, max-age=300, stale-while-revalidate=60 — 5 dakika taze, arka planda yenilenirken 1 dakika daha eski sürüm sunulabilir.

Cache busting ve versiyonlama stratejisi

Uzun süreli önbellekleme ile güncellik arasındaki dengeyi kurmak, cache yönetiminin en kritik noktasıdır. Bir dosyayı bir yıllık önbellekle gönderirseniz ama dosya değişirse kullanıcılar eski sürümü görmeye devam eder. Cache busting bu sorunu çözer: dosya değiştiğinde URL değiştirilir, tarayıcı yeni URL'yi hiç görmediği için önbellekte aramaz ve sunucudan indirir.

İçerik karması (content hash) tabanlı versiyonlama en güvenilir yöntemdir. Dosyanın içeriğinden üretilen bir hash değeri dosya adına eklenir. Örneğin main.a3f9c2d.js. Webpack, Vite ve Parcel gibi modern derleme araçları bu işlemi otomatik olarak yapar. Dosya içeriği değişmediği sürece hash değişmez; bir karakter bile değişirse yeni hash üretilir.

Sorgu parametresi tabanlı versiyonlama (style.css?v=3) daha basit görünse de bazı CDN'ler ve proxy sunucular query string'leri dikkate almadan önbelleğe alabilir. Bu nedenle dosya adında hash tercih edilmesi daha güvenilir sonuç verir.

• JS ve CSS için içerik hash: Derleme aracına hash oluşturmayı etkinleştirin, her değişiklikle yeni benzersiz URL üretilsin.
• Görseller için hash veya sürüm dizini: Görsel güncellendiğinde yeni URL kullanın; eski URL önbellekte kalmaya devam eder ama artık kullanılmaz.
• HTML dosyaları için no-cache: HTML içeriği CDN'de kısa süreli veya no-cache ile tutulmalı; aksi hâlde güncellenen JS/CSS dosyalarına işaret eden yeni HTML kullanıcıya ulaşmaz.
• Purge mekanizması: CDN kullanıyorsanız acil durumlarda belirli URL'leri önbellekten temizlemek için purge API'sini hazır bulundurun.

Tekrar ziyaret davranışını ölçmeden cache politikası belirlemek zordur

Tek sayı üzerinden acele karar vermek yerine dağılıma bakın. Mobil tarafta düşük işlem gücü ve ağ dalgalanması, masaüstünde görünmeyen gecikmeleri büyütebilir. Birçok ekip iyileştirme adımına hızla geçer; sorunun kaynak katmanını netleştirmeden yapılan değişiklikler ise kısa süreli rahatlama sağlar.

Önce gözlemi kayıt altına alın. Ölçüm tarihi, cihaz tipi, sayfa türü ve metrik sonucu birlikte tutulduğunda hangi adımın gerçekten fayda sağladığı açık biçimde görünür. Kalıcı ilerleme bu disiplinle gelir.

• Gerçek kullanıcı verisi: Chrome UX Report verisini 28 günlük periyotlarda takip edin. P75 değeri 2.5 saniyenin altında mı?
• Laboratuvar testi: Lighthouse skorunu mobil ve masaüstü için ayrı ölçün. Throttling ayarlarını gerçek kullanıcı profilinize göre yapılandırın.
• Cihaz kırılımı: Düşük, orta ve yüksek performanslı cihazlarda ayrı test senaryoları oluşturun.
• Zaman karşılaştırması: Her değişiklik öncesi baseline ölçümü kaydedin, 7 gün sonra tekrar ölçün.

Dağılıma bakmadan tek sayıyla karar vermek, rastgele sonuç üretir.

Önbelleği etkileyen katmanları birbirinden ayırın

Render blocking kaynak analizi ve critical CSS uygulama rehberi birlikte incelendiğinde öncelik sırası daha net çıkar.

Ağır medya dosyaları yüklenme süresini artırır. Bloklayan JavaScript render'ı geciktirir, ana iş parçacığı yükü etkileşim metriklerini bozar, sunucu gecikmesi ise TTFB'yi yükseltir. Tüm bunlar önbellek stratejisini etkiler.

• Ağır medya: 1MB üzeri görseller varsa WebP'ye çevirin. Video için adaptive streaming kullanın.
• Bloklayan kaynak: CSS'i critical/non-critical olarak ayırın. JavaScript'i defer veya async ile yükleyin.
• Ana iş parçacığı yükü: Chrome DevTools Performance sekmesinde Long Task'leri tespit edin. 50ms üzeri görevleri parçalayın.
• Sunucu gecikmesi: TTFB 600ms üzerindeyse CDN kullanın veya sunucu tarafı önbellek ekleyin.

Her katmanın ayrı çözümü var. Hepsini birden düzeltmeye çalışmayın.

Dosya sınıfına göre TTL belirlerken etki ve riski dengeleyin

Her iyileştirme adımının etkisi farklıdır. Gerçek kullanıcı verisinde açıkça görülür.

Bazı değişiklikler büyük etki yaratır ama uygulama maliyeti yüksektir. Bazıları düşük risklidir ama geri dönüş süresi uzundur. Önceliklendirme matrisini net kurmadan iyileştirmeye başlamak, kaynakları yanlış alana harcamak demektir.

• Etki büyüklüğü: Değişiklik LCP'yi 500ms düşürüyorsa yüksek etki. 50ms düşürüyorsa düşük etki. Önce yüksek etkili adımları uygulayın.
• Uygulama maliyeti: Cache-Control header eklemek 1 saatlik iş. Tüm görselleri WebP'ye çevirmek 2 haftalık iş. Maliyeti düşük olanı önce yapın.
• Risk seviyesi: Statik varlık önbelleği düşük risk. Dinamik içerik önbelleği yüksek risk. Düşük riskli adımları önce test edin.
• Geri dönüş süresi: Header değişikliği 5 dakikada geri alınır. CDN konfigürasyonu 1 saatte geri alınır. Hızlı geri alınabilen adımları önce deneyin.

Yüksek etki + düşük maliyet + düşük risk = ilk adım.

Cache konfigürasyon değişikliklerini sınırlı trafikle test edin

Büyük değişiklikler birden uygulandığında hangi adımın fayda sağladığını, hangisinin sorun ürettiğini ayırt etmek zorlaşır. Küçük adımlar her birinin etkisini net gösterir; iyileştirme kalitesini belirleyen de bu yaklaşımdır.

• Aşamalı yayın: Önce %5 trafiğe açın. 24 saat sonra %25'e çıkarın. Sorun yoksa %100'e çıkarın.
• Önce test sonra canlı: Staging ortamında 3 gün test edin. Gerçek kullanıcı verisi toplamadan canlıya almayın.
• Regresyon kontrolü: Her değişiklik sonrası tüm metrikleri kontrol edin. LCP düzelirken CLS bozulmuş olabilir.
• Geri alma planı: Her değişiklik için geri alma senaryosu hazırlayın. Sorun çıkarsa 5 dakikada geri alabilmeli.

Bir metrik düzelirken diğeri bozulabilir. Hepsini izleyin.

Lab testi ile gerçek ziyaretçi davranışı farklı veri üretir

Lighthouse raporunu doğru okuma ve TTFB katmanlarını ayırma yaklaşımı, önbellek kararlarının yanlış metrikle alınmasını engeller.

Tek ölçüm yanılgısı en yaygın hatadır. Bir kez ölçüp karar vermek rastgele sonuç üretir. Aşırı ortalama kullanımı ise gerçek kullanıcı deneyimini gizler; P75 ve P95 değerlerine bakın.

• Tek ölçüm yanılgısı: Lighthouse skorunu 5 kez çalıştırın. Ortalamasını alın. Tek ölçüm güvenilir değil.
• Aşırı ortalama kullanımı: Ortalama LCP 2.5 saniye olabilir ama P95 değeri 8 saniye olabilir. P75 ve P95'e bakın.
• Coğrafya farkı: Avrupa'dan hızlı olan site Asya'dan yavaş olabilir. Farklı bölgelerden test edin.
• Cihaz sınıfı etkisi: iPhone 14'te hızlı olan site Android Go cihazında yavaş olabilir. Düşük performanslı cihazlarda test edin.

Ortalama 2.5 saniye ama %25 kullanıcı 8 saniye bekliyor? Sorun var.

Önbellek politikası düzenli gözden geçirilmeden eskir

Bir kez düzeltip unutursanız, yeni özellikler performans çizgisini bozar. Süreklilik modeli kurmak, her yayında önbellek kurallarını da kontrol etmek demektir.

• Haftalık denetim: Her Pazartesi Chrome UX Report verisini kontrol edin. P75 değeri eşiğin üzerine çıkmış mı?
• Yayın öncesi kontrol: Her deployment öncesi Lighthouse skorunu çalıştırın. Skor 10 puan düşmüşse yayını durdurun.
• Otomatik alarm: LCP 2.5 saniyeyi geçerse Slack'e bildirim gönderin. TTFB 600ms'yi geçerse e-posta gönderin.
• Dokümantasyon disiplini: Her değişikliği performance-log.md dosyasına kaydedin. Tarih, değişiklik, metrik sonucu yazın.

Otomatik alarm yoksa sorun fark edilmeden büyür.