CDN ve Agresif Cache Ayarları

CDN (Content Delivery Network), web içeriğini coğrafi olarak dağıtılmış edge sunucularından kullanıcıya en yakın noktadan sunan dağıtık ağ altyapısıdır. 2026 verilerine göre CDN kullanan siteler, origin sunucuya kıyasla ortalama %60 daha düşük TTFB değerleri üretmekte ve agresif cache politikalarıyla tekrar ziyaretlerde sayfa yükleme süresini 200 ms altına çekmektedir. Bu altyapı katmanı, sunucu performansından bağımsız olarak her kullanıcıya tutarlı hız garantisi sunan teknik SEO'nun temel yapı taşıdır.

CDN Mimarisinin Temel Çalışma Prensibi

CDN, origin sunucudaki içeriğin kopyalarını dünya genelindeki Point of Presence (PoP) noktalarına dağıtır. Kullanıcı bir URL'ye istek gönderdiğinde, DNS çözümlemesi isteği en yakın PoP noktasına yönlendirir. Bu noktada içerik cache'te mevcutsa (cache hit), origin sunucuya hiç ulaşılmadan yanıt verilir. Cache'te yoksa (cache miss), edge sunucu origin'den içeriği çeker, kullanıcıya sunar ve gelecekteki istekler için cache'ler.

Bu mekanizma, coğrafi mesafenin yarattığı ağ gecikmesini ortadan kaldırır. İstanbul'daki bir kullanıcı, Almanya'daki origin sunucu yerine İstanbul PoP noktasından yanıt alır. Fiziksel mesafe 2000 km'den 20 km'ye düşer ve ağ gecikmesi 60-80 ms'den 5-10 ms'ye iner. Bu fark, doğrudan TTFB'ye yansır ve LCP zincirinin ilk halkasını güçlendirir.

Cache-Control Header'ının Anatomisi ve Direktifleri

HTTP Cache-Control header'ı, içeriğin nasıl ve ne kadar süre cache'leneceğini kontrol eden birincil mekanizmadır. Bu header, birden fazla direktifi virgülle ayırarak tek satırda barındırır. Her direktif, cache davranışının farklı bir boyutunu kontrol eder.

public direktifi, yanıtın CDN dahil tüm ara katmanlarda cache'lenebileceğini bildirir. private ise yalnızca son kullanıcının tarayıcısında cache'lenebileceğini ifade eder; CDN bu yanıtı cache'lemez. max-age saniye cinsinden cache süresini belirler. s-maxage yalnızca paylaşımlı cache'ler (CDN) için geçerli olan ayrı bir süre tanımlar. no-cache cache'lemeyi yasaklamaz; her kullanımda origin'den doğrulama ister. no-store ise yanıtın hiçbir yerde cache'lenmemesini kesin olarak emreder. immutable direktifi, cache süresi dolmadan içeriğin kesinlikle değişmeyeceğini bildirir ve tarayıcının revalidation isteği göndermesini engeller.

Kaynak Tipine Göre Cache Süresi Stratejisi

Her kaynak tipi farklı değişim sıklığına sahiptir ve cache süresi buna göre belirlenmelidir. Yanlış cache süresi, ya eski içerik sunulmasına ya da gereksiz origin isteklerine neden olur. Doğru strateji, kaynak tipinin doğasına göre şekillenir.

Statik varlıklar (JavaScript, CSS, görseller, fontlar) için agresif cache uygulanır. Bu dosyalar, build sürecinde dosya adına content hash eklenerek versiyonlanır (main.a1b2c3.js). İçerik değiştiğinde hash değişir ve yeni URL oluşur. Dolayısıyla eski URL'nin cache'i sorun yaratmaz:

    
Cache-Control: public, max-age=31536000, immutable      
    

HTML dosyaları için kısa süreli cache veya stale-while-revalidate stratejisi uygulanır:

    
Cache-Control: public, max-age=60, stale-while-revalidate=3600 
    

API yanıtları için ise içeriğin dinamiklik seviyesine göre 0 saniyeden 300 saniyeye kadar değişen süreler tanımlanır. Kullanıcıya özel yanıtlar (sepet bilgisi, profil verisi) hiçbir zaman CDN'de cache'lenmemelidir: Cache-Control: private, no-store.

stale-while-revalidate Stratejisinin SEO Avantajı

stale-while-revalidate (SWR) direktifi, cache süresi dolan içeriğin kullanıcıya eski (stale) versiyonla sunulurken arka planda origin'den güncel versiyonun çekilmesini sağlar. Bu strateji, TTFB'yi sıfıra yaklaştırır; çünkü kullanıcı her zaman cache'ten anında yanıt alır.

    
Cache-Control: public, max-age=300, stale-while-revalidate=86400
    

Bu yapılandırmada ilk 5 dakika (300 saniye) içerik doğrudan cache'ten sunulur. 5 dakika ile 24 saat (86400 saniye) arasında, eski içerik sunulurken arka planda güncelleme yapılır. 24 saat sonra cache tamamen geçersiz olur ve origin'den çekilir. Bot perspektifinden SWR, her tarama isteğinde hızlı yanıt alınmasını garanti eder. stale-while-revalidate, SEO açısından en dengeli cache stratejisidir çünkü hem hız hem de içerik tazeliği aynı anda sağlanır.

CDN Edge Cache ve Origin Shield Mimarisi

Edge cache, kullanıcıya en yakın PoP noktasındaki cache katmanıdır. Origin shield ise edge sunucular ile origin sunucu arasına yerleştirilen ikinci bir cache katmanıdır. Edge cache'te miss olan istekler doğrudan origin'e gitmek yerine origin shield'a yönlendirilir. Shield'da cache hit olursa, origin sunucu hiç yüklenmez.

Bu iki katmanlı yapı, özellikle viral içerik veya yüksek trafik anlarında origin sunucuyu korur. 50 farklı PoP noktasından aynı anda gelen cache miss istekleri, origin shield olmadan 50 ayrı origin isteği üretir. Shield ile bu 50 istek tek bir origin isteğine düşer. Cloudflare'de bu özellik "Tiered Cache", AWS CloudFront'ta "Origin Shield", Fastly'de "Shielding" olarak adlandırılır. Origin sunucu kaynaklı TTFB spike'larını önlemenin en etkili yöntemidir.

Cloudflare CDN Yapılandırması ve Cache Kuralları

Cloudflare, DNS tabanlı reverse proxy CDN'dir. Domain'in DNS kayıtları Cloudflare'e yönlendirildiğinde tüm trafik Cloudflare ağı üzerinden akar. Cache kuralları, dashboard'dan veya Page Rules ile yönetilir.

Cloudflare'de statik varlıklar için agresif cache yapılandırması:

    
# Cloudflare Page Rules
URL: example.com/assets/*
Cache Level: Cache Everything
Edge Cache TTL: 1 month
Browser Cache TTL: 1 year

URL: example.com/*.html
Cache Level: Cache Everything
Edge Cache TTL: 1 hour
    

Cloudflare'in "Cache Everything" kuralı, varsayılanda cache'lenmeyen HTML dosyalarını da edge cache'e alır. Edge Cache TTL CDN'deki süreyi, Browser Cache TTL ise tarayıcı cache'indeki süreyi belirler. HTML için edge cache süresini kısa (1 saat), browser cache süresini ise stale-while-revalidate ile yönetmek, güncel içerik ve hız dengesini sağlar.

Nginx Sunucusunda Cache Header Yapılandırması

CDN, origin sunucunun gönderdiği Cache-Control header'larını temel alarak cache kararı verir. Origin sunucuda doğru header'ların tanımlanması, CDN'in doğru çalışmasının ön koşuludur. Nginx'te kaynak tipine göre cache header yapılandırması:

    
server {
    # Statik varlıklar: agresif cache
    location ~* \.(js|css|png|jpg|jpeg|webp|avif|gif|svg|woff2|woff)$ {
        expires 1y;
        add_header Cache-Control "public, max-age=31536000, immutable";
        add_header Vary "Accept-Encoding";
    }

    # HTML dosyaları: kısa cache + SWR
    location ~* \.html$ {
        add_header Cache-Control "public, max-age=300, stale-while-revalidate=86400";
    }

    # API yanıtları: cache yok
    location /api/ {
        add_header Cache-Control "private, no-store, no-cache";
    }
}
    

Vary: Accept-Encoding header'ı, gzip/brotli sıkıştırılmış ve sıkıştırılmamış versiyonların ayrı cache'lenmesini sağlar. Bu header olmadan CDN, sıkıştırmayı desteklemeyen bir istemciye sıkıştırılmış yanıt gönderebilir.

Content Hash ve Cache Busting Mekanizması

Agresif cache (1 yıl) uygulandığında, dosya içeriği değiştiğinde eski cache'in geçersiz kılınması zorunludur. Content hash, dosya içeriğinden üretilen benzersiz bir imzayı dosya adına ekler: main.a1b2c3d4.js. İçerik değiştiğinde hash değişir, yeni dosya adı oluşur ve tarayıcı/CDN yeni dosyayı indirir.

Webpack'te content hash yapılandırması:

    
module.exports = {
  output: {
    filename: '[name].[contenthash:8].js',
    chunkFilename: '[name].[contenthash:8].chunk.js'
  }
};
    

Görseller için CMS'lerin çoğu otomatik hash üretmez. Bu durumda görselin URL'sine query string eklemek (image.jpg?v=2) veya görseli yeniden adlandırmak (image-v2.jpg) cache busting sağlar. Ancak query string bazlı cache busting, bazı CDN'lerde varsayılan olarak farklı cache key üretmez. Cloudflare'de "Query String Sort" ayarının aktif olduğundan emin olmak gerekir.

Brotli ve Gzip Sıkıştırma ile Transfer Boyutu Optimizasyonu

CDN'ler, yanıtları istemciye göndermeden önce sıkıştırarak transfer boyutunu küçültür. Gzip standart sıkıştırma algoritmasıdır. Brotli, Google tarafından geliştirilen ve gzip'e göre %15-25 daha iyi sıkıştırma oranı sağlayan modern algoritmadır. Tüm modern tarayıcılar Brotli'yi destekler.

Cloudflare, Brotli sıkıştırmayı varsayılan olarak destekler. Nginx'te Brotli etkinleştirmek için ngx_brotli modülü gerekir:

    
brotli on;
brotli_comp_level 6;
brotli_types text/html text/css application/javascript application/json image/svg+xml;
    

Sıkıştırma seviyesi (1-11) hız ve oran dengesidir. Seviye 6, çoğu senaryo için optimal dengeyi sağlar. Seviye 11 en yüksek sıkıştırma oranını verir ancak CPU maliyeti yüksektir; yalnızca statik dosyaların önceden sıkıştırılması (pre-compression) için uygundur. Pre-compressed dosyalar main.js.br olarak diske yazılır ve Nginx brotli_static on; direktifiyle doğrudan sunulur.

ETag ve Last-Modified ile Koşullu İstek Mekanizması

Cache süresi dolduğunda tarayıcı, kaynağın gerçekten değişip değişmediğini kontrol etmek için koşullu istek gönderir. ETag header'ı, içeriğin parmak izini (hash) sunar. Tarayıcı, If-None-Match header'ıyla bu hash'i sunucuya gönderir. İçerik değişmemişse sunucu 304 (Not Modified) döndürür ve tarayıcı cache'teki versiyonu kullanır. Transfer boyutu sıfıra iner.

Last-Modified header'ı aynı mekanizmayı tarih bazlı uygular. Tarayıcı If-Modified-Since ile sorgu yapar; dosya değişmemişse 304 döner. Bu mekanizmalar, agresif cache süreleri kullanmaya cesaret edemeyenler için güvenlik ağı oluşturur. Ancak koşullu istek bile bir HTTP round-trip gerektirir. immutable direktifi ile birlikte uzun max-age kullanmak, koşullu isteği tamamen ortadan kaldırır ve en agresif cache stratejisini uygular.

CDN Cache Purge ve Anlık İçerik Güncelleme

Agresif cache ayarlarının riski, içerik güncellendikten sonra eski versiyonun sunulmaya devam etmesidir. CDN cache purge, belirli URL'lerin veya tüm cache'in anında geçersiz kılınmasını sağlar. Cloudflare'de tek URL purge, prefix bazlı purge ve tam purge seçenekleri API üzerinden uygulanabilir:

    
# Tek URL purge
curl -X POST "https://api.cloudflare.com/client/v4/zones/ZONE_ID/purge_cache" \
  -H "Authorization: Bearer TOKEN" \
  -H "Content-Type: application/json" \
  --data '{"files":["https://example.com/updated-page.html"]}'
    

CMS'te içerik güncellendiğinde otomatik purge tetiklemek, agresif cache ile içerik tazeliği arasındaki çelişkiyi çözer. WordPress'te WP Cloudflare Super Page Cache veya WP Rocket eklentileri, yazı güncellendiğinde ilgili URL'lerin CDN cache'ini otomatik olarak temizler. Bu otomasyon, cache süresini uzun tutarken güncel içerik sunmayı garanti eder.

Bot Trafiği ve CDN Cache Etkileşimi

Googlebot, CDN edge cache'ten yanıt aldığında TTFB dramatik biçimde düşer ve tarama verimliliği artar. Bot, cache'ten sunulan sayfayı origin sunucudan sunulan sayfayla aynı şekilde değerlendirir; cache'ten sunulması indeksleme kalitesini etkilemez.

Ancak dikkat edilmesi gereken bir senaryo vardır: CDN'in bot trafiğine farklı cache kuralları uygulaması. Bazı CDN yapılandırmaları, bot trafiğini doğrudan origin'e yönlendirir. Bu durumda bot, CDN'in hız avantajından yararlanamaz. Sahadaki gerçek tecrübemiz gösteriyor ki, Googlebot'un CDN edge cache'ten sunulduğu sitelerde ortalama tarama hızı %40-60 artıyor ve tarama bütçesinin daha verimli kullanıldığı Search Console verilerinden teyit ediliyor.

Service Worker Cache ve CDN'in Tamamlayıcılığı

Service worker, tarayıcı katmanında çalışan bir cache mekanizmasıdır. CDN sunucu tarafında cache yaparken, service worker istemci tarafında cache yapar. Bu iki katmanın birlikte çalışması, çok katmanlı bir cache mimarisi oluşturur: tarayıcı cache > service worker cache > CDN edge cache > origin shield > origin sunucu.

Service worker'ın "cache-first" stratejisi, kaynağı önce istemci cache'inden sunar, bulamazsa ağa düşer:

    
self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request).then(cached => {
      return cached || fetch(event.request).then(response => {
        const clone = response.clone();
        caches.open('v1').then(cache => cache.put(event.request, clone));
        return response;
      });
    })
  );
});
    

Bu strateji, tekrar ziyaretlerde ağ isteği bile göndermeden içerik sunmayı sağlar. TTFB sıfır olur. Ancak service worker cache'inin güncellenmesi ayrı bir stratejik karar gerektirir. "stale-while-revalidate" stratejisi, service worker katmanında da uygulanarak hem anlık yanıt hem de arka planda güncelleme sağlanabilir.

HTTP/2 ve HTTP/3 Protokollerinin CDN Performansına Katkısı

CDN'ler, HTTP/2 ve HTTP/3 protokollerini edge sunucularda varsayılan olarak destekler. HTTP/2 multiplexing, tek bağlantı üzerinden paralel kaynak transferi sağlayarak sayfa yükleme süresini kısaltır. HTTP/3 ise QUIC protokolü üzerinden çalışarak bağlantı kurma süresini daha da azaltır ve paket kaybına karşı dayanıklılık sunar.

CDN kullanımının gizli avantajlarından biri, origin sunucu HTTP/2'yi desteklemese bile CDN edge'inin HTTP/2 veya HTTP/3 ile yanıt verebilmesidir. Cloudflare, origin'den HTTP/1.1 ile aldığı yanıtı kullanıcıya HTTP/3 üzerinden sunabilir. Bu protokol yükseltmesi, origin sunucu yapılandırmasına dokunmadan gerçekleşir ve özellikle eski altyapıya sahip sitelerde belirgin performans iyileştirmesi sağlar.

Image CDN ve Otomatik Görsel Optimizasyonu

Image CDN servisleri (Cloudflare Images, Cloudinary, imgix), görselleri istek anında otomatik olarak optimize eder. Tarayıcının Accept header'ına göre en uygun formatı seçer (AVIF > WebP > JPEG), URL parametresiyle görseli yeniden boyutlandırır ve kalite ayarını uygular.

Cloudflare Image Resizing yapılandırması:

    
# Nginx ile Cloudflare Image Resizing proxy
location /cdn-cgi/image/ {
    proxy_pass https://example.com;
}

# Kullanım
<img src="/cdn-cgi/image/width=800,format=auto,quality=80/images/hero.jpg"
     alt="Açıklama" width="800" height="450" loading="eager">
    

format=auto parametresi tarayıcı desteğine göre format seçer. Bu otomasyon, her görsel için manuel olarak WebP ve AVIF versiyonları oluşturma ihtiyacını ortadan kaldırır. LCP elemanı bir görsel olduğunda, Image CDN'in otomatik format seçimi ve boyutlandırması resource load time'ı doğrudan kısaltır.

Cache Katmanlarında Vary Header Yönetimi

Vary header'ı, CDN'e aynı URL için farklı koşullarda farklı cache versiyonları tutmasını emreder. Vary: Accept-Encoding en yaygın kullanımdır: gzip, brotli ve sıkıştırılmamış versiyonlar ayrı cache'lenir. Vary: Accept ise content negotiation (WebP vs JPEG gibi) için farklı versiyonlar tutar.

Ancak Vary header'ının aşırı kullanımı cache verimliliğini düşürür. Vary: User-Agent her farklı user-agent string'i için ayrı cache oluşturur ve cache hit oranını %5'in altına düşürebilir. Vary header'ında yalnızca gerçekten farklı içerik üreten başlıklar belirtilmelidir. Accept-Encoding ve gerekli durumlarda Accept yeterlidir. Mobil ve masaüstü için farklı içerik sunuluyorsa, Vary: User-Agent yerine CDN'in device detection özelliğiyle ayrı cache key oluşturmak daha verimlidir.

WordPress ve CMS Platformlarında CDN Entegrasyonu

WordPress'te CDN entegrasyonu, eklenti bazlı veya DNS bazlı olarak gerçekleştirilir. DNS bazlı CDN'ler (Cloudflare, Sucuri) tüm trafiği proxy ederek hem statik hem dinamik içerik için cache uygular. Origin pull CDN'ler (BunnyCDN, KeyCDN) ise yalnızca statik varlıkları CDN subdomain'inden sunar.

WP Rocket eklentisi, CDN entegrasyonunu ve cache header yönetimini birlikte sağlar. Eklenti ayarlarında CDN URL'si tanımlandığında, statik varlık referansları otomatik olarak CDN URL'sine dönüştürülür. Ayrıca HTML cache'i sunucu tarafında oluşturulur ve CDN'e statik dosya olarak sunulur. Bu kombinasyon, WordPress sitelerinde origin sunucu yükünü %90'a kadar azaltır.

E-ticaret Sitelerinde Dinamik İçerik ve Cache Stratejisi

E-ticaret sitelerinde fiyat, stok durumu ve sepet bilgisi dinamik verilerdir. Bu verileri cache'lemek, eski fiyat veya yanlış stok bilgisi gösterilmesine neden olabilir. Ancak ürün sayfasının tamamını cache'lememek, performanstan tamamen vazgeçmek anlamına gelir.

Edge Side Includes (ESI) veya client-side data fetching bu çelişkiyi çözer. ESI, sayfa içindeki dinamik blokları ayrı fragment'lar olarak tanımlar. CDN, statik kısımları cache'ten sunarken dinamik fragment'ları origin'den çeker:

    
<!-- ESI ile dinamik fiyat bloğu -->
<esi:include src="/api/product/123/price" />
    

Alternatif olarak, sayfanın statik HTML'i CDN'den sunulurken fiyat ve stok bilgisi client-side JavaScript ile API'den çekilir. Bu yaklaşımda sayfa anında yüklenir (cache'ten), dinamik veriler JavaScript ile 100-200 ms içinde güncellenir. LinkedIn üzerindeki e-ticaret mühendisliği topluluklarında tartışılan A/B test sonuçları gösteriyor ki, bu hibrit yaklaşım sayfa yükleme süresini ortalama %45 kısaltırken dönüşüm oranlarında istatistiksel olarak anlamlı bir düşüş üretmiyor.

Cache Hit Oranı İzleme ve Optimizasyon Döngüsü

Cache hit oranı, CDN'in etkinliğini ölçen temel metriktir. Bu oran, CDN'den sunulan (cache hit) isteklerin toplam isteklere oranını ifade eder. %90 üzeri cache hit oranı sağlıklı bir CDN yapılandırmasını gösterir. %70 altı ise cache kurallarının veya TTL değerlerinin optimize edilmesi gerektiğine işaret eder.

Cloudflare Analytics, cache hit oranını gerçek zamanlı olarak gösterir. Cache hit oranını artırmak için şu adımlar uygulanmalıdır: HTML cache'lemeyi aktifleştirin (varsayılanda kapalıdır), query string varyasyonlarını normalize edin, Vary header'ını minimize edin ve TTL değerlerini artırın. Her adımın etkisini izleyerek iteratif optimizasyon yapın.

CDN ve Cache Yapılandırmasının Teknik Kontrol Listesi

Kapsamlı bir CDN ve cache denetiminde uygulanması gereken kontrol noktaları şunlardır:

• Statik varlıklara 1 yıl cache süresi ve immutable direktifi uygulayın: Content hash ile versiyonlanan dosyalarda cache busting otomatik çalışır ve maksimum cache süresi güvenle uygulanabilir.
• HTML yanıtlarına stale-while-revalidate stratejisi uygulayın: Anlık yanıt ve içerik tazeliğini birlikte sağlayan bu strateji, bot ve kullanıcı deneyimini eş zamanlı iyileştirir.
• Brotli sıkıştırmayı etkinleştirin: Gzip'e göre %15-25 daha küçük transfer boyutu sağlayarak resource load time'ı kısaltın.
• Origin shield katmanını aktifleştirin: Çoklu edge miss'lerin origin sunucuyu yormesini önleyerek TTFB stabilitesini koruyun.
• Cache purge otomasyonunu kurun: CMS'te içerik güncellendiğinde ilgili URL'lerin CDN cache'ini otomatik temizleyerek eski içerik riskini ortadan kaldırın.
• Cache hit oranını %90 üzerinde tutun: Analytics verilerini izleyerek düşük hit oranının kaynaklarını tespit edip cache kurallarını optimize edin.

CDN Performansının Core Web Vitals Üzerindeki Bütünsel Etkisi

Çoğu uzman aksini iddia etse de, CDN ve agresif cache yapılandırması yalnızca TTFB'yi değil, Core Web Vitals'ın üç metriğini birden etkiler. LCP açısından, düşük TTFB ve hızlı kaynak teslimi LCP zincirinin ilk iki bileşenini doğrudan iyileştirir. CLS açısından, hızlı CSS ve font teslimi layout kurallarının erken uygulanmasını sağlayarak geç yükleme kaynaklı shift'leri önler. INP açısından ise daha küçük transfer boyutları (Brotli sıkıştırma) JavaScript parse süresini kısaltarak ana thread'in daha erken serbest kalmasını sağlar.

Teoride doğru görünen ama pratikte patlayan nokta şudur: CDN'i aktifleştirmek tek başına performansı garanti etmez. Yanlış cache kuralları, eksik purge otomasyonu veya düşük cache hit oranı, CDN'in potansiyelini boşa harcar. CDN, doğru yapılandırıldığında performansın temel taşıdır; yanlış yapılandırıldığında ise yalnızca ek bir ağ katmanı ve gereksiz karmaşıklık üretir. Yapılandırmayı periyodik olarak denetlemek, cache hit oranını izlemek ve kaynak tipine göre TTL değerlerini optimize etmek, CDN yatırımının getirisini maksimize eden sürdürülebilir yaklaşımdır.