Browser Cache (Tarayıcı Önbelleği) Nasıl Yapılandırılır?

Tarayıcı cache (önbellek), sayfalarınızın ikinci kez açılışını hızlandıran en doğrudan etkili ayarlardan biridir. Yanlış yapılandırma ise eski içeriklerin görünmesine, gereksiz bant genişliği kullanımına ve CDN/geri dönüşlerde performans kayıplarına yol açar. Bu rehberde browser cache’i sunucu tarafında doğru HTTP başlıklarıyla nasıl yöneteceğinizi, uygulama türünüze göre hangi süreleri kullanacağınızı ve sonuçları nasıl doğrulayacağınızı öğreneceksiniz.

Browser cache nedir, hangi katmanda çalışır?

Browser cache; tarayıcının indirdiği kaynakları (HTML, CSS, JS, görseller, fontlar) tekrar istemek yerine yerel depoda saklayıp yeniden kullanmasıdır. Bu davranış “hangi kaynağı ne kadar süre sakla” kararını HTTP yanıt başlıkları belirler.

Tarayıcı şu kararları verir: - Cache-Control: Kaynağı sakla/saklama ve maksimum süre. - ETag: İçerik değiştiğinde doğrulama için sürüm etiketi. - Last-Modified: Dosya zamanına göre doğrulama. - Vary: İçeriğin hangi istek başlıklarına göre farklılaştığını belirtir.

Bu nedenle hedef yalnızca “cache’i açmak” değil; kaynak türüne göre cache stratejisi kurmaktır.

Doğru strateji: Dosya türüne göre cache ayırın

En iyi pratik, tüm kaynaklara aynı önbellek süresini vermemektir. HTML çoğu projede sık değişir; görsel, JS bundle, CSS gibi “derlenmiş” statikler daha uzun süre cache edilebilir.

Aşağıdaki tablo, pratikte kullanılan net bir eşleştirmeyi gösterir:

“immutable” ne zaman kullanılmalı?

immutable direktifini yalnızca dosya URL’si değiştiğinde (ör: app.9f3a1c.js gibi hash’li) yeniden yükleme garanti olduğunda kullanın. URL aynıysa ama içerik değişiyorsa immutable eskiliğe yol açabilir.

Versiyonlama (cache busting) olmadan uzun süreli cache risktir

JS/CSS dosyalarınız URL ile versiyonlanmıyorsa (hash yoksa), max-age=31536000 gibi değerler eski sürümü uzun süre kullanıcıya kilitleyebilir. Öneri: asset’lerde hash’li dosya isimleri kullanın.

Sunucu tarafında Cache-Control, ETag ve Vary nasıl ayarlanır?

Tarayıcı cache’i yönetmek için temel set genelde şu üçlüdür: - Cache-Control (saklama süresi + davranış) - ETag (revalidation/conditional request) - Vary (CDN ve varyant doğru çalışsın)

1) Cache-Control: aralığı kaynak türüne göre belirleyin

Yaygın desenler: - Dinamik içerik: Cache-Control: no-cache, must-revalidate - Kesin saklama istenmeyen: Cache-Control: no-store - Statik ve uzun süre: Cache-Control: public, max-age=31536000, immutable

Uygulama örnek başlık şablonları: - Statik asset için: - Cache-Control: public, max-age=31536000, immutable - Ana HTML için: - Cache-Control: no-cache - veya Cache-Control: max-age=60, must-revalidate

2) ETag: günceli doğrulamak için kullanın

ETag ile tarayıcı “içerik aynı mı?” diye kontrol eder. Aynı içerikse yanıt genelde 304 Not Modified döner ve gövde indirilmez.

Pratik etkiler: - Ana sayfayı sık ziyaret eden kullanıcıda bant genişliği düşer. - Değişiklik olduğunda anında doğru sürüm yüklenir.

3) Vary: CDN/kimlik doğrulama/ülke dil farklarını doğru belirtin

Eğer aynı URL farklı koşullara göre farklı içerik üretiyorsa (ör: dil Accept-Language, oturum durumu Cookie, cihaz varyantı), bunu Vary ile belirtmezsen CDN yanlış varyant döndürebilir.

Net kontrol: - A/B, dil, auth gibi farklar varsa Vary yoksa sorun ihtimali yükselir. - Örn. dil bazlı içerikte: Vary: Accept-Language

Uygulama örnekleri: Nginx/Apache ve uygulama tarafı

Aşağıdaki örnekler hedefi anlatmak içindir. Kullandığınız dağıtım ve dosya yapısına göre yolları uyarlayın.

Nginx örneği: statik dosyalara uzun cache

location ~* \.(js|css|png|jpg|jpeg|gif|svg|webp|woff2|woff)$ {
  expires 1y;
  add_header Cache-Control "public, max-age=31536000, immutable";
}

location = / {
  add_header Cache-Control "no-cache";
}

Bu düzenin anlamı: - Statik dosyalar hash’li ise uzun süre cache edilir. - Ana sayfa her seferinde doğrulanır.

Apache örneği: mod_headers ile Cache-Control

<FilesMatch "\.(js|css|png|jpg|jpeg|gif|svg|webp|woff2|woff)$">
  Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>

<Location />
  Header set Cache-Control "no-cache"
</Location>

Cache’i yanlış yapmanın 5 net sonucu

1. Eski dosya görünmesi: Asset URL’leri versiyonlanmıyorsa uzun max-age eski sürümü kilitler.
2. Gereksiz doğrulama: Her şeyi no-cache yapmak, 304 olsa bile ekstra round-trip doğurur.
3. CDN varyant hatası: Vary eksikse kullanıcı farklı içerik alabilir.
4. Performans yerine gecikme: HTML de uzun cache yapılırsa First Byte gecikir; kullanıcının geri dönüşte güncel görmemesi maliyet yaratır.
5. Mobilde bant israfı: Cache davranışı mobilde farklılaşmıyorsa gereksiz yeniden indirme olur.

Başarıyı ölçme: Tarayıcı ve HTTP seviyesinde test adımları

Yapılandırmayı “gördüm, çalışıyor” yerine ölçün.

1) Chrome DevTools ile doğrulama

• DevTools → Network sekmesi
• Sayfayı yenileyin (Ctrl+R)
• Kaynaklara tıklayın:
• Response Headers altında Cache-Control, ETag, Age değerlerini kontrol edin.
• Status alanında 200 mi 304 mü geldiğini görün.

Net beklenti: - Statik assetlerde ikinci yüklemede çoğu kaynak için tarayıcı “cache’ten” servis eder (çoğu zaman Size: 0B ya da from disk cache görünür). - Revalidation gerekenlerde 304 Not Modified görürsünüz.

2) Hard refresh ve normal refresh farkı

• Normal yenilemede cache davranışı doğrulanır.
• Hard refresh (Ctrl+Shift+R) cache’i daha agresif atlatır.

Bu farkı bilmek, “cache çalışmıyor” yanlış yorumunu engeller.

3) curl ile header testi

Hızlı bir doğrulama için: - HTML için: - curl -I https://example.com/ - Statik için: - curl -I https://example.com/assets/app.js

Beklediğiniz header seti: - HTML: Cache-Control: no-cache (ya da kısa süre + revalidate) - Asset: Cache-Control: public, max-age=31536000, immutable - İsteğe göre ETag

CDN kullanıyorsanız cache ayarları iki katmana yayılır

Birçok hosting senaryosunda CDN (ör: Cloudflare, benzeri) devrededir. Bu durumda iki katman vardır: 1) CDN cache politikası 2) Origin (sunucu) cache header’ları

Net kural: - CDN, origin’den gelen Cache-Control/ETag/Vary sinyallerini temel alır. - Origin başlıkları doğru değilse CDN “yanlış” şekilde cache edebilir veya sık doğrulama yapabilir.

Kontrol listesi: - CDN panelinde “respect origin headers” benzeri ayar açık mı? - Cache hit oranı artıyor mu? - Yanlış varyant (dil/auth) gidiyor mu? Vary ile doğrulayın.

Statik dosya hash’leri yoksa uygulanacak net yol haritası

Eğer mevcut projede app.js gibi sabit isimlerle dosya yayınlanıyorsa şu sırayı izleyin: 1. Build pipeline’e hash’li asset ismi ekleyin (ör: app.<hash>.js). 2. HTML çıktılarında yeni isimleri otomatik bağlayın. 3. Statik dosyalar için immutable + max-age=31536000 hedefleyin. 4. HTML ve API için revalidation veya kısa süreli politikaya devam edin. 5. DevTools ile ikinci yüklemede header ve boyut davranışını doğrulayın.

Bu sıra, “eski içerik kilitlenmesi” riskini pratikte sıfıra indirir.

Sonuç: En hızlı kazanım için önce assetleri, sonra HTML’i düzenleyin

Browser cache’i doğru kurmanın pratik yolu şudur: Asset (JS/CSS/görsel/font) dosyalarınızı URL ile versiyonlayın ve bu statik kaynaklara Cache-Control: public, max-age=31536000, immutable verin. Ana HTML ve dinamik API’lerde no-cache veya kısa süre + ETag revalidation ile içerik tutarlılığını koruyun. Ardından Chrome DevTools ve curl -I ile Cache-Control/ETag/304 davranışını ölçün; sonuç oturmadan süreleri artırmayın.

Aksiyona dönük öneri: Önce en çok ziyaret edilen 3 URL için (ana sayfa, kategori, ürün/landing) header testini yapın; sonra statik dosyalar için hedeflenen cache politikasını uygulayıp ikinci yükleme (repeat view) performansını karşılaştırın.