tarayici onbellek yapilandirmasi: Hızlı ve Güncel Web Siteleri İçin Rehber
Tarayıcı önbelleği yapılandırması, web sitenizin daha hızlı açılması için kaynakların ziyaretçi cihazında ne kadar süre saklanacağını ve ne zaman sunucudan doğrulanacağını belirler. Doğru yapılandırma, tekrar ziyaretlerde ağ trafiğini azaltır; yanlış yapılandırma ise güncel olmayan CSS, JavaScript veya HTML dosyalarının gösterilmesine neden olabilir.
Önemli Noktalar
- Statik ve sürümlenmiş dosyalar uzun süre önbelleğe alınabilir.
- HTML, kişiselleştirilmiş yanıtlar ve hassas veriler daha kontrollü saklanmalıdır.
- `Cache-Control`, temel önbellek politikasını belirleyen ana HTTP başlığıdır.
- `ETag` ve `Last-Modified`, değişmeyen içeriklerin yeniden indirilmesini önleyebilir.
- Dosya adı sürümleme, eski kaynakların kullanılma riskini azaltır.
- Ayarlar yalnızca tarayıcıda değil; CDN, proxy ve sunucu katmanlarında da test edilmelidir.
- Önbellek optimizasyonu, performans ölçümü ve yayın süreçleriyle birlikte ele alınmalıdır.
Tarayıcı önbelleği nedir ve nasıl çalışır?
Tarayıcı önbelleği, daha önce indirilen web kaynaklarının yerel bir kopyasını saklayan istemci tarafı mekanizmadır. Kullanıcı aynı sayfayı veya aynı kaynağı yeniden istediğinde tarayıcı, kaynağın hâlâ geçerli olup olmadığını kontrol eder ve uygun durumda sunucuya yeniden bağlanmadan dosyayı kullanır. Bu yapı, gecikmeyi ve gereksiz veri aktarımını azaltır.
Bir web sayfası yalnızca HTML’den oluşmaz. CSS dosyaları, JavaScript paketleri, logo ve ürün görselleri, yazı tipleri, video posterleri ve bazı API yanıtları da önbellek politikasına tabi olabilir. Her kaynak türünün güncellenme sıklığı, kişisel veri içerip içermediği ve tekrar kullanılma ihtimali farklıdır.
Örneğin içerik adı değişen bir HTML sayfası ile dosya adında içerik özeti bulunan bir JavaScript paketi aynı süreyle saklanmamalıdır. İyi bir politika, “her şeyi uzun süre sakla” yaklaşımı değil, kaynak türüne göre kontrollü süre ve doğrulama modelidir.
Neden tarayıcı önbellek yapılandırması önemlidir?
Önbellek, ilk ziyaretin bütün maliyetini ortadan kaldırmaz; asıl kazanım çoğunlukla tekrar ziyaretlerde ve aynı kaynağı kullanan sayfalar arasında ortaya çıkar. Daha önce indirilen bir CSS veya yazı tipi yeniden kullanılabildiğinde istek sayısı ve aktarılması gereken veri azalır. Bu durum, özellikle mobil ağlarda ve uzak sunuculara erişen kullanıcılarda daha akıcı bir deneyim sağlayabilir.
Performans, kullanıcı deneyiminin tek ölçütü değildir; ancak önemli bir bileşenidir. Google, Core Web Vitals metriklerini yükleme performansı, etkileşim ve görsel kararlılığı değerlendirmek için kullanır. LCP için iyi deneyim hedefi 2,5 saniye içinde yüklenme, INP için ise 200 milisaniyenin altında yanıt olarak açıklanır.
Önbellek ayarları bu metrikleri otomatik olarak iyi seviyeye getirmez. Büyük görseller, engelleyici JavaScript, yavaş sunucu yanıtı veya yanlış önceliklendirme devam ediyorsa yalnızca cache başlıklarını değiştirmek yeterli değildir. Bu nedenle yapılandırma; sayfa hızı optimizasyonu ve gerçek kullanıcı verileriyle birlikte değerlendirilmelidir.
Cache-Control başlığı ne işe yarar?
`Cache-Control`, tarayıcılara ve paylaşımlı önbelleklere bir yanıtın saklanıp saklanamayacağını, ne kadar süre geçerli olacağını ve hangi koşullarda doğrulanacağını bildiren HTTP yanıt başlığıdır. Aynı başlık, tarayıcı cache’i, CDN, proxy ve diğer ara katmanlar için farklı sonuçlar doğurabilir.
En sık kullanılan yönergeler şunlardır:
- `public`: Yanıtın paylaşımlı önbelleklerde de saklanabileceğini belirtir.
- `private`: Yanıtın yalnızca kullanıcıya özel tarayıcı önbelleğinde tutulmasını amaçlar.
- `max-age`: Kaynağın saniye cinsinden tazelik süresini tanımlar.
- `no-cache`: Kaynağın saklanmasını mutlaka engellemez; kullanılmadan önce sunucuyla doğrulanmasını ister.
- `no-store`: Yanıtın saklanmamasını ister. Hassas veya kişisel içeriklerde değerlendirilir.
- `must-revalidate`: Kaynak süresi dolduktan sonra yeniden doğrulama yapılmasını zorunlu kılar.
- `immutable`: URL’si değiştirilen, içeriği sabit kaynakların taze olduğu sürede yeniden doğrulanmasını önlemeye yardımcı olur.
- `stale-while-revalidate`: Uygun senaryolarda eski yanıt gösterilirken arka planda güncelleme yapılmasına izin verir.
no-cache ile no-store aynı şey midir?
Hayır. `no-cache`, kaynağın her kullanım öncesinde doğrulanmasını ifade eder; `no-store` ise yanıtın saklanmamasını amaçlar. Bu fark, güvenlik ve performans açısından kritiktir. Güncel kalması gereken bir HTML sayfasında çoğu zaman `no-cache` ve doğrulayıcı başlıklar kullanılabilir. Oturum, ödeme veya kullanıcıya özel hassas yanıtlar için ise `no-store` daha uygun olabilir.
Hangi kaynak ne kadar süre önbelleğe alınmalı?
Tek bir ideal süre yoktur. Süreyi belirlerken kaynağın değişme sıklığı, URL’nin sürümlenip sürümlenmediği, kullanıcıya özel veri içerip içermediği ve bir değişiklikten sonra eski sürümün gösterilmesinin ne kadar riskli olduğu dikkate alınmalıdır.
| Kaynak türü | Önerilen yaklaşım | Temel gerekçe |
|---|---|---|
| HTML belgeleri | Kısa süre veya `no-cache` | Yeni içerik ve şablon değişiklikleri hızlı görünmelidir |
| Sürümlenmiş CSS/JS | Uzun `max-age`, gerekirse `immutable` | URL değiştiğinde yeni dosya alınır |
| Logo ve sabit görseller | Orta veya uzun süre | Sık değişmeyen kaynaklardır |
| Kullanıcıya özel API yanıtları | `private`, kısa süre veya `no-store` | Kişisel verilerin paylaşılmasını önlemek |
| Sık değişen API verileri | Kısa `max-age` ve doğrulama | Güncellik ile hız arasında denge |
| Yazı tipleri | Uzun süre, sürümleme ile birlikte | Aynı dosya birçok sayfada tekrar kullanılır |
Süreler, sitenin yayın sıklığına göre ayarlanmalıdır. Haber, finans veya stok verisi içeren projelerde kısa süreli cache daha güvenli olabilir. Kurumsal bir sitenin sürümlenmiş tasarım dosyalarında ise uzun süreli önbellek daha verimli çalışabilir.
En doğru tarayıcı önbellek yapılandırması nasıl yapılır?
Uygulama, rastgele bir süre yazmak yerine kaynak envanteri ve test süreciyle yürütülmelidir. Aşağıdaki adımlar, farklı sunucu ve teknoloji yığınlarına uyarlanabilecek temel bir yöntem sunar.
1. Kaynakları sınıflandırın
Önce sitenin yanıtlarını gruplara ayırın:
- HTML ve şablon çıktıları
- CSS ve JavaScript dosyaları
- Görseller, SVG’ler ve medya dosyaları
- Yazı tipleri
- API yanıtları
- Oturum ve kullanıcıya özel içerikler
- Üçüncü taraf kaynaklar
Her grup için değişme sıklığını, gizlilik seviyesini ve dosya adı sürümlemesini kaydedin. Bu envanter oluşturulmadan yapılan genel bir kural, güncel içerik sorunlarına veya gereksiz sunucu isteklerine yol açabilir.
2. HTML için güncelliği önceliklendirin
HTML belgesi, diğer dosyaların hangi sürümlerinin yükleneceğini belirleyebilir. Bu nedenle eski HTML uzun süre saklanırsa kullanıcı, güncellenmiş CSS veya JavaScript dosyalarının yeni bağlantılarını geç alabilir. Sık değişen sayfalarda yeniden doğrulama yapılmasını sağlayan bir politika tercih edilmelidir.
`ETag` ve `Last-Modified` burada yararlıdır. Tarayıcı, daha önce aldığı doğrulama bilgisini sunucuya gönderir; içerik değişmemişse sunucu gövdeyi yeniden göndermek yerine `304 Not Modified` yanıtı verebilir. Böylece kaynak güncel kabul edilirken tam dosya aktarımı gerekmeyebilir.
3. Statik dosyaları sürümleyin
CSS ve JavaScript dosyalarını uzun süre önbelleğe almanın güvenli yolu, içerik değiştiğinde URL’yi de değiştirmektir. `app.css` yerine içerik özeti veya sürüm bilgisi taşıyan bir dosya adı kullanmak bu yöntemin temelidir.
Dosya güncellendiğinde yeni URL oluşturulursa tarayıcı eski kopyayı kullanmaya devam etse bile yeni sayfa yeni dosyayı çağırır. Bu yaklaşıma cache busting denir. Sürümlenmiş kaynaklar için uzun `max-age` ve uygun durumlarda `immutable` kullanılabilir.
4. Görselleri ve yazı tiplerini kontrol edin
Görseller, sayfa ağırlığının önemli bir bölümünü oluşturabilir. Ancak görseli önbelleğe almak, dosyanın boyutunu küçültmez. Bu nedenle öncelikle uygun format, boyut ve sıkıştırma uygulanmalı; ardından cache süresi belirlenmelidir. WebP görsel dönüştürme rehberi bu sürecin dosya optimizasyonu tarafı için kullanılabilir.
Dosya adı değişmeyen görsellerde uzun süreli cache kullanmak mümkün olsa da içerik değiştiğinde sürümleme veya URL yenileme planı bulunmalıdır. Yazı tiplerinde de aynı kural geçerlidir. Kullanılmayan font ağırlıkları kaldırılmalı, gerekli dosyalar sürümlenerek tutarlı başlıklarla sunulmalıdır.
5. Kişisel verileri paylaşılabilir cache’lerden uzak tutun
Kullanıcı hesabı, sepet, ödeme, bildirim veya kişisel rapor içeren yanıtlar başka kullanıcıların görebileceği paylaşımlı cache katmanlarına bırakılmamalıdır. Bu tür yanıtlar için `private` veya gereksinime göre `no-store` kullanılabilir.
Ayrıca yalnızca yanıt başlığını değil; çerezleri, `Vary` davranışını, yetkilendirme mekanizmasını ve CDN kurallarını da incelemek gerekir. “Tarayıcıda saklanıyor” ifadesi, verinin yalnızca o kullanıcıya ait olduğu anlamına gelmez; yanlış CDN politikası kişisel içeriğin istemeden paylaşılmasına neden olabilir.
ETag ve Last-Modified birlikte kullanılmalı mı?
Çoğu web projesinde her iki doğrulayıcının birlikte değerlendirilmesi faydalı olabilir. `ETag`, kaynağın belirli bir sürümünü tanımlayan bir değerdir; `Last-Modified` ise son değişiklik zamanını belirtir. Tarayıcı, bu bilgileri sonraki koşullu isteklerde kullanarak kaynağın değişip değişmediğini sorabilir.
Doğrulayıcılar özellikle HTML ve sık güncellenen fakat büyük yanıt gövdesine sahip kaynaklarda veri aktarımını azaltabilir. Bununla birlikte, birden fazla sunuculu ortamlarda ETag üretiminin tutarlı olması gerekir. Farklı düğümler aynı içeriğe farklı etiketler üretirse gereksiz yeniden indirmeler yaşanabilir.
stale-while-revalidate hangi durumlarda kullanılabilir?
`stale-while-revalidate`, tazelik ile hız arasında esneklik sağlayan bir direktiftir. Kaynak kısa süre önce tazeliğini yitirmiş olsa bile tarayıcı veya cache katmanı mevcut kopyayı sunabilir; aynı anda arka planda güncel sürüm için doğrulama yapılır. Böylece kullanıcı beklemeden içerik görebilir.
Bu yöntem, küçük gecikmelerin kabul edilebildiği içeriklerde değerlendirilebilir. Saniyesi saniyesine değişmesi gereken fiyat, stok veya güvenlik bilgileri için dikkatli olunmalıdır. Önce verinin birkaç saniye veya dakika eski görünmesinin iş etkisi analiz edilmeli, ardından `max-age` ve `stale-while-revalidate` süreleri belirlenmelidir.
Sunucu ve CDN ayarları nasıl test edilir?
Yanıt başlıklarını inceleyin
Tarayıcı geliştirici araçlarında Network panelini açın ve HTML, CSS, JavaScript, görsel ve API isteklerini ayrı ayrı inceleyin. Şu başlıkları kontrol edin:
- `Cache-Control`
- `ETag`
- `Last-Modified`
- `Age`
- `Expires`
- `Vary`
- CDN sağlayıcısına ait cache durum başlıkları
İlk istekte `200`, değişmeyen içerik için koşullu istekte `304` veya uygun cache hit davranışı görülmesi beklenebilir. Ancak sonuç, kullanılan sunucu, CDN ve tarayıcı politikasına göre değişir.
Farklı senaryolarla doğrulayın
- İlk ziyareti temiz profil veya gizli pencereyle test edin.
- Aynı sayfayı yenileyerek tekrar isteklerini kaydedin.
- Dosya içeriğini değiştirip URL sürümleme davranışını kontrol edin.
- Mobil ağ ve masaüstü ağ koşullarını ayrı değerlendirin.
- Giriş yapmış ve yapmamış kullanıcı yanıtlarını karşılaştırın.
- CDN önbelleğini temizledikten sonra yayılım süresini ölçün.
- Güncelleme sonrasında eski CSS veya JavaScript kullanımını gözlemleyin.
Ölçüm yalnızca laboratuvar testine dayanmamalıdır. Gerçek kullanıcı verileri, farklı cihaz ve ağ koşullarında cache politikasının nasıl sonuç verdiğini daha iyi gösterebilir. Performans çalışmasını Core Web Vitals iyileştirme rehberi ile birlikte değerlendirmek, önbellek kararlarını kullanıcı deneyimi metriklerine bağlamaya yardımcı olur.
Sık yapılan önbellek hataları nelerdir?
Her dosyaya aynı süreyi vermek
HTML, API, görsel ve JavaScript dosyasına aynı `max-age` değerini vermek pratik görünür; fakat kaynakların güncellenme ve gizlilik ihtiyaçları farklıdır. Kaynak türü bazlı politika daha kontrollü sonuç verir.
Güncellenen dosyada aynı URL’yi korumak
CSS veya JavaScript değiştiğinde dosya URL’si aynı kalıyor ve uzun süreli cache kullanılıyorsa bazı kullanıcılar eski dosyayı görür. Sürümleme, bu sorunu yayın sürecinin parçası olarak çözmelidir.
no-cache’i no-store sanmak
`no-cache`, doğrulama ihtiyacını anlatır; saklamayı bütünüyle engellemez. Hassas yanıtlar için yalnızca bu yönergeye güvenmek doğru değildir.
Cache temizlemeyi çözüm sanmak
Tarayıcı cache’ini manuel temizlemek, ziyaretçinin cihazındaki mevcut kopyayı geçici olarak siler. Ancak sunucu başlıkları yanlışsa sorun tekrar oluşur. Kalıcı çözüm, kaynağın yaşam döngüsünü ve yayın stratejisini düzeltmektir.
Cache’i diğer performans işlerinden koparmak
Önbellek, görsel sıkıştırma, lazy loading, JavaScript optimizasyonu, sunucu yanıt süresi ve render stratejisiyle birlikte ele alınmalıdır. Örneğin doğru cache başlıklarına sahip çok büyük bir görsel, ilk ziyarette yine yüksek aktarım maliyeti yaratır. Lazy loading kullanımı ve görsel optimizasyonu bu nedenle tamamlayıcı çalışmalardır.
Uygulama öncesi karar kriterleri
Bir kaynağın nasıl önbelleğe alınacağına karar verirken şu soruları kullanın:
- İçerik kullanıcıya özel mi?
- Kaynak ne sıklıkla güncelleniyor?
- Güncel olmayan sürümün gösterilmesi kritik bir sorun oluşturur mu?
- URL, içerik değiştiğinde otomatik olarak sürümleniyor mu?
- Yanıt CDN veya proxy üzerinden paylaşılabilir mi?
- Kaynakta kişisel, finansal veya oturum verisi bulunuyor mu?
- Güncelleme sonrası cache temizleme süreci tanımlı mı?
- Başlıklar farklı cihaz, dil ve kullanıcı durumlarında tutarlı mı?
Bu soruların yanıtları, yalnızca teknik performansı değil; güvenlik, içerik doğruluğu ve bakım maliyetini de etkiler.
Sonuç: hızlı olmak kadar güncel kalmak da önemlidir
Etkili bir tarayıcı önbellek yapılandırması, her kaynağı mümkün olan en uzun süre saklamak değildir. Amaç; değişmeyen ve sürümlenmiş dosyaları hızlı biçimde yeniden kullanmak, değişen içerikleri zamanında doğrulamak ve kişisel verileri yanlış cache katmanlarından uzak tutmaktır.
Mimoza Bilişim yaklaşımında önbellek çalışması; HTTP başlıkları, dosya sürümleme, CDN davranışı, güvenlik ve Core Web Vitals ölçümleriyle birlikte değerlendirilmelidir. Böylece performans kazanımı, güncel içerik ve sürdürülebilir teknik SEO hedefleri arasında daha dengeli bir yapı kurulabilir.