WordPress’te .htaccess ile Tarayıcı Önbellek Başlıkları Nasıl Eklenir?

Bir yıllık tarayıcı önbelleği performansı iyileştirebilir; ancak aynı kural sürümlenmeyen bir JavaScript dosyasına veya dinamik HTML’e uygulanırsa ziyaretçiler günlerce eski içeriği görebilir. CDN’in eklediği ikinci bir Cache-Controlbaşlığı da tarayıcıya hangi politikanın uygulanacağını belirsiz hâle getirir.

Bu rehber, WordPress’te tarayıcı önbellek başlıklarını .htaccessüzerinden güvenli biçimde planlamayı anlatır. Statik dosyalar ile dinamik yanıtları nasıl ayıracağınızı, uzun önbellek süresinin ne zaman güvenli olduğunu ve son yanıtın gerçekten hangi katmanda oluşturulduğunu nasıl doğrulayacağınızı göreceksiniz.

Tarayıcı önbellek başlıkları nedir?

Tarayıcı önbellek başlıkları, bir yanıtın istemcide veya paylaşımlı önbellekte ne kadar süre saklanabileceğini ve ne zaman yeniden doğrulanması gerektiğini belirtir. Cache-Controlbu davranışı max-age, public, private, no-cacheve immutablegibi yönergelerle tanımlar. Expiresise sona erme zamanını mutlak tarih olarak bildirir.

Uzun süreli önbellek, içerik değiştiğinde URL’si de değişen CSS, JavaScript, görsel ve font dosyalarında etkilidir. WordPress sayfaları, oturum açmış kullanıcılara verilen yanıtlar, WooCommerce sepeti ve hesap ekranları ise aynı politikaya uygun değildir. Bu içerikler kişiye veya zamana göre değişebildiğinden daha kısa ve kontrollü bir önbellek stratejisi ister.

Gerçekçi bir WordPress örneği

Bir ekip, örnek bir yapılandırmadan aldığı bir yıllık önbellek süresini tüm siteye uyguluyor. Yeni sürüm yayımlandığında app.jsdosyasının URL’si değişmediği için bazı ziyaretçiler eski JavaScript’i kullanmaya devam ediyor. Aynı sırada CDN de kendi Cache-Controlbaşlığını ekliyor ve origin ile ziyaretçinin gördüğü yanıt birbirinden ayrılıyor.

Doğru çözüm, tüm dosyalara tek süre vermek değildir. Önce statik dosyaların her yayında yeni bir sürüm parametresi veya hash içeren dosya adı alıp almadığını belirleyin. Ardından HTML ve kullanıcıya özel sayfaları uzun önbelleğin dışında tutun. Son olarak origin, CDN ve tarayıcı yanıtlarını ayrı ayrı inceleyerek ziyaretçiye ulaşan tek ve tutarlı politikayı doğrulayın.

Neden önemlidir ve ne zaman kullanılır?

Doğru tarayıcı önbelleği, tekrar ziyaretlerde aktarılan veri miktarını azaltır ve statik kaynakların daha hızlı yüklenmesini sağlar. Özellikle değişmeyen tema dosyaları, fontlar ve sürümlenmiş görseller için uzun süreler gereksiz yeniden indirmeleri önler.

Bununla birlikte önbellek süresi, yayın sürecinden bağımsız düşünülemez. Dosya içeriği değiştiğinde URL aynı kalıyorsa aylar süren max-ageeski kodu ziyaretçinin tarayıcısında kilitleyebilir. immutableyönergesi de yalnızca URL’nin içerik değiştiğinde kesin olarak yenilendiği dosyalarda kullanılmalıdır. CDN veya optimizasyon eklentisi başlıkları zaten yönetiyorsa .htaccessiçine ikinci bir politika eklemek yerine denetimi tek katmanda toplamak daha güvenlidir.

Yeni başlayanlar için güvenli uygulama

1. CSS, JavaScript, görsel ve font URL’lerinin yayın sırasında nasıl sürümlendiğini belirleyin. İçerik değiştiğinde URL değişmiyorsa çok uzun önbellek süresi kullanmayın.
2. Tarayıcıya ulaşan mevcut Cache-Controlve Expiresbaşlıklarını inceleyin. Origin yanıtını CDN üzerinden gelen yanıtla karşılaştırın.
3. Etkin .htaccessdosyasını yedekleyin ve hosting paneli ya da FTP üzerinden dosyaya erişimi hazır tutun.
4. Kuralı yalnızca uygun statik uzantılarla sınırlandırın. HTML, PHP çıktısı, yönetim ekranları, sepet ve hesap sayfalarını uzun süreli publicönbelleğe dahil etmeyin.
5. Önce kısa ve ölçülü bir süreyle deneyin. Başlıkların tek kez gönderildiğini ve hedef dosya türlerinde beklendiği gibi değiştiğini doğrulayın.
6. Standart yayın süreciyle zararsız bir CSS veya görsel değişikliği yapın. Yeni dosyanın ziyaretçiye ulaştığını, eski URL’nin ise belirlenen politika uyarınca davrandığını sınayın.

İleri teknik yaklaşım

İleri incelemede yalnızca .htaccessiçeriğine bakmak yeterli değildir. Apache modülleri, WordPress eklentileri, reverse proxy ve CDN aynı yanıta başlık ekleyebilir. Tarayıcıya ulaşan nihai yanıtı belirlemek için origin adresini, ziyaretçiye açık URL’yi ve mümkünse farklı bir CDN noktasını karşılaştırın.

• mod_expiresve mod_headersdesteğini doğrulayın. <IfModule>bloğu eksik modülün 500 hatasına yol açmasını önleyebilir; ancak kuralın sessizce uygulanmaması ihtimalini de gizler.
• Dosya türlerini gerçek Content-Typedeğerleriyle eşleştirin. WebP, AVIF, WOFF2 ve build sisteminin ürettiği diğer formatları test kapsamına alın.
• Hash içeren dosya adlarında uzun max-ageve gerektiğinde immutablekullanılabilir. Aynı adla üzerine yazılan logo.pnggibi dosyalarda daha kısa süre ya da güvenilir yeniden doğrulama tercih edin.
• ETagve Last-Modifieddoğrulamasını 304 yanıtlarından ayırın. Tarayıcı önbelleğinden hiç ağ isteği yapılmadan yüklenen dosya ile sunucuda yeniden doğrulanan dosya aynı davranış değildir.
• CDN purge sürecini dosya saklama politikasıyla birlikte planlayın. Eski HTML bir süre daha eski hash’li dosyaya başvuruyorsa bu dosyayı edge noktalarından erken kaldırmak sayfayı bozabilir.

Riskler, sık hatalar, yedek ve rollback

En ciddi risk, dinamik veya kişisel bir yanıtı paylaşımlı önbelleğe açık hâle getirmektir. Oturum açmış kullanıcı sayfalarına ve WooCommerce verilerine, ziyaretçiye açık içerik için tanımlanan genel publicönbellek kurallarını uygulamayın. Aynı başlığın Apache, eklenti ve CDN tarafından farklı değerlerle gönderilmesi de öngörülemeyen sonuçlara yol açabilir.

• Değişiklikten önce etkin .htaccessdosyasının bağımsız bir kopyasını saklayın.
• 500 hatası oluşursa yeni bloğu kaldırın veya yedekten önceki dosyaya dönün.
• Başlık doğru görünse bile güncelleme senaryosunu sınamadan uzun süreye geçmeyin.
• Rollback sonrasında origin ve CDN önbelleklerini gerektiği kadar temizleyin; statik kaynakların ve dinamik sayfaların önceki politikaya döndüğünü doğrulayın.

İlgili AIOWS yazıları

• WordPress Önbelleğini Temizleme: Sayfa, Nesne, Tarayıcı ve CDN
• WordPress Önbellekleme Nasıl Çalışır? Sayfa, Tarayıcı, Nesne ve CDN
• WordPress’te .htaccess ile Güvenlik Başlıkları: HSTS, CSP ve Daha Fazlası

Sonuç ve önerilen yol

Uzun tarayıcı önbelleğini yalnızca içerik değiştiğinde URL’si de değişen statik dosyalara uygulayın. Dinamik ve kullanıcıya özel yanıtları ayrı tutun; origin, CDN ve tarayıcı davranışını standart bir yayın denemesiyle doğrulamadan süreleri uzatmayın.

Resmî kaynaklar

• MDN HTTP önbellekleme rehberi
• Apache .htaccess rehberi