Bir kütüphanenin ana sayfasında bugünkü çalışma saatlerini değiştirdiğinizi, ancak bazı ziyaretçilerin hâlâ eski saatleri gördüğünü düşünün. Önce sunucudaki asıl içeriğin güncellenmemesi, tarayıcının sakladığı yanıtı yeniden kullanması ve aradaki bir sunucunun eski sürümü vermesi olasılıklarını ayırmak gerekir. Sayfayı birçok kez yenilemiş olmak, sorunun hangi aşamada bulunduğunu tek başına göstermez.
HTTP önbelleği, alınan yanıtları saklayıp koşullar uygun olduğunda yeniden kullanan bir mekanizmadır. Bu makale, herkese açık bir çalışma saatleri çizelgesi üzerinden kurulan varsayımsal örnekle Cache-Control saklama/doğrulama yönergelerini ETag ve 304 yanıtlarına bağlar. Aşağıdaki iletişim kayıtları açıklama amacıyla kısaltılmıştır; gerçek bir kütüphanede veya belirli bir sunucuda yapılmış ölçümler değildir. Amaç, bütün önbellekleri kaldırmayı önermekten çok hangi yanıtın ne zaman yeniden kullanılabilmesi gerektiğini açıklamaktır.
1. Saklamak, denetleyip kullanmak ve paylaşmak
Bir önbellek politikasını okurken üç soruyu ayrı yazın: Yanıt saklanabilir mi, saklanan kopya sonraki istekte doğrudan kullanılabilir mi ve birden fazla kullanıcıyla paylaşılabilir mi? Saklama izni, her zaman yeniden kullanım izni anlamına gelmez; güncelliğin denetlenmesi de başka kullanıcılarla paylaşımı uygun hâle getirmez. HTTP önbellekleme standardı RFC 9111, bu koşulları ayrı yönergelerle tanımlar. Burada, başlık alanı adlarının ayrıca argüman olarak verilmediği yanıt yönergeleri ele alınmaktadır.
| Sorulacak soru | İlgili yanıt yönergesi | Ayırt edilecek anlam |
|---|---|---|
| Yanıtın saklanması yasak mı? | no-store | Daha sonra yeniden kullanmak üzere saklamayı yasaklayan yönerge |
| Yeniden kullanmadan önce denetim gerekli mi? | no-cache | Saklanabilir, fakat yeniden kullanımdan önce başarılı doğrulama gerekir |
| Birden fazla kullanıcıyla paylaşılabilir mi? | private | Paylaşılan önbellekte saklamayı engeller; özel önbellekte saklamayı bütünüyle yasaklamaz |
Örneğin herkese açık saatleri aynı adreste sık sık değiştiriyorsanız, saklanan kopya bulunsa bile kullanmadan önce denetlenmesi gereksinimini değerlendirebilirsiniz. Kişiye özel ekranların paylaşım koşulları, herkese açık çizelgeninkinden farklıdır. private, paylaşılan önbelleğe ilişkin bir yönergedir; oturum açma ve yetki denetimlerinin yerine geçmez. Farklı amaçlara hizmet eden ayarları tek cümlede birleştirirseniz hızı iyileştirirken bilginin kimlere gösterileceğini yanlış belirleyebilirsiniz.
Politika tablosunda yalnızca yönergeyi değil, gerekçesini de kaydedin. Çizelgenin değişiklik denetimi gerektiren kamusal bilgi olup olmadığını, logonun içeriği sabit bir dosya olup olmadığını ve aynı adresten kişiselleştirilmiş bilgi sunulup sunulmadığını birlikte belirtin. Bu tablo bütün sitelere uygulanacak hazır bir yapılandırma değil, gerçek yanıtları sınıflandırmaya başlamanın bir yoludur. Tarayıcı veya CDN gibi hangi depoya uygulandığını da ayırmalısınız.
2. no-cache ile no-store arasında yalnızca ada bakarak seçim yapmayın
no-cache adını saklama yasağı gibi okumak kolaydır; oysa yanıttaki no-cache, saklanan kopyanın yeniden kullanılmadan önce doğrulanmasını ister. Sunucu değişiklik olmadığını doğrularsa saklanmış gövdeyi yeniden kullanmak mümkün olabilir. no-store ise bu yanıtın saklanmamasını isteyen yönergedir. Neyin tutulacağı ve sonraki istekte neyin denetleneceği farklı olduğundan iki ayarın aynı şekilde davranmasını beklemeyin.
Önbellekte fresh, politikanın ek doğrulama olmadan yeniden kullanıma izin verdiği durumu belirtir. Bu, işletmecinin o sırada içeriği değiştirmediğinin garantisi değildir. Yeniden kullanım süresi max-age ile belirlenmişse asıl içerik bu süre içinde değişse de önceden saklanan yanıt seçilmeye devam edebilir. Önce kabul edilebilir güncelleme gecikmesini belirleyip bu gereksinimi yönergeyle ilişkilendirin. Gelişigüzel uzun bir saklama süresini performans iyileştirmenin doğru cevabıymış gibi kopyalamayın.
MDN HTTP önbellekleme rehberi, yeni yanıta no-store eklemenin aynı URL için önceden saklanmış eski yanıtı silmediğini açıklar. Eski kopya hâlâ geçerliyse ve yeni yanıt için istek yapılmıyorsa yeni başlık da hiç ulaşmayabilir. no-store ifadesini bütün önbelleği temizleme komutu veya gizliliğin yeterli koşulu olarak görmeyin; mevcut yanıtların ömrünü ve yönetebildiğiniz önbelleklerin güncellenme sürecini de inceleyin.
3. ETag ve 304 ile bir yeniden ziyareti izlemek
Varsayımsal /hours.json adresinin başlangıçta kapanış saatini 18:00 olarak bildirdiğini düşünün. Aşağıdaki açıklayıcı HTTP/1.1 örneğinde yalnızca gerekli kısımlar tutulmuş, gerçek yanıtta gereken diğer başlıklar çıkarılmıştır. hours-v1, bu örnekte sunucunun seçtiği temsilin tanımlayıcısıdır; saat hesaplayan bir formül veya gerçek dosya özeti değildir.
HTTP/1.1 200 OK
Content-Type: application/json
Cache-Control: no-cache
ETag: "hours-v1"
{"closes":"18:00"}Tarayıcı bu yanıtı sakladıysa daha sonra ETag değerini koşullu isteğin If-None-Match başlığında gönderebilir. Sunucu, koşulun seçtiği güncel temsille eşleştiğini ve değişiklik olmadığını belirlerse 304 Not Modified ile yanıt verir. Aşağıdaki blok, isteği ve buna verilen yanıtı art arda gösteren kısaltılmış bir kayıttır. 304 sonrasında çizelge JSON gövdesinin yeniden gönderildiği bir örnek değildir.
GET /hours.json HTTP/1.1
Host: library.example
If-None-Match: "hours-v1"
HTTP/1.1 304 Not Modified
Cache-Control: no-cache
ETag: "hours-v1"MDN ETag açıklamasında olduğu gibi istemci bu durumda saklanan gövdeyi kullanır. 304 yeni bir gövde içermez, fakat istek ve doğrulama için iletişim yine gerçekleşir. İşletmeci kapanış saatini 19:00 olarak değiştirmiş ve sunucunun temsili de değişmişse eski koşula karşı yeni gövdeyi ve yeni tanımlayıcıyı içeren bir 200 yanıtı beklenebilir. no-cache kullanmak, her seferinde 304 alınacağı veya veritabanı sorgusunun ortadan kalkacağı anlamına gelmez.
Denetlenecek şey tek başına durum kodundan çok içerikle tanımlayıcının uyumudur. İçerik değişmişken sunucu eski ETag değerini kullanmaya devam ederse doğrulama yanlış sonuç verebilir. Tersine, içerik aynı kaldığı hâlde tanımlayıcı sürekli değişirse gövde daha sık yeniden gönderilebilir. Üretim yöntemiyle seçilen temsil arasındaki ilişki sunucuda incelenmelidir; ETag bulunması tek başına uygulamanın doğru olduğunu kanıtlamaz.
4. Sık değişen belgeyi yeni adlı varlıktan ayırmak
İçeriği aynı URL altında değişen çizelge gibi belgelerle, içerik değiştiğinde yeni dosya adı verilen logo veya betikler farklı güncelleme stratejileri gerektirebilir. Örneğin logo.a1.png yerine logo.b2.png kullanılan bir tasarımda yeni belgenin yeni adrese başvurması gerekir. Dosya adına tanımlayıcı ekleyip sonra eski dosyanın içeriğini üzerine yazarsanız içerikle adresi birlikte yönetme sözünü bozmuş olursunuz.
Yeni dosyayı yüklemek, ziyaretçinin yeni adresi isteyeceği anlamına gelmez. Ziyaretçinin aldığı HTML hâlâ eski logo adresini gösteriyorsa eski varlık yeniden kullanılabilir. Bu yüzden yalnızca varlığın önbellek ayarına değil, ona başvuran belgenin güncellenme yoluna da bakın. Belgeyle varlığın saklama süresini aynı yapmak yerine her birinin ne kadar gecikmeyle değişebileceğini açıklayabilmelisiniz.
Dağıtım sırasında eski ve yeni belgeler kısa süre birlikte kullanılabilir. Yeni varlık hazır olmadan yeni belgeyi yayımlamak veya eski varlığı çok erken silmek ayrı arızalara yol açabilir. Bu varsayımsal örnekte hem yeni belgenin başvurduğu dosyaların varlığı hem eski belgenin başvurduğu dosyalara erişim denetlenebilir. Dosya adını değiştirmek önbellek tasarımının bir aracıdır; dağıtım sırası ve geri alma sorunlarının hepsini kendiliğinden çözmez.
5. Network panelinde her seferinde tek bir varsayımı sınamak
Doğrudan incelemeye başlarken önce önbelleğe izin verilen durumda bir başlangıç kaydı alın. Tam URL ve sorguyu, ekranda görünen çizelge sürümünü, yanıt durumunu, istekteki If-None-Match ile yanıttaki Cache-Control ve ETag değerlerini birlikte inceleyin. İstek ve yanıt başlıkları aynı ada sahip olsa bile farklı tarafların koşullarını belirtir; hangisini okuduğunuzu kaydedin. Chrome DevTools Network belgesi, bu öğelerin Headers bölümünde nasıl ayrılacağını açıklar.
| Varsayımsal sınama durumu | Birlikte incelenecek kayıt | Aceleyle çıkarılmaması gereken sonuç |
|---|---|---|
| Aynı çizelgeyi yeniden isteme | Koşullu istek, durum, ekrandaki saat | 304 olduğuna göre hiç iletişim olmadı |
| Asıl saati değiştirip istek yapma | Yeni gövde, ETag, gerçek istek URL’si | Kaydetme başarılı göründüğüne göre herkese yansıdı |
| Tarayıcı önbelleği kapalıyken istek yapma | İlk indirme ile olağan yeniden ziyaretin farkı | Bu sonuç normal yeniden ziyaret hızıyla aynıdır |
| Geri düğmesiyle dönme | Yeni isteğin oluşup oluşmadığı ve geri yüklenen ekran | Ekran göründüğüne göre mutlaka yeni HTTP doğrulaması oldu |
Ardından tarayıcı önbelleğini devre dışı bırakmayı ayrı bir koşul olarak deneyin. Chrome Disable cache ayarı, DevTools açık olduğu sürece uygulanır; bu nedenle aracın açık olup olmadığını ve ayar değerini birlikte kaydedin. Bu, ilk indirmeyi incelemek için yararlıdır; fakat olağan bir yeniden ziyarette saklanan kopyanın nasıl kullanıldığını sınamakla aynı değildir. Ayarı açtığınızı kaydetmezseniz sürekli yeni indirilen sonuçlara bakıp önbelleğin çalışmadığı sonucuna varabilirsiniz. Önbelleğin yeniden izinli olduğu koşula dönüp karşılaştırabilmek için deney koşullarını saklayın.
Gözlem sırasında birden fazla değişikliği ve isteği aynı anda yapmamak nedeni daraltmayı kolaylaştırır. Önce içeriği değiştirmeden yeniden ziyareti inceleyin, sonra saatlerden birini değiştirip yanıtın nasıl farklılaştığına bakın. Belge URL’si, sunucu ayarı ve dosya adı aynı anda değişirse hangi değişikliğin sonucu doğurduğunu ayırmak güçleşir. Beklenen 200 veya 304 gelmediyse yeni ayarlar eklemeden önce gerçek istek ve yanıtı yeniden okuyun.
6. Diğer saklama yollarını ve tamamlanma ölçütünü birlikte denetlemek
Tarayıcının HTTP önbelleğini devre dışı bırakmanın sunucunun önündeki CDN’yi veya uygulamanın diğer saklama yollarını da ortadan kaldırdığını varsaymayın. Bir service worker’ın isteği işleyip işlemediğini, aradaki sunucunun hangi yanıtı seçtiğini ve uygulamanın önceden aldığı veriyi ekranda tutup tutmadığını ayrı ayrı inceleyebilirsiniz. Aynı URL’nin görünmesi, bütün katmanların aynı kopyayı kullandığını göstermez.
Geri düğmesini de yeni HTTP isteğinden ayrı inceleyin. Tarayıcı önceki oturumun ekranını geri yüklediğinde no-cache bulunsa bile beklediğiniz yeniden doğrulama isteği görünmeyebilir. Bunu hemen sunucunun başlığı yok saydığına kanıt saymak yanlış nedene götürebilir. Yeni gezinme, yenileme ve geri dönüş için gerçekten istek oluşup oluşmadığını ayrı kaydetmek, farklı olayları tek sorun altında toplamayı önler.
Çizelge örneğinde tamamlanma ölçütü yalnızca önbellek isabet oranı değildir. İçerik değişmediğinde saklanan kopyadan doğru yararlanıldığını, değişiklikten sonra kabul edilen süre içinde yeni bilginin göründüğünü ve yanıtın doğru kullanıcı grubuyla paylaşıldığını denetleyin. Değişiklik zamanı, gözlem zamanı, koşullar ve gerçek gövde kaydedilirse başkaları aynı durumu daha kolay yeniden oluşturabilir. Hız değerleri iyileşmiş ama yanlış çalışma saatleri uzun süre görünmüşse asıl gereksinim karşılanmış değildir.
Üretime uygularken yanıt türlerine göre politikayı, güncelleme ve geri alma süreciyle birlikte inceleyin. Herkese açık belgenin önbellek yönergelerini kişiye özel yanıta kopyalamayın; doğrulamanın başarılı olmasını erişim yetkisi denetiminin de tamamlandığı şeklinde yorumlamayın. Başlıklar, saklama ve yeniden kullanım kurallarını ileten araçlardır. Neyin saklandığını ve hangi denetimlerden geçerek mevcut ekrana ulaştığını açıklayabildiğinizde eski ekran sorununu daha doğru teşhis edebilirsiniz.