Bir siteyi ilk kez açtığında sayfa iki saniyede geliyor. Sekmeyi kapatıp beş dakika sonra aynı sayfaya döndüğünde neredeyse anında açılıyor. Sitede hiçbir şey değişmedi, bağlantın da aynı. Değişen tek şey, ikinci ziyarette tarayıcının o dosyaların çoğunu yeniden istemek zorunda kalmamasıdır.
Bu farkı üreten iki ayrı mekanizma var ve pratikte sürekli birbirine karıştırılıyor. CDN mesafeyi kısaltır: isteği hâlâ bir sunucuya gönderirsin, sadece daha yakın bir sunucuya. Önbellek isteği tamamen ortadan kaldırır: dosya zaten cihazda veya uç sunucuda durduğu için ağa hiç çıkılmaz. İkinci ziyaretin hızlı olmasının sebebi büyük ölçüde ikincisidir. Birincisi ise ilk ziyareti kurtarır.
Bu ayrım, "agresif cache" tartışmasının da temelidir. Agresif ayarlar bir dosyanın ne kadar süre yeniden istenmeden kullanılacağını uzatır. Kazancı gerçek, bedeli ise çoğu rehberde geçiştirilir: uzun süre verdiğin bir dosyayı geri çağırma imkânın her katmanda aynı değildir.
CDN mesafeyi nasıl kısaltır
CDN (Content Delivery Network), sitenin dosyalarının kopyalarını farklı coğrafyalardaki uç sunucularda tutan dağıtık bir ağdır. Kullanıcı siteye istek gönderdiğinde istek doğrudan asıl sunucuya (origin) değil, ağın kullanıcıya en yakın uç noktasına düşer. İstenen yanıt o uç sunucunun önbelleğinde varsa (cache hit) yanıt oradan döner ve asıl sunucuya hiç dokunulmaz. Yoksa (cache miss) uç sunucu içeriği origin'den bir kez çeker, kullanıcıya iletir ve sonraki istekler için saklar.
Mesafenin bedelinin tek seferlik olmaması, CDN'in neden bu kadar işe yaradığını açıklar. Yeni bir HTTPS bağlantısında DNS çözümlemesi, TCP el sıkışması ve TLS el sıkışması, ilk HTML baytı gelmeden önce tarayıcı ile sunucu arasında birkaç gidiş dönüş gerektirir. Işık fiber içinde saniyede kabaca 200 bin kilometre yol aldığı için her 1.000 kilometrelik mesafe, tek bir gidiş dönüşe yaklaşık 10 milisaniye ekler. Tek başına küçük görünen bu sayı üç dört gidiş dönüşle çarpılır. Uç sunucu, ödenen mesafeyi değil o mesafenin çarpanını küçültür.
CDN'in yapamadığı şey de aynı ölçüde belirleyicidir: CDN asıl sunucunu hızlandırmaz. Sayfanın HTML'ini üretmek veritabanı sorguları yüzünden 800 milisaniye sürüyorsa ve HTML önbelleğe alınmıyorsa, CDN bu 800 milisaniyeyi ortadan kaldırmaz, üstelik araya bir durak daha ekler. CDN'in hız katkısı isteğin origin'e hiç ulaşmadığı durumlarda doğar. Yani CDN'in değeri, önbellek kurallarını ne kadar doğru yazdığına bağlıdır. Cloudflare, Fastly ve Akamai gibi sağlayıcılar aynı temel mimariyi kurar; aralarındaki fark ağın genişliği ve önbellek kurallarının nasıl tanımlandığı düzeyindedir.
Üç önbellek katmanı ve hangisini kimin temizleyebildiği
Bir yanıt kullanıcıya ulaşana kadar birbirinden bağımsız üç yerde saklanabilir. Bu katmanlar aynı başlıkları okur ama sana karşı sorumlulukları aynı değildir.
| Katman | Nerede durur | Kimin için geçerli | Sen temizleyebilir misin |
|---|---|---|---|
| Tarayıcı önbelleği | Kullanıcının cihazında | Yalnızca o kullanıcı | Hayır |
| CDN önbelleği | Uç sunucularda | Tüm ziyaretçiler | Evet, saniyeler içinde |
| Sunucu önbelleği | Kendi sunucunda | Tüm ziyaretçiler | Evet |
Tablodaki son sütun, bu yazının geri kalanındaki her kararın dayanağıdır. CDN önbelleğine yanlış bir içerik yazdıysan bir purge isteğiyle birkaç saniye içinde geri alırsın. Sunucu önbelleği zaten senin makinendedir. Ancak bir kullanıcının tarayıcısına "bu dosyayı bir yıl boyunca yeniden isteme" dedikten sonra o kararı geri alacak bir mekanizman yoktur. Kullanıcı önbelleğini kendisi temizlemedikçe veya süre dolmadıkça o dosya orada kalır.
Sunucu önbelleği ise diğer ikisinden farklı bir işi çözer. HTML'i üretme maliyetini düşürür: veritabanına gitmek yerine hazır çıktıyı sunar. CDN'i olan bir site sunucu önbelleğine ihtiyaç duymayabilir gibi görünse de, uç sunucuda önbelleklenemeyen her istek (kişiye özel sayfalar, önbellek süresi dolan sayfalar, yeni uç noktalar) yine origin'e düşer. İki katman birbirinin yerine geçmez.
Cache-Control başlıkları gerçekte ne söyler
Bir yanıtın ne kadar süre saklanacağını asıl sunucu belirler ve bunu Cache-Control başlığıyla söyler. Aynı başlığı hem tarayıcı hem CDN okur. Kullanılan direktifler az sayıdadır.
| Direktif | Sade karşılığı |
|---|---|
| max-age=N | Bu yanıt üretildikten N saniye sonrasına kadar taze sayılır ve yeniden sorulmadan kullanılabilir. |
| s-maxage=N | Yalnızca paylaşımlı önbellekler (CDN) için süre. Varsa CDN tarafında max-age değerinin yerine geçer, tarayıcı bunu yok sayar. |
| public | Paylaşımlı önbellekte saklanabilir. |
| private | Yalnızca kullanıcının kendi tarayıcısında saklanabilir, CDN saklamaz. |
| no-cache | Saklanabilir, ancak her kullanımdan önce sunucuya sorulup hâlâ geçerli mi diye doğrulanmalıdır. |
| no-store | Hiçbir önbellek bu yanıtı saklamasın. |
| immutable | Taze olduğu sürece bu dosya değişmeyecek, sayfa yenilense bile doğrulama isteği gönderme. |
| stale-while-revalidate=N | Süresi dolduktan sonraki N saniye boyunca eski kopya sunulabilir; güncelleme arka planda yapılır. |
Bu listede en çok yanlış okunan direktif no-cache. Adına rağmen "önbellekleme" demez. Yanıtın saklanmasına izin verir, sadece her kullanımdan önce doğrulanmasını şart koşar. Doğrulama sırasında tarayıcı elindeki ETag değerini If-None-Match başlığıyla gönderir; içerik değişmemişse sunucu gövde göndermeden 304 Not Modified döner. Yani no-cache ile dosya yeniden indirilmez, sadece bir gidiş dönüş harcanır. Gerçekten "hiç saklanmasın" demek istiyorsan kullanman gereken direktif no-store.
İkinci yaygın yanılgı max-age sayacının ne zaman başladığıyla ilgili. Sayaç, yanıtın sana ulaştığı an değil, origin'de üretildiği an başlar. Bir yanıt CDN'de 100 saniye beklediyse bunu Age başlığıyla bildirir ve tarayıcının elindeki tazelik süresinden o 100 saniye düşülür. Uzun s-maxage değerleriyle çalışan bir yapıda tarayıcıya ulaşan dosya, hesapladığından çok daha kısa ömürlü olabilir.
Üçüncüsü ise sessizce en çok zarar vereni: Cache-Control göndermemek "önbellekleme yok" anlamına gelmez. HTTP mümkün olduğunca önbelleklemek üzere tasarlandığı için, başlık yoksa istemciler sezgisel önbellekleme uygular ve yanıtı Last-Modified tarihine bakarak kendi kararlarıyla saklar. Bu durumda dosyanın ne kadar saklanacağını sen değil istemci belirler. Bu yüzden her yanıta açık bir Cache-Control vermek, agresif ayarlardan önce gelen temel adımdır.
Agresif önbellek tam olarak neyi riske atar
"Agresif" kelimesi bu konuda kendi başına bir erdem gibi kullanılıyor ve bu yanıltıcı. Agresif olmak, bir dosyaya gerçekte hak ettiğinden uzun bir yaşam süresi vermek demektir. Kazanç ölçülebilir, risk ise dört başlıkta toplanır.
Birincisi bayat içerik. Uzun süre verilmiş bir sayfa güncellendiğinde kullanıcı hâlâ eski hâlini görür. E-ticarette bunun karşılığı somuttur: indirim bittiği hâlde eski fiyatı gören ya da tükenen ürünü stokta sanan kullanıcı. Fiyat ve stok gibi alanların sayfanın önbelleklenen gövdesi içinde donması, teknik bir ayar hatası olmaktan çıkıp doğrudan ticari bir soruna dönüşür.
İkincisi geri alınamazlık. CDN'de yaptığın hatayı purge ile düzeltirsin; tarayıcıda yaptığın hatayı düzeltemezsin. Adı sabit bir dosyaya bir yıllık süre verip ertesi hafta içeriğini değiştirdiysen, o dosyayı zaten indirmiş kullanıcılar için yapabileceğin hiçbir şey yoktur. Purge isteği CDN'i temizler, kullanıcının diskindeki kopyaya dokunmaz.
Üçüncüsü sürüm uyumsuzluğu. Bir yayın sonrası kullanıcının elinde yeni HTML ile eski JavaScript veya eski CSS birleşebilir. Sayfa açılır ama düzen bozuk gelir, bir buton çalışmaz, bir bileşen hiç görünmez. Bu hatanın kötü tarafı, geliştiricinin ekranında görünmemesidir: sen sert yenileme yaparak önbelleği atlarsın, kullanıcı atlamaz.
Dördüncüsü ve en ağırı, kişiye özel bir yanıtın paylaşımlı önbelleğe yazılmasıdır. Sepet, hesap veya sipariş sayfası public olarak işaretlenirse CDN o yanıtı saklar ve aynı adrese gelen başka bir kullanıcıya sunabilir. Bu, hız kaybı değil veri sızıntısıdır. Kişiye özel her yanıtın private veya no-store taşıması pazarlık konusu değildir.
Bu dört başlığın ortak paydası şudur: önbellek kurmak kolaydır, geçersiz kılmak zordur. Agresif ayarların güvenli olduğu tek durum, geçersiz kılma probleminin en baştan ortadan kalktığı durumdur. Bir sonraki bölüm tam olarak bunu anlatıyor.
HTML'i önbelleklemek ile statik varlıkları önbelleklemek neden aynı iş değil
Modern derleme araçları JavaScript ve CSS dosyalarının adına içerikten üretilen bir imza ekler: app.9f2c1b.js gibi. İçerik değiştiği anda imza değişir, dosyanın adresi değişir ve tarayıcı bunu daha önce görmediği yeni bir dosya olarak indirir. Burada eski dosyayı geçersiz kılmaya gerek yoktur, çünkü kimse eski adresi bir daha istemez. Adres ile içerik bire bir eşleştiği için bu dosyalara bir yıllık süre vermek ve immutable eklemek güvenlidir.
Cache-Control: public, max-age=31536000, immutableHTML'de böyle bir imkân yoktur. Bir yazının adresi kalıcıdır: kullanıcı onu kaydeder, başka siteler ona link verir, Google onu o adresle indeksler. Adresi içerik değiştiği için değiştiremezsin. Yani HTML, adresi sabit kalırken içeriği değişen tek kaynak tipidir ve geçersiz kılma probleminden kaçamaz. Bu yüzden statik dosyalarda doğru olan uzun süre, aynı sitenin HTML'inde tuzağa dönüşür.
Çözüm, tek bir süre seçmek yerine iki katmana iki farklı süre vermektir. Temizleyebildiğin katmanı agresif tut, temizleyemediğini kısa tut. s-maxage tam olarak bunu mümkün kılar: CDN tarafındaki süreyi ayrı belirler ve tarayıcı onu yok sayar.
Cache-Control: public, max-age=0, s-maxage=600, stale-while-revalidate=86400Bu satırda tarayıcı yanıtı hemen bayatlamış sayar ve bir sonraki ziyarette doğrulama isteği gönderir; içerik değişmemişse 304 alıp indirmeden kullanır. CDN ise aynı yanıtı on dakika boyunca doğrudan sunar, süre dolduktan sonraki bir gün boyunca da eski kopyayı sunmaya devam ederken güncellemeyi arka planda yapar. Yazıyı güncellediğinde CDN önbelleğini temizlersin ve on dakika beklemek zorunda kalmazsın. Kullanıcının tarafında ise geri alamayacağın bir taahhüt hiç verilmemiş olur.
Kaynak tipine göre başlangıç ayarları
Aşağıdaki değerler evrensel doğrular değil, makul başlangıç noktalarıdır. Doğru sayı yayın sıklığına ve otomatik temizleme kurup kuramadığına göre değişir.
| Kaynak tipi | Cache-Control | Gerekçe |
|---|---|---|
| Adında içerik imzası olan JS ve CSS | public, max-age=31536000, immutable | İçerik değişince adres değişir, geçersiz kılma gerekmez. |
| Adı sabit görsel ve font | public, max-age=604800 | Bir hafta, geri alamayacağın bir taahhüt için makul üst sınır. |
| Herkese aynı gelen HTML | public, max-age=0, s-maxage=600, stale-while-revalidate=86400 | Agresif olan katman temizlenebilen katmandır. |
| Kişiye özel sayfa (sepet, hesap) | private, no-store | Paylaşımlı önbelleğe düşmesi veri sızıntısıdır. |
| Herkese aynı gelen API yanıtı | public, max-age=0, s-maxage=60 | Kısa uç sunucu süresi, yoğun anlarda origin yükünü ciddi biçimde düşürür. |
Bir dosyaya süre verirken sorulacak ilk soru "kaç saniye" değildir. İlk soru şudur: içerik değiştiğinde bu dosyanın adresi de değişiyor mu? Cevap evetse istediğin kadar agresif olabilirsin. Hayırsa, verdiğin süre boyunca o içeriği değiştirme hakkından vazgeçiyorsun demektir. Adı sabit görseller için pratik çıkış yolu, dosyayı güncellemek yerine yeni adla yüklemek ve referansları değiştirmektir.
TTFB ve LCP üzerindeki gerçek etkisi
Önbellek ayarlarının Core Web Vitals'a katkısı en net TTFB üzerinde görülür. Uç sunucudan önbellekten dönen bir HTML yanıtında sunucu işleme süresi tamamen ortadan kalkar ve geriye yalnızca ağ mesafesi kalır. TTFB, LCP'nin ilk bileşeni olduğu için bu kazanç doğrudan LCP'ye taşınır: LCP süresinin 2,5 saniye altına çekilmesi hedefinde çoğu sitede en büyük tek kalem sunucu yanıt süresidir.
Buradan sonrası abartılmamalı. CDN, LCP'yi geciktiren sebep sunucu değilse fazla bir şey değiştirmez. LCP görselinin geç keşfedilmesi, render'ı bloklayan stil dosyaları veya ana iş parçacığını meşgul eden bir betik varsa yanıtın 40 milisaniyede gelmesi sonucu kurtarmaz. Bu durumda sıradaki iş kritik CSS'in satır içi yüklenmesi gibi render zinciri düzeltmeleridir. Protokol katmanındaki kazanç da benzer biçimde bağımsızdır: uç sunucular genelde HTTP/3 ve QUIC desteğini asıl sunucudan bağımsız olarak sağlar ve bağlantı kurma maliyetini ayrıca düşürür.
Ölçüm tarafında akılda tutulması gereken bir gecikme var. Core Web Vitals değerlendirmesi laboratuvar testine değil, gerçek kullanıcılardan toplanan ve 28 günlük kayan bir pencerede biriken saha verisine dayanır. Önbellek ayarını bugün düzelttiğinde test aracındaki tekil ölçüm anında iyileşir, saha verisindeki 75. yüzdelik değer ise haftalar içinde yerine oturur. Ayarı değiştirip ertesi gün rapora bakmak yanıltıcı sonuç verir.
Ayarın çalıştığını nasıl doğrularsın
Yapılandırmanın gerçekten uygulandığını görmenin en hızlı yolu yanıt başlıklarına bakmaktır. Tarayıcının geliştirici araçlarında ağ sekmesinden bir isteğin yanıt başlıkları açıldığında üç şey aranır.
- Cache-Control satırı beklediğin değeri taşıyor mu? Sunucu yapılandırmasındaki kural ile canlıdaki yanıt çoğu zaman araya giren bir katman yüzünden ayrışır.
- Age başlığı var mı ve sıfırdan büyük mü? Age, yanıtın paylaşımlı bir önbellekte ne kadar beklediğini söyler; varlığı isteğin origin'e gitmediğinin doğrudan kanıtıdır.
- İkinci ziyarette istek 200 yerine 304 dönüyor mu ya da boyut sütununda diskten okunduğu görünüyor mu? İkisi de yanıtın yeniden indirilmediği anlamına gelir.
Bu testi yaparken sık yapılan hata sert yenileme kullanmaktır. Sert yenileme önbelleği bilerek atlar, dolayısıyla her seferinde taze indirme görürsün ve ayarın çalışmadığı sonucuna varırsın. Doğru test, sayfayı normal gezinmeyle yeniden açmaktır.
Sık sorulanlar
CDN kullanınca Googlebot farklı bir içerik mi görür?
Hayır. Uç sunucudan sunulan yanıt, origin'den sunulacak yanıtın kopyasıdır ve tarama açısından aralarında fark yoktur. Dikkat edilmesi gereken nokta içerik değil yapılandırmadır: bot trafiğini önbellekten muaf tutan veya farklı davranan bir kural yazıldıysa bot, CDN'in hız avantajından yararlanamaz. Ayrıca uç sunucunun bot isteklerine güvenlik katmanında engel çıkarmadığından emin olmak gerekir.
Kullanıcının tarayıcı önbelleğini uzaktan temizleyebilir miyim?
Hayır. Verilen süre dolana kadar o kopya kullanıcının cihazında kalır. Yapılabilecek tek şey dosyanın adresini değiştirmek ve HTML'i güncelleyerek kullanıcıyı yeni adrese yönlendirmektir. Bu da HTML'e neden uzun süre verilmediğini açıklar: HTML kısa ömürlü olduğu için yeni adresleri taşıyabilen tek katmandır.
Sunucu tarafında önbellek varken CDN'e gerek var mı?
İkisi farklı yarıyı çözer. Sunucu önbelleği sayfayı üretme maliyetini ortadan kaldırır ama kullanıcı ile sunucu arasındaki mesafeyi kısaltmaz. CDN mesafeyi kısaltır ama önbelleklenemeyen istekleri yine origin'e gönderir. Tek başına sunucu önbelleği olan uzak bir sitede yanıt hızlı üretilir ve yavaş ulaşır; tek başına CDN'i olan yavaş bir sitede yanıt hızlı ulaşır ama üretilmesi beklenir.
