CDN Nedir ve Site Hızına Etkisi Nasıl Olur?

CDN nedir ve nasıl çalışır?

CDN (Content Delivery Network), içerikleri kullanıcıya coğrafi olarak yakın sunuculardan iletmek için tasarlanmış dağıtık bir altyapıdır. Tek bir merkezi sunucu yerine dünyanın farklı konumlarına yerleştirilmiş PoP (Point of Presence) noktaları aracılığıyla çalışır. Kullanıcı sayfayı açtığında istek, merkezi sunucuya değil, kullanıcıya en yakın edge sunucusuna yönlendirilir.

Bu yaklaşımın performans üzerindeki etkisi doğrudan fizik yasalarından gelir. Veri ışık hızına yakın bir hızda iletilse de mesafe arttıkça gecikme kaçınılmaz olarak artar. İstanbul'dan Frankfurt'taki bir sunucuya yapılan istek yaklaşık 30-40 ms sürerken, Singapur'dan aynı sunucuya ulaşmak 150-200 ms alabilir. CDN, bu mesafe sorununu içeriği edge'e taşıyarak çözer.

Bir kullanıcı CDN üzerinden korunan bir sayfayı ilk kez ziyaret ettiğinde edge sunucu içeriği origin'den (kaynak sunucu) çeker ve kendi önbelleğine alır. Sonraki ziyaretlerde aynı içerik doğrudan edge'den sunulur; origin'e hiç istek gitmez. Bu duruma "cache hit" denir. Cache hit oranı ne kadar yüksekse CDN o kadar etkili çalışıyor demektir. Düşük cache hit oranı, CDN'in varlığına rağmen kullanıcıların çoğu isteğin origin'e gittiği anlamına gelir.

Hangi içerikler CDN'e uygundur, hangileri değil?

CDN'in en verimli çalıştığı içerikler statik kaynaklardır: görseller, CSS dosyaları, JavaScript paketleri, fontlar ve video dosyaları. Bu içerikler kullanıcıdan kullanıcıya değişmez; dolayısıyla bir kez edge'e alındıktan sonra uzun süre önbellekte tutulabilir. Uzun TTL (Time to Live) değerleri bu tür içerikler için idealdir.

Dinamik içerikler ise daha dikkatli yaklaşım gerektirir. Kişiselleştirilmiş dashboard verileri, oturum bazlı içerikler ve gerçek zamanlı güncellenen bilgiler CDN'de önbelleğe alınmamalı ya da çok kısa TTL değerleriyle ayarlanmalıdır. Bu içeriklerin yanlışlıkla önbelleğe alınması bir kullanıcıya başka kullanıcının verisini gösterme gibi ciddi sorunlara yol açabilir.

HTML sayfaları ise ikisi arasında bir konumdadır. Tamamen statik bir site söz konusuysa HTML'nin CDN'de önbelleğe alınması hem TTFB'yi düşürür hem de origin sunucu yükünü azaltır. Dinamik içerik barındıran sayfalar için ise kısmi önbellekleme stratejileri (ESI - Edge Side Includes gibi) veya vary header kullanımı değerlendirilebilir.

• Uzun TTL (statik): Görseller, fontlar ve versiyonlanmış JS/CSS dosyaları için 1 yıla kadar TTL değeri kullanılabilir; dosya değiştiğinde URL değiştirilir (cache busting).
• Kısa TTL (yarı-dinamik): Ana sayfa HTML'si veya ürün listeleri için 5-60 dakikalık TTL değerleri dengeli bir yaklaşım sunar.
• TTL sıfır (dinamik): Kullanıcı bazlı içerikler, ödeme sayfaları ve API yanıtları CDN önbelleğinden muaf tutulmalıdır.
• Cache-Control başlıkları: Cache-Control: public, max-age=31536000, immutable gibi başlıklar CDN'e ve tarayıcıya doğru yönergeleri iletir.

Bölge ve segment bazlı ölçüm, CDN kararının temelidir

Aynı sayfa farklı coğrafyalarda ve farklı cihazlarda farklı sonuç üretir. Mobil tarafta düşük işlem gücü ve ağ dalgalanması masaüstünde görünmeyen gecikmeleri büyütür. Tek sayı üzerinden acele karar vermek yerine dağılıma bakın. Ortalama değil, 75. persentil önemlidir; kullanıcıların dörtte biri o noktanın altında kalıyor.

• Gerçek kullanıcı verisi: Chrome UX Report'tan 28 günlük dağılımı çekin. P75 değeri 2.5 saniyenin üzerindeyse LCP sorununuz var.
• Laboratuvar testi: Lighthouse'u throttled 4G + mid-tier mobile ayarında çalıştırın. Tekrarlanabilir sonuç için 5 kez ölçün, medyanı alın.
• Cihaz kırılımı: Düşük bellekli Android cihazlar (2GB RAM) toplam trafiğin %40'ını oluşturabilir. Bu segmentte ayrı ölçüm yapın.
• Zaman karşılaştırması: Haftalık trend grafiği tutun. Ani sıçrama deployment ile mi çakıştı, yoksa trafik artışı mı tetikledi?

Kullanıcı sayfa ile akıcı etkileşime girsin, içerik stabilitesini korusun, bekleme hissi azalsın. Bir metriği iyileştirirken başka alanda sorun üretmek kolaydır.

Gecikmenin hangi katmandan geldiğini ayırt etmek önemlidir

Dağıtım zincirinde sorun ararken TTFB analizi ile render blocking kaynak kontrolünü birlikte yürütmek gerçek darboğazı daha hızlı gösterir.

Ağır medya yükleme süresini uzatır. Bloklayan kaynak render'ı geciktirir. Ana iş parçacığı yükü etkileşimi dondurur. Sunucu gecikmesi TTFB'yi artırır. Hangi katman asıl sorunu üretiyor? Chrome DevTools Performance sekmesini açın, 6 saniye kayıt alın, flame graph'e bakın. Sarı bloklar JavaScript execution, mor bloklar rendering, yeşil bloklar painting.

Çoğu ekip ilk gördüğü soruna odaklanır. Görsel boyutları optimize edersiniz, 200ms kazanırsınız. Ama asıl sorun 3 saniyelik JavaScript parse süresi. Yanlış darboğaza müdahale etmişsiniz.

• Ağır medya: 1MB üzeri görseller LCP'yi doğrudan etkiler. WebP formatı %30 küçültme sağlar, AVIF %50. Ancak AVIF decode süresi düşük CPU'da daha uzun.
• Bloklayan kaynak: Head'deki senkron script'ler render'ı bloklar. Defer veya async ekleyin. Critical CSS'i inline yapın, geri kalanını async yükleyin.
• Ana iş parçacığı yükü: 50ms üzeri task'lar Long Task sayılır. Bunları böl: requestIdleCallback veya setTimeout ile chunk'lara ayır.
• Sunucu gecikmesi: TTFB 600ms üzerindeyse CDN edge cache'i kontrol edin. Cache HIT rate %80'in altındaysa kural setini gözden geçirin.

Waterfall chart'a bakın. Hangi kaynak zinciri en uzun? Hangi request 3. parti domain'e gidiyor ve 2 saniye bekliyor? Orada başlayın.

Her değişiklik sonrası tekrar ölçün. Bir optimizasyon başka metriği bozabilir. Görsel lazy load eklediniz, LCP iyileşti ama CLS arttı. Çünkü placeholder yüksekliği tanımlamadınız.

Etki, maliyet ve geri dönüş süresi üçgeninde öncelik belirleyin

Her optimizasyon eşit değildir. Etki büyüklüğü, uygulama maliyeti, risk seviyesi ve geri dönüş süresi dört ayrı faktördür; dengeli değerlendirilmesi gerekir.

Görsel sıkıştırma yüksek etki, düşük maliyet ve düşük risk sunar. Sunucu tarafı rendering'e geçiş yüksek etki ama aynı zamanda yüksek maliyet ve yüksek risk gerektirir; sprint planına alınmalıdır. Üçüncü parti script kaldırma orta etki, düşük maliyet ama iş birimi onayına göre değişen risk taşır.

Dört faktörü birlikte değerlendirin:

• Etki büyüklüğü: LCP'de 500ms+ kazanç yüksek etki. 100ms kazanç düşük etki. Lighthouse'ta simülasyon yapın, tahmini kazancı görün.
• Uygulama maliyeti: 1 günden az: düşük. 1-5 gün: orta. 1 hafta+: yüksek. Ekip kapasitesine göre ayarlayın.
• Risk seviyesi: Statik asset değişikliği düşük risk. API değişikliği orta risk. Rendering mimarisi değişikliği yüksek risk.
• Geri dönüş süresi: Feature flag ile anında geri alabiliyorsanız düşük risk. Deployment gerekiyorsa orta risk. Database migration varsa yüksek risk.

Önce düşük maliyet + yüksek etki işleri bitirin. Quick win'ler momentum yaratır, ekip motivasyonu artar. Sonra yüksek maliyet + yüksek etki işlere geçin.

Matris her sprint başında güncellensin. Yeni veri geldiğinde öncelikler değişebilir. Mobil trafikte ani artış olduysa mobil optimizasyonlar yukarı çıkar.

Yapılandırma değişikliklerini izole ve geri alınabilir tutun

Tüm görselleri bir anda WebP'ye çevirdiniz. LCP 800ms düştü. Harika. Ama Safari 14 kullanıcıları görselleri göremedi. Geri aldınız. Kazanç kayboldu, 2 gün harcandı.

Küçük adımlarla ilerleyin. Önce ana sayfa hero görseli. Sonra kategori sayfaları. Sonra ürün detay. Her adımda ölç, sorun yoksa devam et. Sorun varsa sadece o adımı geri al, diğerleri ayakta kalır.

• Aşamalı yayın: %5 trafiğe aç, 24 saat bekle. Metrikler stabil mi? %25'e çıkar. Sonra %50, sonra %100. Canary deployment kullan.
• Önce test sonra canlı: Staging ortamında Lighthouse CI kur. Her PR'da otomatik performans testi. Skor 10 puan düşerse PR merge edilmesin.
• Regresyon kontrolü: Deployment sonrası 1 saat içinde RUM verilerini kontrol et. LCP, FID, CLS'de %10+ artış varsa otomatik rollback tetikle.
• Geri alma planı: Feature flag kullan. Kod değişikliği yapmadan açıp kapatabilirsiniz. LaunchDarkly, Unleash gibi araçlar işi kolaylaştırır.

Her değişikliği dokümante edin. Ne yaptınız? Neden yaptınız? Sonuç ne oldu? 6 ay sonra başka biri aynı değişikliği tekrar denemek isteyebilir. Dokümantasyon varsa zaman kaybetmez.

Tek metriğe odaklanmak bölgesel farkları gizler

Rapor tarafında Lighthouse skorunu yorumlama ve sayfa yüklenme hızı etkisini okuma adımları, CDN kararlarını sadece tek metriğe bağlamayı önler.

Lab verisi gerçek kullanıcının ortamını yansıtmaz. Lighthouse kontrollü ortamda fast 3G, Moto G4 simülasyonuyla çalışır. Gerçek kullanıcılar 2G'de, eski cihazlarda farklı bir deneyim yaşıyor olabilir. CrUX verilerine bakın; P75 değeri Lighthouse'tan çok farklı çıkabilir.

Ortalama aldanıcıdır. Ortalama LCP 2.1 saniye. İyi görünüyor. Ama dağılıma bakın: %60 kullanıcı 1.5 saniyede yüklüyor, %40 kullanıcı 3.2 saniyede yüklüyor. İkinci grup mobil kullanıcılar. Onlar için optimizasyon yapmanız lazım, ortalama sizi yanıltıyor.

• Tek ölçüm yanılgısı: Sadece LCP'ye odaklandınız. 1.8 saniyeye düştü. Ama FID 300ms'ye çıktı. Kullanıcı tıklıyor, sayfa donuyor. Üç metriği birlikte izleyin: LCP, FID, CLS.
• Aşırı ortalama kullanımı: Median yerine P75 kullanın. Google Core Web Vitals P75'i baz alır. %75 kullanıcı eşiğin altında kalmalı.
• Coğrafya farkı: Avrupa'da TTFB 200ms, Asya'da 800ms. Sunucunuz Frankfurt'ta, Asya trafiği uzak. CDN edge location'ları Asya'ya ekleyin.
• Cihaz sınıfı etkisi: iPhone 13'te LCP 1.2 saniye, Samsung Galaxy A10'da 4.5 saniye. Düşük segment cihazlar için ayrı optimizasyon stratejisi gerekir.

Segmentasyon yapın. Mobil/desktop, coğrafya, cihaz sınıfı, bağlantı tipi. Her segment için ayrı hedef belirleyin. Hepsini aynı kefeye koymayın.

Cache kuralları ve TTFB profili düzenli izleme ister

Performans tek seferlik proje değil, sürekli disiplindir.

İlk sprintte LCP'yi 1.8 saniyeye düşürdünüz. 3 ay sonra 3.2 saniyeye çıkmış. Ne oldu? Yeni özellikler eklendi, kimse performans etkisini kontrol etmedi. Büyük görsel yüklendi, üçüncü parti script eklendi, CSS dosyası şişti.

Performans bütçesi belirleyin. JavaScript bundle 200KB'ı geçmesin. Ana sayfa LCP 2.5 saniyenin altında kalsın. Her deployment'ta bu eşikler kontrol edilsin. Eşik aşılırsa deployment başarısız olsun.

• Haftalık denetim: Her Pazartesi sabahı CrUX dashboard'a bakın. Hangi metrik kötüleşti? Hangi sayfa sorunlu? Geçen haftaki deployment'la ilişkisi var mı?
• Yayın öncesi kontrol: CI/CD pipeline'a Lighthouse CI ekleyin. Her PR'da performans skoru hesaplansın. 10 puan düşüşte otomatik yorum atsın: "Bu PR LCP'yi 400ms artırıyor."
• Otomatik alarm: Datadog, New Relic veya custom script ile RUM verilerini izleyin. P75 LCP 3 saniyeyi geçerse Slack'e alarm göndersin. 15 dakika içinde müdahale edin.
• Dokümantasyon disiplini: Her optimizasyonu Confluence veya Notion'a yazın. Ne yaptık? Neden yaptık? Sonuç ne oldu? Hangi metrik ne kadar değişti? Ekip bilgisi kaybolmasın.

Performans şampiyonu atayın. Bir kişi sorumlu olsun, her sprint performans gözden geçirmesi yapsın. Ekip toplantısında metrik trendlerini paylaşsın.

Küçük disiplinler büyük fark yaratır. Değişiklik öncesi/sonrası ölçüm koşullarını koruyun. Performans eşiklerini sürüm notlarına işleyin. Yeni geliştirmeler çizgiyi bozduğunda erken yakalayın.