Tarayıcı Cache (Browser Cache) Nasıl Yapılandırılır? Net Rehber

Browser cache (tarayıcı önbelleği) doğru yapılandırıldığında, aynı ziyaretlerde sayfa ve görsel gibi dosyaların tekrar tekrar indirilmesini azaltır. Sonuç olarak kullanıcı tarafında TTFB/TBT benzeri gecikmeler düşer, sunucu ve bant genişliği maliyeti azalır. Bu rehberde; cache mantığını, HTTP header’larını (Cache-Control, ETag), dosya sürümleme yaklaşımını ve pratikte nasıl doğrulayacağınızı adım adım göreceksiniz.

Browser cache neyi çözer, neyi çözmez?

Browser cache’in amacı, statik kaynakları (JS, CSS, görseller, fontlar) yeniden indirmek yerine tarayıcıda saklamaktır. Ancak her şeyi cache’lemek doğru değildir.

Cache’lemenin doğru hedefi: statik dosyalar

Aşağıdaki içerikler genellikle uzun süreli cache ile uyumludur: - JS ve CSS dosyaları - Görseller (png, jpg, webp, svg) - Fontlar (woff2 vb.) - Kullanıcı değişmeyen statik asset’ler

Bu dosyalarda kritik nokta şudur: Dosya adı değişmedikçe tarayıcı eski sürümü tutabilir. Bu yüzden dosya sürümleme (hash ile isimlendirme) gerekir.

Cache’lememeniz gerekenler: sık değişen içerik

Aşağıdakiler çoğu senaryoda kısa cache veya hiç cache olmadan yönetilmelidir: - HTML sayfaları - Dinamik içerik üreten API yanıtları - Kullanıcıya özel sayfalar (oturum, kişisel veriler)

Burada amaç; güncellemelerin “beklemeden” görünmesini sağlamaktır. HTML için kısa süreli cache + “asset’leri uzun süre cache’le” yaklaşımı pratikte en dengeli yöntemdir.

Cache-Control başlıkları: pratikte doğru kombinasyonlar

Browser cache’in kalbi HTTP yanıt başlıklarıdır. En çok kullanılanları Cache-Control, bazen ETag ve ek olarak Last-Modified olur.

Cache-Control: en net kontrol

Sık kullanılan ayarlar: - public: Yanıt proxy/cache altyapıları tarafından da cache’lenebilir. - private: Sadece tarayıcı (client) önbelleğine uygundur. - max-age=SECONDS: Cache’in ne kadar süre geçerli olduğunu belirler. - no-cache: Cache’lenebilir ama her istek öncesi doğrulama gerekir (yeniden indirilmeyebilir). - no-store: Hiç saklama. - must-revalidate: Cache geçerliliği dolunca doğrulama zorunlu.

Örnek politika tablosu

Aşağıdaki tablo, dosya türüne göre “net” bir başlangıç çerçevesi verir:

Not: immutable güncel tarayıcılarda “dosya adı değişmeyecek” varsayımıyla birlikte çalışır. Bu nedenle sadece hash’lenmiş statik dosyalarda kullanın.

ETag: doğrulama (revalidation) maliyetini yönetme

ETag ile tarayıcı, cache’teki içeriğin hâlâ aynı olup olmadığını sorar. Bu sayede içerik değişmediyse veri boyutu büyük olsa bile tam indirme olmayabilir. - HTML için no-cache kullanmak, doğrulamayı zorunlu kılar. - Statik dosyalarda ise sürümleme yaptığınız için çoğu zaman doğrulama ihtiyacını minimuma indirirsiniz (uzun max-age + immutable).

Dosya sürümleme (hash) olmadan uzun cache risktir

En sık yapılan hata: “max-age’i 1 yıl yaptım, hızlandı” zannedip dosya adını değiştirmeden güncelleme yapmaktır. Kullanıcılar eski dosyayı cache’ten çeker.

En doğru yaklaşım: filename’de içerik hash’i

Örnek mantık: - app.4f3a9c2.js - styles.a19bd0c.css

Yeni deploy olduğunda hash değişir, dosya adı değiştiği için tarayıcı yeni dosyayı ister. Bu sayede uzun cache ile güncellemeleri aynı anda garanti edersiniz.

Uygulama tarafı: build pipeline şart

Build pipeline şu üç ihtiyacı karşılamalıdır: - Hash’li asset üretimi - HTML içinde doğru referansı otomatik güncelleme - Servis tarafında hash’li dosyaları uzun cache’te tutma

Taraf bağımsız kurulum: “Tarayıcı tarafında cache” ile “sunucu header’ı” karışmasın

Bazı kullanıcılar “tarayıcı ayarlarından cache’i ayarlayayım” diye düşünür. Bu kontrol tek tek kullanıcıda garanti edilemez.

NetKıyas açısından en sağlıklı yöntem: - Tarayıcı davranışını belirleyen asıl kaynak: sunucunun HTTP response header’ları - Tarayıcı tarafı: geliştirme ve test içindir (ör. DevTools ile boşaltma)

Sunucu/Proxy tarafında header uygulama: net örnekler

Aşağıdaki örnekler, statik dosya türlerinde uzun cache vermek için başlangıç komutlarıdır. Kullandığınız teknolojiye göre uyarlayın.

Nginx örneği (statik dosyalar)

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

location / {
    add_header Cache-Control "public, max-age=60";
}

Apache örneği (mod_headers)

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

  <FilesMatch "\.html$">
    Header set Cache-Control "public, max-age=60"
  </FilesMatch>
</IfModule>

CDN varsa: iki katman birlikte düşünülür

CDN kullanıyorsanız hem CDN cache politikasını hem de origin header’larını kontrol edin. - Origin’de uzun cache verdiniz ama CDN “override” uyguluyorsa davranış değişir. - Purge/invalidate mekanizması: hash’li dosyalarda genelde purge ihtiyacı azalır.

Doğrulama: “Cache-Control doğru mu?” nasıl kanıtlanır?

Cache ayarları teoride değil, log/başlık doğrulamasıyla netleşir.

Chrome/Firefox DevTools ile kontrol

1. Geliştirici araçlarını açın (F12).
2. Network sekmesine gidin.
3. Sayfayı hard refresh yapın (geliştirici aracına göre değişir).
4. Yeniden yüklenen isteklerde response headers altında şunları arayın: - Cache-Control doğru mu? - Yanıt immutable içeriyor mu? - HTML için max-age kısa mı?
5. Aynı sayfayı tekrar açın. - Uzun cache’li dosyalarda “from disk cache”/“from memory cache” veya beklenen cache davranışı görülmelidir.

Curl ile header kontrolü

Örnek akış: - Asset için: - Cache-Control içinde max-age=31536000 ve immutable doğrulayın. - HTML için: - max-age 60 gibi kısa bir değer veya no-cache doğrulayın.

Komut formatı (örn.): - curl -I https://site.example/app.a19bd0c.css

Cache temizleme (purge) ve sorun giderme: net karar ağaçları

Cache politikasını kurduktan sonra iki tür problem çıkar: “Kullanıcı eski dosya görüyor” ve “Hâlâ yavaş, cache çalışmıyor”.

Problem 1: Kullanıcı eski JS/CSS görüyor

Doğru kontrol sırası: 1. Dosya sürümleme var mı? (hash’li dosya adı değişiyor mu?) 2. HTML içinde eski referans kalıyor mu? 3. Cache-Control uzun mu ve immutable var mı? 4. CDN purge gerekiyor mu? (özellikle proxy override varsa)

Net çözüm: Dosya hash’i değişmiyorsa uzun cache doğru değildir. Hash ile isimlendirmeyi etkinleştirin.

Problem 2: Cache çalışmıyor, her seferinde yeniden indiriyor

Kontrol listesi: - Response’larda Cache-Control gerçekten dönüyor mu? - Vary başlığı (ör. Vary: Accept-Encoding) kontrolü: uygulama yanlış Vary ile gereksiz varyant üretiyor olabilir. - Uygulama katmanı (framework) her istekte header’ı override ediyor mu? - CDN/Load balancer origin header’ı değiştiriyor mu?

Net çözüm: Static asset route’larında sabit bir header set edin, uygulama üzerinden dinamik override’u kaldırın.

Optimizasyon hedefleri: ölçüm olmadan “cache yaptım” denmez

Cache ayarlarının etkisini sayısal ölçümle doğrulayın: - İlk yükte indirme boyutu: değişmez (assets yine gelir) - İkinci/sonraki yükte istek sayısı ve toplam indirme: düşmelidir - Network waterfall: özellikle JS/CSS yeniden indirme yoksa belirgin kısalır

Kılavuz bir hedef: - Hash’li statik dosyalar için tekrar ziyaretlerde “tam dosya indirme” yerine cache’ten servis görülmeli. - HTML için max-age kısa tutularak kullanıcı güncellemeleri hızlı görmeli.

Sonuç: Net bir yapı kuralı ile ilerleyin

Browser cache’i doğru kurmanın net formülü şudur: HTML’i kısa cache/ doğrulamalı yönet, hash’li statik asset’leri uzun cache + immutable ile servis et, sonra DevTools/curl ile header’ları doğrula. Kurulumu tamamladıktan sonra ilk iki deploy’da değişen dosyaların adlarının gerçekten güncellendiğini teyit edin. Bu üç adımı uyguladığınızda cache performansı “tahminle” değil “ölçümle” ilerler.

İsterseniz mevcut stack’inizi (Nginx/Apache/CDN, framework, asset hash var mı) yazın; ona göre size uygun net Cache-Control setini birlikte çıkarabilirim.