CDN'nin performansa katkısı, kurulum tamamlandığı an değil, belirli koşullar bir araya geldiğinde ortaya çıkar. Bu koşulların başında kullanıcıların coğrafi dağılımının edge noktalarıyla örtüşmesi, isteğin önbellekten karşılanması ve TLS el sıkışmasının origin yerine yakın bir edge'de tamamlanması gelir. Bu üç koşuldan biri eksikse CDN, trafiği origin'e ileten şeffaf bir proxy katmanından öteye geçemez.

CDN'yi bir hız düğmesi gibi düşünmek yaygın bir yanılgıdır. Gerçekte CDN, mevcut altyapının fiziksel sınırlarını dağıtarak azaltan bir çarpan mekanizmasıdır. Hızlandıracak bir şey olmadığında —önbelleklenemeyen içerik, tek coğrafi bölgede yoğunlaşan kullanıcı kitlesi, zaten düşük TTFB— CDN eklemenin somut bir izi oluşmaz.

CDN eklendi, TTFB değişmedi: asıl gösterge önbellekleme oranıdır

Bir CDN entegrasyonunun işe yarayıp yaramadığını değerlendirmek için bakılacak ilk metrik pop sayısı veya vaat edilen ağ kapasitesi değil, cache-hit oranıdır. CDN kontrol panellerinin büyük çoğunluğu bu oranı raporlar; HIT, MISS ve BYPASS etiketleriyle gelen yanıt başlıklarından da doğrudan okunabilir.

Cache-hit oranı düşükse —çoğu projede başlangıçta yüzde 30–50 aralığında olduğu görülür— TTFB iyileşmesi beklenmemelidir. Her MISS isteği CDN'yi atlayarak origin'e ulaşır; kullanıcı ile origin arasındaki fiziksel mesafe değişmemişse gecikme de değişmez. Yüksek cache-hit oranı ise genellikle yüzde 80'in üzerinde seyreder ve bu noktada TTFB farklılığı ölçüm araçlarında net biçimde görünür hale gelir.

Oranı düşük tutan başlıca nedenler şunlardır: kısa veya sıfır TTL değerleri, Cache-Control: private veya no-store direktifleri, cookie varlığına bağlı CDN bypass kuralları ve kimlik doğrulama gerektiren içerik. Cache-Control ve ETag mekanizmasını doğru yapılandırmadan CDN eklemek, sorunu çözmeden üstüne bir katman eklemekten ibarettir.

Edge konumu kazancın fiziksel zeminidir

Ağ gecikmesinin temel belirleyicisi ışık hızıdır. İstanbul'dan bir kullanıcı, ABD'deki bir origin sunucusuna bağlandığında fiziksel mesafe tek yön için yaklaşık 9.000 km'dir; bu mesafe teorik olarak 30 ms'nin altına inemeyecek bir gecikme tabanı oluşturur. Gerçek ağ koşullarında bu değer çoğunlukla 80–150 ms aralığına yerleşir. Bir CDN pop noktası İstanbul'da veya Frankfurttaysa, TLS el sıkışması ve ilk yanıt bu mesafeden değil, 10–20 ms ötesinden gelir.

Ancak bu kazanım yalnızca trafiğin coğrafi dağılımı ile CDN'nin pop haritasının örtüştüğü durumlarda gerçekleşir. Kullanıcıların büyük çoğunluğu zaten origin sunucusuna yakınsa —örneğin Türkiye'de bir sunucu ve neredeyse tüm trafiği Türkiye'den gelen bir site— fiziksel mesafe kazanımı sınırlı kalır. Bu durumda CDN'nin temel değeri gecikme azaltmak değil, trafik yükünü dağıtmak ve DDoS tampon katmanı sağlamak olur.

Pop yoğunluğu da CDN sağlayıcıları arasındaki en kritik farklardan biridir. Ücretli kurumsal CDN hizmetleri onlarca ülkede yüzlerce pop noktasına sahipken, ücretsiz katmanlarda bu sayı ciddi ölçüde azalır. Kullanıcı kitlesinin coğrafi dağılımını analitik araçlardan çekip CDN sağlayıcısının pop haritasıyla karşılaştırmak, sağlayıcı seçimi açısından en somut karar verme yöntemidir.

Önbelleklenemeyen içerik CDN'yi bypass eder

CSS, JavaScript, font ve görsel dosyaları gibi statik varlıklar CDN önbelleklemesinden en fazla yararlanan içerik türleridir. Bu dosyalar değişmez niteliktedir, uzun TTL değerleriyle servis edilebilir ve tüm kullanıcılara aynı içerik gönderilir. Doğru yapılandırıldığında bir JS bundle veya webp görseli, yüzlerce istek boyunca tek bir origin turu yapmadan edge'den karşılanır.

Dinamik içerik ise bambaşka bir tablo sunar. Kişiselleştirilmiş API yanıtları, oturum bazlı HTML, ödeme akışı sayfaları ve kullanıcı profiline bağlı içerik pratikte önbelleklenemez. Bu tür içerik her seferinde origin'e ulaşmak zorundadır. E-ticaret sitelerinde sayfa yapısının büyük bölümü kişiselleştirilmiş ürün önerileri, sepet durumu ve kullanıcı bilgilerinden oluşur; bu sayfalar için CDN'nin TTFB üzerindeki doğrudan katkısı çoğunlukla ihmal edilebilir düzeyde kalır.

Cookie bazlı farklılaştırma özellikle dikkat gerektiren bir durumdur. Çoğu CDN, gelen istekte belirli bir cookie varsa isteği önbellekten değil origin'den karşılar; bu davranış varsayılan olarak aktif olabilir. Giriş yapmış kullanıcılar için oturum cookie'si mevcut olduğundan, kimliği doğrulanmış tüm trafik CDN'yi bypass edebilir. Bu durumda tarayıcı önbelleklemesi ile CDN önbelleklemesini iyi organize etmek, cache stratejisinin temel eksenini oluşturur.

TLS sonlandırma ve protokol avantajı edge'de gerçekleşir

CDN'nin gecikme üzerindeki en az tartışılan katkılarından biri TLS sonlandırmasının edge'de yapılmasıdır. Bir kullanıcı siteye bağlandığında TLS el sıkışması, origin doğrudan kullanılıyorsa kullanıcı ile sunucu arasındaki tam mesafede tamamlanır. CDN aktifse bu el sıkışması yakın edge pop'unda gerçekleşir; origin ile edge arasındaki bağlantı ise önceden kurulmuş ve ısınmış bir kanalda yürütülür.

TLS 1.3 ile bu kazanım daha da belirginleşir. El sıkışma turu sayısı 1-RTT'ye indiğinden, edge'in kullanıcıya yakın olması ilk bağlantı maliyetini doğrudan etkiler. Tekrar eden ziyaretçiler için session resumption mekanizması bu turu sıfıra yaklaştırır; ancak bu mekanizmanın düzgün çalışması için edge pop'unun oturum bilgisini saklıyor olması gerekir. CDN sağlayıcılarının bir kısmı bu bilgiyi pop noktaları arasında paylaşmazken, diğerleri distributed session cache sunar.

HTTP/3 ve QUIC protokolü de CDN katmanından en verimli biçimde yararlanır. Kaynak sunucuda HTTP/3 desteği yapılandırmak karmaşık ve UDP port açıklığına bağlıyken, büyük CDN sağlayıcılarının büyük çoğunluğu HTTP/3'ü şeffaf biçimde sunar. Kullanıcı ile CDN arasındaki bağlantı QUIC üzerinden kurulurken CDN ile origin arasındaki bağlantı TCP'de kalabilir; son kullanıcı yine de protokol avantajından yararlanmış olur.

Statik ve dinamik trafik ayrı değerlendirilmeli

CDN yapılandırmasının en verimli yaklaşımı, statik varlıkları ve dinamik içeriği farklı önbellekleme kurallarıyla yönetmektir. Statik varlıklar için uzun TTL değerleri —genellikle bir yıl— ve immutable direktifi kullanılabilir; içerik değiştiğinde URL'deki hash değişir ve CDN otomatik olarak yeni dosyayı çeker. Bu strateji, origin'e düşen istek sayısını dramatik biçimde azaltır ve cache-hit oranını yüksek tutar.

Dinamik içerik için ise CDN'nin bypass edilmesi ya da çok kısa TTL değerleriyle sınırlı tutulması daha sağlıklıdır. Yanlış önbelleklenmiş kişiselleştirilmiş içerik —başka bir kullanıcının sepet bilgisini görmek gibi— hem teknik hem de güvenlik problemi üretir. Cache-Control: private direktifi tarayıcıya "bu içeriği sakla ama CDN'ye verme" talimatını verir; paylaşımlı önbelleğe alınması istenmeyen içerik için doğru araçtır.

Yüksek trafikli sayfalarda statik kabuk ile dinamik içeriği ayıran mimariler de giderek yaygınlaşmaktadır. Sayfa şablonu CDN'den gelirken içerik ayrı bir API çağrısıyla doldurulur; bu sayede şablonun cache-hit oranı yüksek tutulur, kişiselleştirilmiş veri ise her seferinde taze çekilir. LCP performansını iyileştirmenin bu mimaride en kritik adımı, hero görsel ve temel sayfa iskeletinin CDN önbelleğinden milisaniyeler içinde gelmesini sağlamaktır.

Gerçek kazanımı ölçmek: coğrafi test ve cache oranı izleme

CDN'nin etkisini doğrulamak için en güvenilir yöntem WebPageTest'in çoklu lokasyon özelliğiyle aynı sayfayı farklı coğrafi noktalardan test etmektir. ABD'deki bir test noktasından origin sunucusu Frankfurt'taysa ve CDN pop noktaları her iki bölgede mevcutsa, CDN aktifken ve CDN bypass edilmişken alınan TTFB farklarını doğrudan karşılaştırmak mümkündür. Fark anlamlıysa CDN çalışıyordur; fark ihmal edilebilir düzeydeyse büyük olasılıkla cache-hit oranı düşüktür.

CDN kontrol panellerindeki bandwidth saved ve origin shield request sayıları da güvenilir göstergelerdir. Tasarruf edilen bant genişliği oranı yüksekse origin yükü azalmıştır; bu hem performans hem de maliyet açısından anlamlı bir kazanımdır. Origin kalkan (origin shield) özelliği aktifse CDN pop noktaları kendi aralarında önbellek doğrulaması yapabilir; bu mekanizma origin'e düşen koşullu istek sayısını da azaltır.

Gerçek kullanıcı verisi —RUM— ise en güvenilir doğrulama kaynağıdır. CDN entegrasyonundan önce ve sonra toplanan TTFB dağılımı, özellikle origin'den uzak coğrafi bölgelerdeki kullanıcı segmentinde bir iyileşme varsa CDN'nin beklenen katkıyı sağladığını gösterir. Bu iyileşme yoksa yapılandırma gözden geçirilmelidir: TTL değerleri, bypass kuralları, cookie davranışı ve pop seçimi sırasıyla incelenecek başlıklardır.

CDN, performans sorunlarını çözen değil belirli darboğazları ortadan kaldıran bir altyapı katmanıdır. Statik varlıkların önbelleğe alınması, TLS maliyetinin edge'e taşınması ve coğrafi gecikmenin azaltılması —bu üç mekanizmanın tamamı doğru çalıştığında— ölçülebilir ve kalıcı bir iyileşme üretir. Bu mekanizmalardan biri bile devre dışıysa CDN kaynağa değil, karmaşıklığa katkıda bulunur.

Pek çok proje için gerçek soru "CDN kullanalım mı?" değil "CDN'den gerçekten yararlanıyor muyuz?" olmalıdır. Cache-hit oranını kontrol etmek, bypass kurallarını gözden geçirmek ve coğrafi test yapmak; bu üç adım, CDN yatırımının karşılığını verip vermediğini net biçimde ortaya koyar.