CDN hesap sayfasını publicgördüğü için cache’lerken statik font her ziyarette yeniden doğrulanıyorsa iki sorun da HTTP cache politikasıyla ilgilidir. Yine de bütün WordPress yanıtlarına aynı header’ı eklemek çözüm değildir.
Cache-Control, her yanıt sınıfının nerede ve ne kadar süre saklanabileceğini açıklar. Genel HTML, kişisel hesap yanıtı ve sürümlü varlık farklı yönergeler ister.
Bu konu ne anlama gelir?
Cache-Control; tazelik, yeniden kullanım, doğrulama ve paylaşılan cache davranışını belirleyen HTTP header’ıdır. max-ageyanıtın ne kadar süre taze kabul edileceğini, s-maxageise paylaşılan cache ortamlarındaki tazelik süresini belirleyebilir.
no-cachesaklamayı yasaklamaz; yeniden kullanmadan önce doğrulama ister.no-storeyanıtın saklanmamasını ister.privatepaylaşılan cache’i sınırlar; önceden saklanan yanlış kopyayı silmez.
Gerçekçi bir WordPress örneği
Bir reverse proxy, site genelindeki public, s-maxage=3600kuralını girişli hesap yanıtına da uyguluyor. CDN kullanıcı adını içeren HTML’i saklıyor. Aynı sitedeki hash’li font dosyası ise no-cachenedeniyle her ziyarette doğrulanıyor.
Kural yanıt sınıfına göre ayrılıyor: kişisel sayfa uygun private/no-storepolitikası alıyor, sürümlü font uzun public, immutablesüreyle sunuluyor. Yanlış saklanan hesap URL’si CDN’den ayrıca temizleniyor.
Neden önemlidir ve ne zaman kullanılır?
Yanlış header gizlilik ihlali, eski içerik veya gereksiz ağ trafiği yaratabilir. public, özel veriyi güvenli hâle getirmez; yalnızca paylaşılan önbelleklerin yanıtı saklayıp yeniden kullanmasına izin verir.
Web sunucusu, WordPress eklentisi, reverse proxy veya CDN aynı header’ı yazabilir. Kural değişince origin yanıtıyla genel URL’deki son yanıtı ayrı inceleyin.
Yeni başlayanlar için anlaşılır yol
- Genel HTML, girişli HTML, API, indirme, sürümlü varlık, hata ve yönlendirmeleri sınıflandırın.
- Her sınıfın son
Cache-Control,Vary, çerez,Ageve cache status değerini alın. - Kişisel içerikte ihtiyatlı
private/no-storepolitikasıyla başlayın. - Sürümlü statik dosyalar için ihtiyaca uygun, uzun bir cache süresi kullanabilirsiniz.
- Oturum açma ve kapatma, içerik güncellemeleri ve deployment sonrasında yanıtların güncelliğini ve kullanıcılar arasındaki cache yalıtımını test edin.
İleri teknik yol
Birden fazla Cache-Controlsatırı aracılar tarafından beklenmedik biçimde birleştirilebilir. Header’ı hangi katmanın yazdığını veya üzerine yazdığını origin–edge karşılaştırmasıyla belirleyin.
Varyve cache anahtarını Authorization, dil, kodlama ve gerçekten değişen çerezlerle eşleyin.- Koşullu
304yanıtının da doğru gizlilik politikasını taşıdığını doğrulayın. stale-while-revalidatekullanımında kabul edilen eskilik süresini belirleyin.- Yanlış policy sonrası ilgili CDN kaydını ayrıca purge edin.
Riskler, sık hatalar, yedekleme ve geri alma
Tek statik varlık için site genelinde publiceklemek, dinamik ve kişisel yanıtları tehlikeye atabilir. WordPress nocache_headers()çağrısının sonraki proxy/CDN kuralını otomatik yönettiğini de varsaymayın.
no-cacheileno-storeyönergelerini eş anlamlı kullanmayın.- Yeni private kuralın önceki ortak kopyayı sildiğini sanmayın.
- Header’ı yalnız yönetici oturumundan kontrol etmeyin.
Önceki kuralı kaydedin. Gizlilik riski görülürse ilgili edge kaydını hemen temizleyip kişisel yanıtın yeniden saklanmadığını doğrulayın.
AIOWS nasıl yardımcı olur?
AIOWS Önbellek Yöneticisi
AIOWS Önbellek Yöneticisi, WordPress tarafındaki desteklenen cache seçeneklerini merkezi biçimde yönetmeye yardımcı olur. Cache-Control çalışmasında önce yanıt sınıflarını ayırmak gerekir; girişli hesap sayfasıyla sürümlü CSS dosyasına aynı politika uygulanmamalıdır.
Desteklenen ayar değiştirildikten sonra origin ve genel URL’deki son header’ları karşılaştırın. Anonim HTML’de beklenen tazelik, kişisel sayfada güvenli depolama kısıtı ve sürümlü statik dosyada uzun yeniden kullanım ayrı ayrı doğrulanmalıdır. Giriş, çıkış ve içerik güncellemesi sonrası cache status ile Agedeğerlerini kontrol edin.
AIOWS, reverse proxy veya CDN tarafından daha sonra eklenen ya da üzerine yazılan header’ları denetleyemez; ayrıca edge katmanında daha önce yanlış cache’lenmiş bir yanıtı her ortamda kendiliğinden silemez. Bu katmanlar ayrıca yönetilmelidir. Modül bu sınırlar içinde WordPress seçeneğini görünür tutmayı, kontrollü değişiklik yapmayı ve sonuç başarısızsa önceki kurala dönmeyi kolaylaştırır.
AIOWS Önbellek Yöneticisi’ni inceleyinAIOWS planlarını karşılaştırın
İlgili AIOWS yazıları
- WordPress Önbellekleme Nasıl Çalışır? Sayfa, Tarayıcı, Nesne ve CDN
- WordPress Tarayıcı Önbelleği Nasıl Ayarlanır?
- WordPress Önbelleği Ne Zaman Temizlenmeli?
Sonuç ve önerilen yol
Cache-Control’ü site geneline kopyalanan bir hız ayarı değil, yanıt sınıfına ait politika olarak ele alın. Kişisel içeriği koruyun, sürümlü varlıklarda uzun tazelik kullanın ve son header’ı bütün proxy/CDN katmanlarından sonra doğrulayın.
