CDN kullanan bir sitede ETag ayarının gerekli olup olmadığı, tek bir “açık” veya “kapalı” cevabıyla değerlendirilecek kadar basit değildir. ETag, tarayıcı önbelleğinin bir dosyanın değişip değişmediğini doğrulamasına yardımcı olur; CDN ise bu dosyaları kullanıcıya en yakın kenar sunucudan ileterek performansı artırır. Bu iki mekanizma birlikte çalışabilir, ancak yanlış yapılandırıldığında gereksiz doğrulama istekleri, tutarsız önbellek davranışı ve beklenmeyen performans kayıpları oluşabilir.
Özellikle WordPress, WooCommerce veya sık güncellenen kurumsal sitelerde amaç yalnızca sayfayı hızlı açmak değildir. İçeriğin doğru sürümünün gösterilmesi, CSS ve JavaScript dosyalarının zamanında yenilenmesi, yönetici paneli ve kullanıcı oturumlarının etkilenmemesi de aynı ölçüde önemlidir. Bu nedenle ETag kararını CDN, web sunucusu ve hosting altyapısı birlikte değerlendirilerek vermek gerekir.
ETag nedir ve önbellekte ne işe yarar?
ETag, sunucunun bir dosya veya kaynak için ürettiği benzersiz doğrulama değeridir. Tarayıcı daha önce indirdiği bir dosya için yeniden istek gönderdiğinde, bu değer üzerinden “dosya değişti mi?” kontrolü yapılır. Dosya değişmediyse sunucu genellikle 304 Not Modified yanıtı döndürür ve tarayıcı mevcut kopyayı kullanır.
Bu yaklaşım bant genişliğini azaltabilir; ancak her durumda en hızlı çözüm olmayabilir. Çünkü dosya indirilmeden önce yine de bir doğrulama isteği yapılır. CDN kullanılan yapılarda asıl hedef, bu doğrulama sürecini mümkün olduğunca kenar sunucuda çözmek ve origin sunucuya gereksiz trafik göndermemektir.
CDN kullanılan sitelerde ETag her zaman gerekli mi?
Statik dosyalar için CDN zaten güçlü bir önbellekleme katmanı sağlıyorsa ETag çoğu zaman kritik bir gereklilik değildir. Hatta bazı senaryolarda kapatılması daha stabil sonuç verebilir. Özellikle birden fazla origin sunucu, load balancer veya farklı dosya sistemi imzası kullanan yapılarda ETag değerleri sunucudan sunucuya değişebilir. Bu durumda CDN aynı dosyayı farklıymış gibi algılayabilir.
Tek sunuculu, basit bir kurulumda ETag genellikle sorun çıkarmaz. Ancak ölçeklenen yapılarda veya agresif CDN cache politikalarında ETag ayarı CDN kullanılan sitelerde gerekli midir sorusunun cevabı daha çok “mimariye bağlıdır” şeklindedir.
ETag ne zaman kapatılabilir?
CDN tüm statik varlıkları cache-control başlıklarıyla etkin biçimde yönetiyorsa, ETag kapatmak mantıklı olabilir. Örneğin CSS, JS, görsel ve font dosyalarında uzun süreli önbellek kullanılıyor; dosya güncellemeleri de versiyon parametresi veya dosya adı değişikliğiyle yönetiliyorsa ETag çoğu zaman ek fayda sağlamaz.
Ayrıca çoklu sunucu ortamlarında ETag değerlerinin inode, dosya boyutu veya zaman damgası gibi sunucuya özel bilgilerden üretilmesi tutarsızlığa yol açabilir. Bu durumda kullanıcı bazı dosyaların güncellenmediğini, bazılarının ise gereksiz yere yeniden doğrulandığını görebilir.
Pratik kontrol listesi
- CDN statik dosyaları gerçekten cache’liyor mu?
- Cache-Control ve Expires başlıkları doğru geliyor mu?
- Dosya güncellemelerinde versiyonlama kullanılıyor mu?
- Birden fazla origin veya load balancer var mı?
- Tarayıcı geliştirici araçlarında gereksiz 304 istekleri yoğun mu?
Bu sorulardan birkaçına “evet” yanıtı veriliyorsa ETag’i kapatıp test etmek genellikle doğru bir adımdır.
ETag ne zaman açık kalabilir?
Dinamik olmayan fakat sık değişebilen belirli kaynaklarda, CDN kısa süreli önbellek kullanıyorsa ETag yararlı olabilir. Örneğin doküman, JSON çıktı veya belirli API yanıtlarında kaynak değişimini hassas biçimde takip etmek gerekebilir. Burada önemli olan CDN’in ETag başlığını nasıl işlediğini bilmektir.
Bazı CDN servisleri ETag başlığını origin’den alıp aynen iletir, bazıları sıkıştırma veya optimizasyon sırasında bu başlığı değiştirebilir ya da kaldırabilir. Bu nedenle yalnızca WordPress eklentisindeki bir seçeneğe bakarak karar vermek yeterli değildir; yanıt başlıkları doğrudan test edilmelidir.
WordPress sitelerde doğru yaklaşım nasıl olmalı?
WordPress tarafında en güvenli yöntem, statik varlıklarda dosya versiyonlamasını doğru kullanmak ve CDN cache kurallarını buna göre ayarlamaktır. Tema veya eklenti güncellemelerinde CSS ve JS dosyalarının eski sürümden gelmemesi için versiyon parametreleri önemlidir. CDN tarafında query string davranışı da buna uygun yapılandırılmalıdır.
Birçok performans eklentisi ETag, cache-control, gzip veya Brotli gibi ayarları aynı ekranda sunar. Burada yapılan yaygın hata, tüm performans seçeneklerini aynı anda açmaktır. Önce mevcut başlıklar kontrol edilmeli, ardından tek tek değişiklik yapılıp etkisi ölçülmelidir.
Nasıl test edilir?
Tarayıcı geliştirici araçlarında Network sekmesi açılarak CSS, JS ve görsel dosyalarının yanıt başlıkları incelenebilir. İlk istekte 200, tekrar ziyarette disk cache, memory cache veya 304 yanıtları görülebilir. CDN panelindeki cache hit oranı da ayrıca değerlendirilmelidir. Cache hit oranı düşükse problem ETag’den çok cache kuralı, query string politikası veya yanlış dosya yolu eşleştirmesi olabilir.
Karar verirken dikkat edilmesi gerekenler
Kurumsal bir sitede hedef, yalnızca test aracında yüksek puan almak değil, kullanıcıya tutarlı ve hızlı deneyim sunmaktır. Bu nedenle ETag ayarı; CDN sağlayıcısı, web sunucusu türü, WordPress cache eklentisi ve hosting altyapısının çalışma biçimiyle birlikte ele alınmalıdır.
Tek origin sunuculu küçük sitelerde ETag açık kalsa da büyük bir sorun yaratmayabilir. Çoklu origin, yoğun CDN kullanımı ve uzun süreli statik dosya cache politikalarında ise ETag’i kapatmak daha sade ve öngörülebilir bir yapı sağlayabilir. Değişiklik yapmadan önce mevcut başlıkların kaydedilmesi, ardından aynı dosyalar üzerinde tekrar test yapılması en sağlıklı yöntemdir.
Uygulamada en iyi yaklaşım, statik dosyalar için güçlü Cache-Control kuralları ve dosya versiyonlama kullanmak; ETag’i ise gerçekten doğrulama değeri gereken kaynaklarla sınırlı değerlendirmektir. Böylece CDN, origin sunucuya daha az başvurur ve kullanıcılar güncel dosyalara gereksiz bekleme yaşamadan erişebilir.