Browser Cache Nasıl Yapılandırılır? Net Kontrol Rehberi

Browser cache (tarayıcı önbelleği) doğru yapılandırıldığında sayfalar gereksiz yere yeniden indirilmez; kullanıcı deneyimi hızlanır ve sunucu trafiği azalır. Yanlış ayarlar ise içeriklerin geç güncellenmesine, “eski dosya” sorunlarına ve beklenmeyen performans düşüşlerine yol açar. Bu rehberde, tarayıcı cache’i doğru stratejiyle kurmayı, doğrulamayı ve hataları gidermeyi adım adım öğreneceksiniz.

Browser cache neyi hızlandırır, neyi bozabilir?

Browser cache, tarayıcının aynı dosyaları tekrar tekrar indirmek yerine yerelde saklamasıdır. Bu sayede aşağıdaki etkiler görülür:

• İndirme süresi azalır: Özellikle görseller, CSS/JS ve font dosyaları tekrar indirilmez.
• Sunucu yükü düşer: Aynı dosyaya gelen istek sayısı azalır.
• TTFB/ışınlanma hızlanır: İlk istek dışında sonraki sayfalarda HTML dışındaki kaynaklar daha hızlı gelir.

Bozucu senaryolar:

• Uzun süreli cache + versiyon yoksa: Örn. app.js aynı isimle güncelleniyorsa kullanıcı “eski app.js”i kullanmaya devam eder.
• Yanlış “no-cache/no-store” kombinasyonları: CDN ve tarayıcı cache atlanır, performans beklenen seviyeye gelmez.
• ETag/Last-Modified uyumsuzluğu: Dosya değiştiği halde 304 döngüleri veya sürekli tekrar indirme görülür.

Bu yüzden tarayıcı cache ayarı yaparken yalnızca “süre verelim” yaklaşımı yeterli değildir; dosya değişim stratejisiyle birlikte planlamak gerekir.

Doğru Cache-Control stratejisi: süreden fazlası

En kritik başlık Cache-Control’dır. Tarayıcıya ve ara katmanlara (CDN, reverse proxy) “ne kadar süre sakla” ve “ne zaman doğrula” bilgisini verir.

Aşağıdaki stratejiler pratikte en sık kullanılanlardır:

1) Değişmeyen statik dosyalar (immutable)

Sık kullanılan örnekler: app.<hash>.js, styles.<hash>.css, logo.<size>.webp gibi dosyalar.

• Dosya adı içerik (build) ile birlikte değiştiği için uzun cache uygundur.
• Öneri: 1 yıl (31536000 saniye) ve immutable.

Örnek yanıt başlıkları:

• Cache-Control: public, max-age=31536000, immutable

2) Sık güncellenen statik dosyalar (versiyon yoksa)

Dosya adında hash yoksa app.js gibi isimler her deploy’da değişir. Bu durumda uzun süre cache vermek risklidir.

Öneri: Kısa cache + doğrulama.

• Cache-Control: public, max-age=0, must-revalidate

Bu yaklaşımda tarayıcı dosyayı saklayabilir; fakat her istek öncesi sunucu doğrulaması yapılır (HTTP conditional request).

3) HTML dökümleri

HTML genelde hızlı güncellenir ve kullanıcıya hemen yansıtılmalıdır.

• Öneri: Cache-Control: no-cache (kullanıcıya “sakla ama doğrula” etkisi verir) veya çok kısa max-age.

Örnek:

• Cache-Control: no-cache

Not: no-store çoğu senaryoda gereksiz yere önbelleği devre dışı bırakır. Performans açısından genellikle daha kısıtlayıcıdır.

ETag ve Last-Modified: doğrulama trafiğini doğru yönetme

Tarayıcı cache sadece “süre” ile çalışmaz. ETag ve Last-Modified ile “değişti mi?” sorusu cevaplanır.

• ETag (entity tag): Aynı kaynak için içerik değiştiğinde farklı bir değer üretir. Sunucu If-None-Match ile doğrulama yapar.
• Last-Modified: Dosyanın son güncellenme tarihine göre çalışır. Sunucu If-Modified-Since ile doğrulama yapar.

Pratik öneri:

• Statik dosyalarda hem süre hem de doğrulama başlıkları tutarlı olmalıdır.
• CDN kullanıyorsanız CDN’in ürettiği başlıklarla sunucu başlıkları çakışmamalıdır. “CDN öncelikli” ayar mantığı genelde en sorunsuzudur.

Hangi dosya türüne hangi süre? Net eşleştirme tablosu

Aşağıdaki tablo, çoğu web uygulaması için güvenli başlangıç noktasıdır.

Sunucu tarafında cache header ayarlama (Apache/Nginx örnekleri)

Browser cache’i en doğru şekilde, kaynaklara göre sunucu (veya CDN) katmanında set etmek gerekir. Aşağıdaki örnekler yön göstericidir.

Nginx (örnek konfigürasyon)

Aşağıdaki mantık, dosya uzantılarına göre farklı süreler verir.

# HTML
location ~* \.html$ {
  add_header Cache-Control "no-cache";
}

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

Apache (örnek konfigürasyon)

Apache’de mod_headers ve mod_expires kullanılabilir.

<IfModule mod_headers.c>
  <FilesMatch "\\.html$">
    Header set Cache-Control "no-cache"
  </FilesMatch>

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

<IfModule mod_expires.c>
  ExpiresActive On
</IfModule>

Bu örnekleri üretim ortamında kullanmadan önce, uygulamanızın dosya isimlendirme (hash var mı yok mu) kurgusunu kesinleştirin.

CDN kullanıyorsanız: tarayıcı cache değil, katman cache de önemlidir

CDN (Content Delivery Network) kullanıyorsanız, tarayıcı cache başlıkları CDN içinde de değerlendirilir. Bu nedenle kontrol listesi şunları kapsamalıdır:

• CDN, sunucudan gelen Cache-Control değerlerini passthrough ediyor mu?
• CDN üzerinde “Cache By Header” veya “Ignore Cache-Control” gibi bir seçenek var mı?
• Dosya isimlerinde hash yoksa CDN tarafında çok uzun TTL ayarlamak, “değişen içerik eski dosyadan” sorununu hızlandırır.

Net kural:

• Hash’li dosyalar için CDN TTL uzun olabilir.
• Hash’siz kritik dosyalarda TTL kısa olmalı veya isimlendirme hash’lenmelidir.

Doğrulama: “cache çalışıyor mu?” nasıl kanıtlanır?

Cache header’larını ayarladığınızda, uygulamanın gerçekten beklenen davranışı verdiğini test etmek gerekir.

Chrome DevTools ile kontrol

1. Sayfayı açın.
2. DevTools → Network sekmesi.
3. Kaynak filtresine js, css, webp, woff2 gibi uzantıları girin.
4. Sayfayı ikinci kez yenileyin (hard refresh yapmayın).
5. Her istek için aşağıdakilere bakın: - Response header içinde Cache-Control doğru mu? - İstek “(from disk cache)” ya da “(from memory cache)” şeklinde geliyor mu? - Alternatif doğrulama senaryosunda 304 Not Modified görünüyor mu?

cURL ile başlık doğrulama

Hızlı bir test için:

curl -I https://ornekdomain.com/assets/app.js

Çıktıda şu başlıklardan beklenenleri arayın:

• Cache-Control
• ETag (varsa)
• Last-Modified (varsa)

Lighthouse ve hız etkisi

Cache doğruluğu, Lighthouse metriklerinde doğrudan “fark” yaratır. Özellikle şu alanlara bakın:

• Resource load times düşüyor mu?
• Önceden cache’lenmiş kaynaklar tekrar indirilmeden mi geliyor?

Yaygın hatalar ve net çözümler

Hata 1: Hash’siz dosyalara 1 yıl cache

Belirti:

• Deploy sonrası bazı kullanıcılar eski JS/CSS dosyasını görür.

Çözüm:

• Hash’li dosya üretin (app.<hash>.js).
• Ya da hash’siz dosyalar için max-age=0, must-revalidate kullanın.

Hata 2: Yanlış HTML cache

Belirti:

• Ana sayfa veya yönlendirmeler gecikmeli güncelleniyor.

Çözüm:

• HTML için no-cache tercih edin.
• Varsa SPA router senaryosunda HTML/JS ayrımını net yapın.

Hata 3: CDN ile sunucu başlıkları çakışıyor

Belirti:

• DevTools’ta header doğru görünüyor ama davranış farklı.

Çözüm:

• CDN ayarlarında cache davranışını kontrol edin.
• CDN üzerinden gelen yanıt başlıklarını inceleyin: curl -I ile CDN domaininden test edin.

Hata 4: Çok agresif sıkıştırma (gzip/brotli) ile cache çakışması

Belirti:

• Aynı dosya bazen farklı varyant olarak dönüyor.

Çözüm:

• Sunucu/ CDN seviyesinde brotli/gzip varyantlarının doğru çalıştığından emin olun.
• Vary: Accept-Encoding başlığını bekleyin.

WordPress gibi içerik yönetim sistemlerinde cache ayarı

WordPress tarafında cache, tek bir yerde bitmez; server cache header’ları ile eklenti/cache katmanları birlikte düşünülmelidir.

Net yaklaşım:

• Statik dosyalar (tema/build varlıkları) için doğru Cache-Control ile hash’li üretim yapın.
• WordPress HTML çıktısı için eklenti cache ayarlarını server header’larıyla çakıştırmadan doğrulayın.
• Dynamic endpoint’ler (ör. REST API) için içerik kişiselse private mantığını kullanın.

Eğer bir CDN kullanıyorsanız, WordPress cache eklentisinin ürettiği başlıklar CDN’de eziliyor olabilir. Bu yüzden doğrulama testini CDN URL’si üzerinden yapın.

Uygulamaya koyma planı: 30 dakikalık net aksiyon

Aşağıdaki sıralama, riski azaltır:

1. Mevcut yanıt başlıklarını çıkarın: curl -I ile HTML + 2-3 statik dosya inceleyin.
2. Uygulamanız statik dosyaları hash’li üretiyor mu karar verin.
3. Hash’li ise statik dosyalara public, max-age=31536000, immutable verin.
4. HTML için no-cache uygulayın.
5. Hash’siz ise statik dosyalara max-age=0, must-revalidate verin.
6. CDN kullanıyorsanız CDN üzerinden curl -I testi yapın.
7. 1. sayfa yüklemesinde Network’ten tekrar indirilmeyen kaynakları doğrulayın.

Sonuç: Browser cache’i “süre + dosya stratejisi” ile kurun

Browser cache ayarını tek bir süre değeri olarak değil, dosya değişim stratejinizle birlikte tasarlayın: hash’li statik dosyalara uzun immutable cache, HTML’ye no-cache, hash’siz dosyalara ise kısa + doğrulamalı cache. Önce başlıkları doğrulayın, sonra değişken davranışı (deploy sonrası güncellendi mi?) test edin. Bu rehberi uyguladıktan sonra NetKıyas üzerinden performans karşılaştırması yapmanıza gerek kalmadan, kendi sayfanızda tarayıcı cache etkisini net şekilde ölçebilir hale geleceksiniz.