Stale-while-revalidate HTTP Cache-Control yönergesi, tarayıcıların önbelleğe alınmış içeriği derhal sunmasına ve aynı zamanda arka planda eşzamansız olarak yeniden doğrulamasına olanak tanır. Bu özellik, kullanıcıların sunucudan taze içerik indirmeyi bekleyerek harcadığı süreyi azaltarak site performansını artırmanın birincil yöntemidir. Bu başlığı ayarlayarak, tarayıcıya, tarayıcı eşzamanlı olarak sunucuda daha yeni bir sürüm olup olmadığını kontrol ederken, eğer hala eski (stale) pencere içerisindeyse bir sayfanın veya varlığın mevcut, önbelleğe alınmış bir sürümünü görüntülemesini talimatını verirsiniz.
Neden stale-while-revalidate kullanmalısınız?
Web performansı, tekrar gelen ziyaretçiler için gecikmeyi en aza indirmeye büyük ölçüde dayanır. Tipik bir hesapta, bir kullanıcı günde birkaç kez bir açılış sayfasını ziyaret edebilir. Önbellek başlıklarınız çok katıysa, tarayıcı sürekli olarak sunucuya onay ister, bu da deneyimi yavaşlatır. Stale-while-revalidate kullanmak, taze veri ihtiyacını yerel önbelleğe almanın hızıyla etkili bir şekilde dengeler. Bir varlığın ilk render aşamasında bir ağ yanıtını beklemek zorunda kalmaktan kaçınarak kullanıcı arayüzünü hızlı tutar.
Bu yönerge, milisaniye düzeyinde kusursuz doğruluk gerektirmeyen varlıklar için özellikle yararlıdır. Örneğin, bir ürün fiyatlandırma sayfasını veya günde birkaç kez güncellenen bir blog akışını düşünün. Bu yönergeyi kullanarak, tarayıcının önbelleğe alınmış içeriği hemen göstermesine izin vermiş olursunuz. Bu içerik belirttiğiniz max-age süresinden eskiyse ancak stale-while-revalidate penceresi içindeyse, tarayıcı güncellemeyi arka planda getirir. Kullanıcı sayfayı anında görür ve bir sonraki ziyaretinde yeni verileri görür.
Yönergenin sözdizimi nasıldır?
Yönerge, Cache-Control HTTP başlığı aracılığıyla uygulanır. Tarayıcıya içeriğin ne kadar süreyle taze kabul edileceğini söylemek için bir max-age tanımlarsınız ve ardından stale-while-revalidate parametresini eklersiniz. Örneğin, yaygın bir yapılandırma şöyle görünür: Cache-Control: max-age=60, stale-while-revalidate=3600. Bu yapılandırma tarayıcıya varlığın 60 saniye boyunca taze olduğunu söyler. 60 saniyeden sonra ancak 3600 saniyeden önce bir istek gerçekleşirse, tarayıcı eski içeriği sunar ve arka planda bir getirme işlemi başlatır.
- max-age: İçeriğin taze kabul edildiği süreyi belirler.
- stale-while-revalidate: max-age süresi dolduktan sonra tarayıcının bir güncelleme getirirken eski içeriği kullanabileceği zaman penceresini belirler.
- Private ve Public: Bu başlıklar, içeriğin nerede depolandığını kontrol etmek için private veya public yönergeleriyle birleştirilebilir; örneğin tarayıcı önbelleği ile paylaşılan bir CDN önbelleği gibi.
Sunucunuzu bu başlık için nasıl yapılandırırsınız
Bunu sunucunuzda uygulamak için istemciye gönderilen yanıt başlıklarını değiştirmeniz gerekir. Nginx kullanıyorsanız, statik varlıklarınız veya API uç noktalarınız için location bloğu içinde yapılandırma dosyanızı ayarlarsınız. Örnek bir satır şu şekilde olur: add_header Cache-Control ‘public, max-age=86400, stale-while-revalidate=86400’;. Bu yaklaşım, sunucunuzun önbellekleme stratejisini kaynaklarınızı talep eden her tarayıcıya net bir şekilde iletmesini sağlayarak son kullanıcılarınız için daha tutarlı bir deneyim sunar.
Apache kullanan geliştiriciler için, aynı sonucu elde etmek için mod_headers modülünü kullanabilirsiniz. .htaccess dosyanıza şu şekilde bir satır eklersiniz: Header set Cache-Control ‘max-age=604800, stale-while-revalidate=86400’. Bu değişiklikler dağıtıldıktan sonra, tarayıcı geliştirici araçlarında yanıt başlıklarını kontrol etmek iyi bir uygulamadır. Ağ (Network) sekmesini açın, sayfayı yenileyin ve Cache-Control değerinin amaçlanan yapılandırmanızla eşleştiğini doğrulamak için kaynağı seçin.
Önbellekleme Stratejilerinin Karşılaştırması
| Strateji | Anlık Hız | Tazelik |
|---|---|---|
| Standart Önbellek | Yüksek | Düşük |
| No-Cache | Düşük | Yüksek |
| Stale-While-Revalidate | Yüksek | Yüksek |
Alien Road stale-while-revalidate yöntemini nasıl uygular
Alien Road olarak, web arayüzleri oluştururken veya optimize ederken sıklıkla müşteri performans metriklerini inceleriz. Tipik bir projede, önce mevcut sunucu yanıt sürelerini ve sunulan içeriğin doğasını inceleriz. Bir sitenin statik varlıklara veya yavaş değişen sık erişilen verilere dayandığını tespit edersek, bu yönergenin uygulanmasını öneririz. Özellikle hassas kullanıcı verileri içeren sayfalar için uygulamanın güvenlik gereksinimleriyle çelişmemesini sağlarız.
Süreçimiz, mevcut başlık yapılandırmalarının kontrol edilmesini ve farklı tarayıcılarda yükleme sürelerinin test edilmesini içerir. Ardından, içeriğin özel güncelleme sıklığına göre max-age ve stale-while-revalidate aralıklarını ayarlarız. Örneğin, bir haber sitesi daha kısa aralıklar gerektirebilirken, bir şirket portföyü sayfası daha uzun aralıklardan faydalanabilir. Bu ayarları belgelendiriyoruz, böylece müşteri ekibi belirli varlıkların neden önbelleğe alınmış göründüğünü ve arka plan güncellemelerinin genel kullanıcı deneyimini nasıl etkilediğini anlar.
Hangi varlıklar bu yaklaşım için en uygundur?
Web sitenizdeki her varlık stale-while-revalidate için bir aday değildir. Acil güvenlik için kritik olmayan varlıkları veya içerik güncellemesinde küçük bir gecikmenin kabul edilebilir olduğu varlıkları önceliklendirmelisiniz. Görseller, CSS dosyaları, JavaScript paketleri ve yarı statik API yanıtları ideal adaylardır. Bu yönergeyi bu dosyalarda kullanarak, orijinal sunucunuzdaki (origin server) yükü azaltır ve ziyaretçilerin mümkün olan en hızlı render sürelerini almasını sağlarsınız.
- CSS ve JavaScript dosyaları: Bunlar, anlık güncellemeler gerektirecek kadar köklü bir şekilde nadiren değişir.
- Ürün görselleri: Bunları uzun bir yeniden doğrulama penceresiyle saklamak önemli ölçüde bant genişliği tasarrufu sağlar.
- JSON veri akışları: Periyodik olarak güncellenen hassas olmayan veriler, arka plan yeniden doğrulamasıyla iyi çalışır.
Kaçınılması gereken yaygın tuzaklar
Sık yapılan bir hata, yüksek hassasiyet gerektiren içerikler için yeniden doğrulama penceresini çok uzun ayarlamaktır. Bir kullanıcı canlı bir hisse senedi fiyatı veya kritik bir uyarı görmeyi bekliyorsa, eski içeriği sunmak ters etki yaratabilir. Dakikalar veya saatler öncesine ait bilgileri sunmanın iş üzerindeki etkisini her zaman değerlendirin. Ek olarak, form gönderimleri veya hesap eylemleri sırasında güvenlik açıklarını önlemek için her zaman taze olması gerektiğinden, bunu kimlik doğrulama token’larına veya CSRF token’larına uygulamaktan kaçının.
Bu hafta nereden başlamalı
Web sitenizde en çok erişilen beş statik kaynağı belirleyerek başlayın. Her biri için mevcut Cache-Control başlığını incelemek üzere tarayıcı geliştirici araçlarınızı kullanın. stale-while-revalidate bileşeni olmayan bir max-age görürseniz, o belirli dosyanın ne sıklıkta değiştiğine bağlı olarak uygun bir yeniden doğrulama penceresi hesaplayın. Canlı prodüksiyon sitenize dağıtmadan önce tarayıcı davranışının beklentilerinizle eşleştiğini doğrulamak için değişikliği önce bir hazırlık (staging) ortamında sunucu yapılandırmanıza uygulayın.
Sıkça Sorulan Sorular
Bu tüm tarayıcılarda çalışır mı?
Çoğu modern tarayıcı stale-while-revalidate yönergesini destekler. Standart Cache-Control spesifikasyonunun bir parçası olduğu için, parametreyi tanımayan tarayıcılar onu basitçe yok sayacak ve standart max-age talimatlarını takip edecektir. Bu, arka plan yeniden doğrulama sürecini desteklemeyen eski tarayıcılar için deneyimi bozmadan mevcut önbellekleme stratejinize ekleyebileceğiniz güvenli bir ilerici iyileştirme (progressive enhancement) yapar.
Bunu bir CDN ile kullanabilir miyim?
Evet, birçok modern İçerik Dağıtım Ağı (CDN) stale-while-revalidate özelliğini destekler. Bir CDN bu başlığı orijinal sunucunuzdan aldığında, içeriği önbelleğe alabilir ve arka plan yeniden doğrulama sürecini kendi yürütebilir. Bu, orijinal sunucu trafiğini azaltmak için son derece etkilidir. Bu yönergeyi destekleyip desteklemediklerini ve uç katmanda (edge layer) etkinleştirmek için herhangi bir özel yapılandırma adımı gerekip gerekmediğini doğrulamak için CDN sağlayıcınızın belgelerini kontrol edin.
Arka plan güncellemesi başarısız olursa ne olur?
Arka plan yeniden doğrulama isteği başarısız olursa, tarayıcı genellikle önbelleğinde zaten bulunan içeriğin eski sürümünü kullanmaya devam edecektir. Tarayıcı ziyaretçiye bir hata göstermediği için kullanıcı deneyimi kesintisiz kalır. Kullanıcı kaynağı bir sonraki kez talep ettiğinde, tarayıcının dahili mantığına ve önbelleğin durumuna bağlı olarak tarayıcı yeniden doğrulama sürecini tekrar deneyebilir.
Bu ETag doğrulamasından daha mı iyidir?
Bu iki yöntem farklı amaçlara hizmet eder. ETag doğrulaması, içeriğin değişip değişmediğini kontrol etmek için sunucuya gidiş-dönüş (round-trip) gerektirir, bu da hala bazı gecikmeler ortaya çıkarır. Stale-while-revalidate yönergesi, önbelleğe alınmış içeriği hemen göstererek bu gecikmeyi tamamen ortadan kaldırır. Önbellek yeniden doğrulandığında bile tarayıcının yalnızca içerik gerçekten değiştiyse tam yükü indirmesini sağlamak için bunları birlikte kullanabilir, böylece daha da fazla bant genişliği tasarrufu sağlayabilirsiniz.
Okumaya devam edin: Web Tasarım ve Geliştirme · Web Tasarım