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

CDN için başlangıç ölçümünü netleştirin

Ölçüm disiplini CDN çalışmalarında temeldir.

Aynı sayfa farklı cihazlarda farklı sonuç üretir. Mobil tarafta düşük işlem gücü var, ağ dalgalanması masaüstünde görünmeyen gecikmeleri büyütüyor. Tek sayı üzerinden acele karar vermek yerine dağılıma bakın. Ortalama değil, 75. persentil önemli. Çünkü 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?

Hedef sadece raporda iyi görünen skor değil. Kullanıcı sayfa ile akıcı etkileşime girsin, içerik stabilite korusun, bekleme hissi azalsın. Bir metriği iyileştirirken başka alanda sorun üretmek kolay.

CDN darboğazını katman katman ayırın

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.

Performans sorunları katmanlıdır.

Ağır medya yükleme süresini uzatır. Bloklayan kaynak render'ı geciktirir. Ana iş parçacığı yükü etkileşimi donduruyor. 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.

CDN tarafında öncelik sırası kurun

Her optimizasyon eşit değildir. Etki büyüklüğü, uygulama maliyeti, risk seviyesi, geri dönüş süresi — dört faktörü dengeleyin.

Görsel sıkıştırma: yüksek etki, düşük maliyet, düşük risk. Hemen yapın. Sunucu tarafı rendering'e geçiş: yüksek etki, yüksek maliyet, yüksek risk. Sprint planına alın, 3 hafta ayırın. Üçüncü parti script kaldırma: orta etki, düşük maliyet, orta risk (iş birimi onayı gerekebilir).

Matris kurun:

• 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.

CDN değişikliklerini küçük yayınlarla doğrulayın

Büyük değişiklikler risklidir.

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.

CDN verisini yanlış okumayın

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.

Metrikler yanlış yorumlanınca yanlış kararlar alınır.

"Lighthouse skorumuz 95, harikayız!" Gerçekten mi? Lighthouse lab data, gerçek kullanıcı verisi değil. Kontrollü ortamda fast 3G, Moto G4 simülasyonu. Gerçek kullanıcılarınız 2G'de, eski iPhone'da ne görüyor? CrUX verilerine bakın. P75 değeri Lighthouse'tan çok farklı olabilir.

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.

CDN için sürdürülebilir kontrol rutini kurun

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.

Vaka Notu: CDN var ama kazanç yoktu

Uluslararası trafiği olan bir projede CDN aktifti fakat cache isabeti düşüktü. Sorun, statik ve dinamik içeriğin aynı kurallarla yönetilmesiydi. Ekip içerik sınıflarını ayırdı, edge tarafında saklanacak varlıkları yeniden tanımladı ve purge sürecini sadeleştirdi. Bu değişiklikle uzak bölgelerde bekleme süresi daha dengeli hale geldi.

Vaka, CDN kullanımının tek başına yeterli olmadığını gösterdi. Asıl fark, doğru kural setiyle dağıtım ağını iş yüküne uygun yapılandırmakla oluştu. Bölgesel performans farkı azaldıkça kullanıcı deneyimi tutarlı hale geldi.