Site hızı için CDN gerekli mi? Hosting + CDN entegrasyonu rehberi

CDN (Content Delivery Network) terimi sık geçiyor; ancak her site için “şartsız” değildir. CDN’nin asıl etkisi, içerik teslimini kullanıcıya coğrafi olarak daha yakın sunucular üzerinden yapması ve belirli türdeki istekleri cache (önbellek) etmesidir. Bu yazıda CDN’nin sizin senaryonuzda ne zaman belirgin fayda sağladığını, ne zaman sadece maliyet eklediğini; ayrıca hosting altyapısı ile CDN entegrasyonunu adım adım anlatacağım. Sonunda, hangi metriklere bakarak karar vereceğinizi net bir kontrol listesiyle çıkaracağız.

1) CDN tam olarak neyi hızlandırır? TTFB mi, yüklenme mi?

CDN’nin performansı nasıl etkilediğini doğru okumak gerekir. Site hızında çoğu kullanıcı “sayfa hız testi” sonucu görür; fakat kökte farklı zamanlar vardır:

• TTFB (Time to First Byte): Tarayıcı ilk byte’ı ilk ne zaman alır? Genelde origin (asıl sunucu) gecikmesi, routing, TLS/SSL ve uygulama/DB işlemleri belirler.
• İçerik indirme süresi: HTML/CSS/JS/görüntü/videolar gibi dosyaların transfer hızı ve istek başına gecikme (RTT) etkileri.
• İstek türü dağılımı: HTML dinamik mi? Görseller statik mi? API çağrıları cache’leniyor mu?

CDN tipik olarak en çok şunlarda etki üretir: - Görseller, CSS/JS, font dosyaları gibi statik varlıkların teslimi - İlk bayt sonrası “yükleme” aşaması - Kullanıcının bulunduğu bölgeye göre daha yakın POP üzerinden (CDN ağ noktası)

CDN şu durumlarda TTFB’yi otomatik olarak “mucize gibi” düşürmez: - HTML tamamen dinamik üretiliyorsa ve CDN bunu cache etmiyorsa - Origin tarafında uygulama/DB yavaşsa - API istekleri kişiye özel ve cache politikası yoksa

Bu nedenle CDN kararını tek bir hız testinde değil, zaman bileşenlerini ayırarak vermek gerekir.

Hız analizi için pratik yaklaşım

1. Tarayıcı DevTools veya bir hız test aracıyla istekleri türlerine göre inceleyin (HTML, API, görsel, JS/CSS).
2. Origin’e giden “en pahalı” istekleri belirleyin.
3. CDN cache edilebilen ve cache edilemeyen içerikleri ayırın.

2) CDN gerekli mi? 7 net karar kriteri

Aşağıdaki kriterlerden 4+ maddede “evet” diyorsanız CDN genellikle anlamlı fayda sağlar.

1. Kullanıcılar Türkiye dışına da yaygın: Türkiye’den gelen trafik tek ülkeyse etki sınırlı olabilir; çok ülke varsa daha belirgin olur.
2. İçerik statik oranı yüksek: Görsel/fotoğraf, CSS/JS, fontlar ana trafik kalemiyse CDN mantıklıdır.
3. Grafik/medya yoğunluğu yüksek: Online dergi, e-ticaret katalog görselleri, video/thumbnail ağırlığı.
4. Origin kaynaklar gecikmeye maruz kalıyor: Yüksek RTT yaşayan bölgelerde CDN otomatik rahatlatır.
5. Origin’e gelen istek sayısı fazla: Aynı görsellerin tekrar tekrar indirilmesi (cache yoksa) origin yükünü artırır.
6. Cache başlıkları ve sürümleme yönetimi yapılabilir: CDN’nin performansı, doğru cache-control ve dosya sürümleme ile artar.
7. DDoS ve bot trafiği yönetimi CDN tarafında yapılacak: Bazı CDN sağlayıcılar edge (uç) katmanında koruma sunar.

CDN genelde “sadece maliyet” olma riski taşıyan senaryolar

• Site neredeyse tamamen kişiye özel (her istekte farklı HTML) ve cache etmek pratik değilse
• İsteklerin büyük kısmı origin API/DB’ye gidiyor ve cache stratejisi yoksa
• Statik varlıklar zaten çok iyi cache ediliyor (hosting kontrol paneli / reverse proxy ile) ve trafik küçük ölçekliyse

3) Hosting performansı ile CDN’nin rol ayrımı

CDN’yi “alternatif” değil, “katman” olarak düşünün. İkisi birlikte şu şekilde çalışır:

• Hosting (VDS/VPS veya web hosting): Uygulama üretimi, veritabanı, server-side render, auth, log yönetimi, yedekleme.
• CDN (Edge katmanı): Statik dosyaları yakın noktadan servis eder, istek yoğunluğunu origin’den uzaklaştırır, bazı WAF ve rate-limit fonksiyonları sağlar.

Bu ayrımı netleştirince entegrasyon hedefi de netleşir: Origin yavaşsa CDN yine de yardım eder; ancak asıl performans kazancı origin’in yükünü azaltmaktan gelir. Origin hızlıysa CDN, teslimat süresini ve origin’e giden trafiği daha da iyileştirir.

Karşılaştırma: Origin optimizasyonu vs CDN

4) Hosting + CDN entegrasyonu: 10 adımda net süreç

Aşağıdaki adımlar “çoğu modern CDN sağlayıcısında” uygulanabilir genel bir akıştır. Sağlayıcıdan sağlayıcıya panel isimleri değişir; mantık aynı kalır.

4.1 DNS yönlendirmesini doğru kurun

• CDN sağlayıcısının verdiği CNAME veya NS kayıtlarını ekleyin.
• Eğer wildcard (ör. *.example.com) kullanacaksanız, alt alan adlarını kapsadığınızdan emin olun.

Doğru kontrol: DNS yayılımı sonrası istek başlıklarında via/server gibi CDN ipuçları görünmeye başlamalıdır.

4.2 Origin’i (asıl sunucu) belirleyin

• CDN ayarlarında origin domain veya origin IP tanımlanır.
• Origin web sunucunuzun (Nginx/Apache/LiteSpeed) erişilebilir olduğundan emin olun.

Net kontrol: Origin’de log tutuyorsanız CDN’den gelen isteklerin ayrı bir segmentte görünmesi gerekir.

4.3 HTTPS (TLS) planı: tek veya çift TLS

CDN’yi devreye aldığınızda genelde iki model görülür: - CDN edge → tarayıcı TLS (her zaman) - CDN edge → origin TLS (opsiyonel ama önerilir)

Eğer origin’de sertifika süresi, chain veya eski TLS konfigürasyonu sorunu varsa CDN tarafı “edge’i hızlı yapar” ama origin bağlantısı yeniden gecikme ekleyebilir.

4.4 Cache politikasını içerik türlerine göre ayırın

CDN’de “her şeyi cache’le” yaklaşımı yanlış sonuç üretir. Siteyi şu sınıflara ayırın: - Statik varlıklar: Görsel, CSS, JS, font → cache edilir. - Genel sayfalar (public): Blog sayfaları gibi → kısa/orta cache (ör. dakika/saat) uygulanabilir. - Kişiye özel sayfalar: Dashboard, profil → cache edilmez. - API yanıtları: Kişiye özel mi? Herkese aynı mı? → yalnızca uygun olanlar cache’lenir.

Net hedef: Yanlış cache, kullanıcıya başkasının verisini gösterme riski yaratır; bu yüzden cache anahtarı (cache key) ve “vary” ayarları dikkat ister.

4.5 Cache-control header’larını standartlaştırın

Origin tarafında şu prensip işe yarar: - Versiyonlanan dosyalara uzun cache (ör. max-age günler/haftalar) - Versiyonlanmayan dosyalara daha kısa cache

Uygulama tarafında dosyalarınızı isimle sürümleyin (ör. app.2026-07-19.js). Böylece CDN cache temizliği (purge) ihtiyacı azalır.

4.6 Range request ve görsel/medya ayarlarını doğrulayın

Video ve bazı görsel türlerinde parçalı indirme (range request) kritik olabilir. - CDN, Accept-Ranges/range request davranışını desteklemelidir. - Görsel optimizasyon araçları (WebP/AVIF) kullanıyorsanız CDN’in doğru Vary: Accept davranışını sağladığını test edin.

4.7 Origin tarafında cache değil, doğru kaynak performansını koruyun

CDN cache yapsa bile dinamik istekler ve cache miss (önbellekte olmayan içerik) mutlaka origin’e döner. - Uygulama sunucunuzun concurrency limitleri - Veritabanı bağlantı havuzu (connection pool) - Sık kullanılan sorguların index’leri

Bu noktalar TTFB üzerinde etki yaratır.

4.8 WAF/DDoS katmanını bilinçli açın

CDN bazı WAF kurallarıyla bot trafiğini filtreler. Ancak yanlış pozitifler olursa gerçek kullanıcılar etkilenir. - Başlangıçta “log-only” mod (varsa) - Trafik profili çıkarma - Kademeli kural genişletme

Net kontrol: 4xx artışı ve kullanıcı şikayetleri birlikte izlenmelidir.

4.9 Log ve metrikleri tek yerde toplayın

CDN panelinde “cache hit ratio”, “origin fetch rate”, “latency” gibi metrikler olur. - Cache hit oranı yükselmesi gerekir - Origin fetch rate düşmesi beklenir - Uzun süreli hatalar için farklı 4xx/5xx tipleri ayrıştırılmalıdır

4.10 Test planı: A/B değil, katman katman doğrulama

En güvenilir yöntem: 1. CDN olmadan bir baz ölçüm alın (TTFB ve istek dağılımı). 2. CDN devreye alındıktan sonra aynı rotaları test edin. 3. Sadece “overall score”a değil, HTML/API/asset isteklerine ayrı ayrı bakın.

5) Başarı metrikleri: CDN’yi “satın aldım” diye değil “ölçerek” doğrulayın

CDN entegrasyonu sonrası şu metriklerde net iyileşme bekleyin:

• Cache hit ratio: Özellikle görsel/CSS/JS için artmalı.
• Origin’e giden istek yüzdesi: Düşmeli.
• P95/P99 latency: CDN edge teslimatının etkisiyle düşebilir.
• TTFB: Her zaman dramatik düşmez; HTML cache’leniyorsa düşüş görülür, yoksa daha sınırlıdır.

Hangi senaryoda TTFB düşüşünü beklersiniz?

• HTML tamamen dinamik değilse ve “public” sayfalar cache edilebiliyorsa
• Edge cache (veya hosting cache) devredeyse
• Origin uygulaması zaten yavaş değilse (DB/işlem süresi makulse)

Hangi senaryoda TTFB düşmeyi beklememelisiniz?

• Kullanıcı bazlı kişiselleştirme (her istekte farklı HTML)
• API bağımlılıkları ve DB işlemleri dominantse

6) Maliyet/performans dengesi: CDN ne zaman “değer” üretir?

CDN ücretlendirmeleri genelde bant genişliği (GB) ve istek (request) üzerinden değişir. En doğru yaklaşım şudur: - Mevcut trafik profilini çıkarın: aylık asset trafiği, görsel ağırlığı - CDN’in cache edebileceği içerik oranını hesaplayın - CDN devreye girince origin fetch rate düşüşünü hedefleyin

Aşağıdaki “hızlı karar tablosu” pratik bir çerçeve sağlar:

Sonuç: CDN gerekli mi? Net aksiyon planı

CDN’yi “site hızı için her zaman gerekir” diye değil, içerik türü + kullanıcı dağılımı + cache edilebilirlik üzerinden değerlendirin. İlk aksiyon olarak hız testiyle HTML/API isteklerini, görsel/CSS/JS isteklerini ayırın; ayrıca mevcut cache-control davranışınızı netleştirin. Görsel/statik pay yüksek ve farklı bölgelerden trafik alıyorsanız CDN, yüklenme süresini ve origin üzerindeki istek baskısını anlamlı biçimde azaltır.

Hemen uygulamak için önerim: 1) Origin tarafında doğru cache header’larını standardize edin, 2) CDN’de statik varlıkları uzun cache’leyin, 3) dinamik/kullanıcıya özel sayfaları cache etmeyin, 4) cache hit ratio ve origin fetch rate metriklerini izleyerek kararınızı güncelleyin. Böylece CDN’yi gereksiz yere maliyetlendirmeden, ölçülebilir performans kazanımı elde edersiniz.