CDN mi Almalıyım Daha İyi Hosting mi? Site Yavaşsa

Siteniz yavaş açılıyor ve sorduğunuz herkes size iki şeyden birini söylüyor: "Cloudflare ekle, uçar" ya da "hostingin yetmiyor, paketi yükselt". İkisi de doğru olabilir, ikisi de tamamen boşa para olabilir — çünkü bunlar aynı problemin iki farklı çözümü değil, iki farklı problemin çözümü. CDN mi hosting mi sorusunun cevabı sizin sitenizin nerede takıldığına bağlı ve bunu tahminle değil ölçerek bulabilirsiniz. Yıllardır gördüğüm en pahalı hata, sunucusu boğulan bir WordPress sitesine CDN takıp "hiçbir şey değişmedi" diye şaşırmaktır.

Bu yazıda önce iki ölçüyü ayıracağız: sunucunun ilk baytı gönderme süresi (TTFB) ile tarayıcının sayfayı tamamlama süresi. Sonra tek bir curl komutuyla darboğazın sunucuda mı ağda mı olduğunu ölçmeyi göstereceğim. Ardından CDN'in gerçekte neyi hızlandırdığını, dinamik içeriğin neden önbelleklenemediğini, hangi belirtinin hangi karara götürdüğünü tabloyla vereceğim. Sonunda "önce hangisi" sorusunun net bir sırası olacak elinizde.

Önce Şunu Ayırın: TTFB mi Toplam Yükleme Süresi mi#

Yavaşlık şikâyetlerinin neredeyse tamamı iki bambaşka ölçünün karıştırılmasından doğar. TTFB (Time To First Byte), tarayıcı isteği yolladıktan sonra sunucudan gelen ilk baytı görmesine kadar geçen süredir. Bu sürenin içinde DNS çözümü, TCP el sıkışması, TLS anlaşması ve — asıl önemlisi — sunucunun PHP'yi çalıştırıp veritabanını sorgulayıp HTML'i üretmesi vardır.

Toplam yükleme süresi ise ilk bayttan sonra başlayan her şeydir: CSS, JavaScript, yazı tipleri, görseller, üçüncü parti scriptler. 4 MB'lık bir kapak görseli olan bir sayfada TTFB 120 ms olabilir ama sayfa 9 saniyede açılır. Tersi de olur: 40 KB'lık minimal bir sayfa, TTFB 3.4 saniye olduğu için ölü gibi hissettirir.

Bu ayrım kararınızı doğrudan belirler:

• TTFB yüksekse sorun sunucu tarafındadır. CDN bunu tek başına çözmez.
• TTFB düşük ama toplam süre yüksekse sorun statik varlıklarda ve ağdadır. Hosting yükseltmek bunu çözmez.

Konunun tamamına daha geniş bakmak isterseniz site neden yavaş açılıyor yazısı yavaşlığın tüm katmanlarını tek tek geziyor; burada özellikle CDN/hosting kararına odaklanıyoruz.

Darboğaz Sunucuda mı Ağda mı: Ölçme Yöntemi#

Darboğazı bulmanın en hızlı yolu, tarayıcı açmadan tek bir curl komutuyla isteğin zaman dilimlerini ayırmaktır. Önce bir zamanlama şablonu oluşturun:

cat > curl-format.txt <<'EOF'
     dns_cozumu:  %{time_namelookup}s
   tcp_baglanti:  %{time_connect}s
    tls_anlasma:  %{time_appconnect}s
  istek_gonderi:  %{time_pretransfer}s
     ilk_bayt_TTFB:  %{time_starttransfer}s
        --------
     toplam:  %{time_total}s
       boyut:  %{size_download} bayt
EOF

Sonra sitenizin ana sayfasını ölçün:

curl -w "@curl-format.txt" -o /dev/null -s https://alanadiniz.com/

Tipik bir çıktı şuna benzer:

     dns_cozumu:  0.031s
   tcp_baglanti:  0.062s
    tls_anlasma:  0.148s
  istek_gonderi:  0.148s
     ilk_bayt_TTFB:  2.914s
        --------
     toplam:  3.102s
       boyut:  84213 bayt

Bu çıktı çok şey söylüyor. TLS anlaşması 148 ms'de bitmiş, yani ağ tarafı gayet sağlıklı. Ama ilk bayt 2.914 saniyede gelmiş — arada geçen 2.77 saniye tamamen sunucunun HTML üretme süresi. Burada CDN takmanın hiçbir faydası olmaz; CDN de aynı sunucudan bu HTML'i beklemek zorundadır. Bu tabloda yapılacak iş sunucu tarafını düzeltmektir.

Şimdi ikinci bir örnek:

     dns_cozumu:  0.028s
   tcp_baglanti:  0.241s
    tls_anlasma:  0.605s
  istek_gonderi:  0.605s
     ilk_bayt_TTFB:  0.712s
        --------
     toplam:  0.744s

Burada sunucu HTML'i 107 ms'de üretmiş (0.712 − 0.605). Sağlıklı. Fakat TCP bağlantısı 241 ms, TLS 605 ms sürmüş — bu, sunucuyla ziyaretçi arasındaki fiziksel mesafenin göstergesidir. Yurt dışından gelen ziyaretçileriniz varsa CDN tam olarak bu iki satırı düşürmek için vardır.

Statik bir dosyayla dinamik bir sayfayı ayrı ayrı ölçmek de çok öğreticidir:

# Dinamik: PHP çalışıyor, veritabanı sorgulanıyor
curl -w "TTFB: %{time_starttransfer}s\n" -o /dev/null -s https://alanadiniz.com/urunler/

# Statik: sadece diskten okunuyor
curl -w "TTFB: %{time_starttransfer}s\n" -o /dev/null -s https://alanadiniz.com/wp-content/uploads/logo.png

Statik dosya 90 ms, dinamik sayfa 2.6 saniye geliyorsa tanı nettir: sunucunun ağ tarafı iyi, PHP/MySQL tarafı boğuluyor. Ölçümün mantığını ve hangi eşiklerin kabul edilebilir olduğunu TTFB nedir ve nasıl düşürülür yazısında ayrıntısıyla bulabilirsiniz.

CDN Tam Olarak Neyi Hızlandırır Neyi Hızlandırmaz#

CDN, dosyalarınızın kopyasını dünyanın farklı noktalarındaki sunucularda tutar ve ziyaretçiye en yakın kopyadan servis eder. Kazanç iki yerden gelir: mesafenin kısalması (daha az gecikme) ve isteğin sizin sunucunuza hiç ulaşmaması (daha az yük).

CDN'in gerçekten hızlandırdıkları:

• Görseller, CSS, JS, yazı tipleri, PDF gibi statik dosyalar
• Coğrafi olarak uzaktaki ziyaretçilerin bağlantı kurma süresi
• TLS el sıkışması (kenar sunucuya yapılır, sizin sunucunuza değil)
• Aynı anda gelen çok sayıda statik dosya isteğinin sunucunuzdan alınması

CDN'in hızlandırmadıkları:

• Oturum açmış kullanıcının gördüğü sayfa (sepet, hesabım, panel)
• Her istekte veritabanına giden dinamik sorgular
• Yavaş çalışan bir eklentinin ürettiği gecikme
• Optimize edilmemiş MySQL sorguları
• Yönetim paneli (/wp-admin, /administrator) hızı
• Yükleme (upload) ve form gönderimi işlemleri

Kritik nokta şu: CDN bir önbellektir, bir hızlandırıcı değil. Önbellekten servis edemediği her istek yine sizin sunucunuza döner ve sizin sunucunuz ne kadar yavaşsa ziyaretçi o kadar bekler — üstüne bir de kenar sunucuya uğrama maliyeti biner.

Dinamik İçerik Neden CDN'de Önbelleklenemez#

Bu, Türkçe kaynaklarda en çok atlanan konu. Bir CDN'in bir yanıtı önbelleğe alabilmesi için o yanıtın tüm ziyaretçiler için aynı olması gerekir. Oysa modern bir sitede HTML çoğu zaman kişiye özeldir.

Bir e-ticaret sitesinde sepette 2 ürün olan kullanıcıya "Sepet (2)" yazan bir başlık gösteriliyorsa, bu HTML önbelleğe alınamaz. Alınırsa bir sonraki ziyaretçi başkasının sepetini görür — bu bir hız sorunu değil, veri sızıntısıdır. Bu yüzden CDN'ler oturum çerezi (PHPSESSID, wordpress_logged_in_*, woocommerce_cart_hash gibi) gördükleri isteklerde önbelleği otomatik olarak devre dışı bırakır.

Sunucunun kendisi de bunu talep eder. Tipik bir WordPress yanıt başlığı şöyledir:

curl -sI https://alanadiniz.com/sepet/ | grep -i "cache-control\|set-cookie"

cache-control: no-cache, must-revalidate, max-age=0
set-cookie: woocommerce_items_in_cart=1; path=/

no-cache gördüğü anda hiçbir CDN o yanıtı saklamaz. Yani CDN takmış olsanız bile e-ticaret sitenizin sepet, ödeme, hesabım sayfaları her seferinde sizin sunucunuzdan üretilir. Ziyaretçinin dönüşüme en yakın olduğu sayfalar tam da bunlardır ve CDN oralara dokunamaz.

Aynı mantık şuralar için de geçerlidir:

• Arama sonuç sayfaları (/?s=telefon)
• Filtreli kategori sayfaları (?renk=mavi&beden=42)
• Yorum gönderme, form gönderme, giriş yapma
• Admin paneli ve her türlü AJAX çağrısı

Bu sayfalar hızlanacaksa hızlanma noktası sunucudur: PHP sürümü, opcode önbelleği, veritabanı indeksleri, nesne önbelleği. Memcached kurulumu ve kullanımı gibi sunucu içi önbellek katmanları tam olarak bu boşluğu doldurmak için vardır ve CDN'in yapamadığı işi yapar.

Hangi Belirti Hangi Karara Götürür#

Aşağıdaki tablo, sahada en sık karşılaştığım belirtileri doğru eyleme eşliyor. Ölçümünüzü yaptıktan sonra buraya bakın.

Tablodaki "rastgele 503/508" satırı özellikle önemli: paylaşımlı hostingde kaynak tavanına vurduğunuzda sunucu isteği reddeder. Bunun CDN ile hiçbir ilgisi yoktur ve genellikle 508 Resource Limit Is Reached hatası şeklinde görünür. Limitlerin nasıl hesaplandığını paylaşımlı hosting kaynak limitleri yazısında bulabilirsiniz.

CDN Eklemenin Doğru Olduğu Senaryolar#

CDN, aşağıdaki koşullardan en az birini karşılıyorsanız somut ve ölçülebilir kazanç verir:

1. Ziyaretçileriniz coğrafi olarak dağınık. Sunucu Türkiye'de, ziyaretçilerin önemli kısmı Avrupa/Amerika'daysa mesafe gecikmesi tek başına 200-400 ms ekler. CDN bunu doğrudan siler.
2. Sayfa ağırlığınızın çoğu statik. Görsel ağırlıklı bir portfolyo, blog veya haber sitesinde sayfa boyutunun %80'i resimdir. Bu %80'in sunucunuzdan çıkmaması hem hız hem bant genişliği kazancıdır.
3. Trafik dalgalanmalarınız var. Bir kampanya duyurusu ya da sosyal medya paylaşımı sonrası gelen ani yükte statik dosyaları CDN karşılar, sunucunuz yalnızca HTML üretmeye odaklanır.
4. Basit saldırı yüzeyini azaltmak istiyorsunuz. CDN önünde durduğunda kaynak sunucunuzun IP'si doğrudan hedef olmaz.

Kurulum kısmı çoğunlukla alan adının nameserver'larını CDN sağlayıcısına yönlendirmekten ibarettir; DNS tarafındaki değişimin nasıl işlediğini Cloudflare DNS ve CDN kullanımı yazısında adım adım anlattık.

Hosting Yükseltmenin Doğru Olduğu Senaryolar#

Paket yükseltmek ya da VDS'e geçmek şu tabloların hepsinde tek gerçek çözümdür:

1. TTFB sürekli 1 saniyenin üstünde. Sunucu HTML üretemiyor demektir. Bunun altında ya CPU/RAM yetersizliği ya da I/O darboğazı vardır.
2. Aynı sayfa boş sunucuda hızlı, sizinkinde yavaş. Aynı kodu bir test sunucusuna kurup TTFB'yi ölçün. Fark büyükse mesele kod değil, kaynaktır.
3. error_log dosyanız kaynak uyarısıyla dolu. cPanel'de Metrics → Errors ekranı ya da doğrudan kabuktan:

tail -n 100 ~/logs/alanadiniz.com.error.log | grep -i "memory\|timeout\|limit"

4. PHP bellek limitine takılıyorsunuz. Allowed memory size of 134217728 bytes exhausted satırı gördüğünüz anda mesele CDN değildir.
5. Veritabanınız büyüdü. 2 GB'lık bir MySQL veritabanı, paylaşımlı hostingin I/O bütçesini tek başına tüketebilir.
6. Aynı anda 50+ eşzamanlı ziyaretçi alıyorsunuz. Paylaşımlı pakette eşzamanlı PHP süreç sayısı genellikle tek haneli sınırlıdır; sıraya giren istek bekler.

Yükseltmenin ilk adımı her zaman paket değiştirmek olmak zorunda değil. Sunucu tarafında yapılacak ücretsiz işler de vardır: PHP sürümünü güncellemek, OPcache'i açmak, sıkıştırmayı etkinleştirmek. Nginx gzip ve Brotli sıkıştırma tek başına HTML/CSS/JS transferini üçte birine indirebilir.

İkisini Birlikte Kullanmak: Doğru Sıra#

Doğru cevap çoğu zaman "ikisi de" olur ama sıra önemlidir. Yanlış sırayla ilerlerseniz iyileşmeyi ölçemez, hangi adımın işe yaradığını bilemezsiniz.

1. Ölç ve kaydet. Yukarıdaki curl çıktısını bir dosyaya yazın. Karşılaştırma için başlangıç değeriniz bu olacak.
2. Sunucu tarafını düzelt. PHP sürümü, OPcache, veritabanı bakımı, ağır eklentilerin temizliği. TTFB'yi 300 ms'nin altına çekmeyi hedefleyin.
3. Statik varlıkları küçült. Görselleri WebP'ye çevirin, kullanılmayan CSS/JS'i kaldırın, sıkıştırmayı açın. Bu adım ücretsizdir ve CDN'in taşıyacağı yükü de azaltır.
4. Önbellek başlıklarını doğru kur. CDN'in işe yaraması için sunucunuzun doğru Cache-Control başlıkları göndermesi gerekir:

location ~* \.(jpg|jpeg|png|webp|gif|svg|css|js|woff2)$ {
    expires 365d;
    add_header Cache-Control "public, immutable";
    access_log off;
}

5. CDN'i devreye al. Artık gerçek kazancı ölçebilirsiniz çünkü sunucu tarafı gürültüsü temizlenmiş durumda.
6. Tekrar ölç. Aynı curl komutunu çalıştırın, farkı görün.

Bu sırayı tersine çevirenler şu tuzağa düşer: önce CDN takılır, sayfa biraz hızlanır, "tamam çözüldü" denir, ama sunucu hâlâ boğuluyordur ve ilk trafik dalgasında site komple düşer. CDN yavaşlığı gizler, çözmez.

Sık Yapılan Hatalar#

"CDN taktım, TTFB düşmedi." Doğaldır. CDN önbelleğinde olmayan bir HTML isteği yine sizin sunucunuza gider ve arada bir durak daha vardır. İlk isteklerde TTFB'nin artması bile normaldir.

Önbellek hiç dolmuyor. Sunucunuz Cache-Control: no-store ya da private gönderiyorsa CDN hiçbir şey saklayamaz. Kontrol edin:

curl -sI https://alanadiniz.com/wp-content/uploads/2026/kapak.jpg | grep -i "cache\|cf-cache\|age"

Age: 0 her seferinde görünüyorsa önbellek çalışmıyordur.

Yönetim paneli önbelleğe alınmış. Yanlış kural yazıp /wp-admin yolunu önbelleğe aldıysanız yaptığınız değişiklikleri göremez, oturumunuz karışır. Panel yollarını her zaman önbellek dışında tutun.

CDN'i yedek sanmak. CDN kaynak sunucunuz kapalıyken çoğunlukla eski bir kopyayı gösteremez; hata sayfası verir. Yedekleme apayrı bir konudur.

Görsel boyutunu görmezden gelmek. 5 MB'lık bir kapak görselini CDN'den servis etmek onu 5 MB olmaktan çıkarmaz; sadece daha yakından yollar. Önce küçültün.

Sıkça Sorulan Sorular#

CDN hosting yerine geçer mi#

Hayır, geçmez. CDN sitenizi barındırmaz; sitenizin bir kopyasının parçalarını dağıtır ve her önbelleklenemeyen istek için yine kaynak sunucunuza döner. Kaynak sunucu kapanırsa siteniz de kapanır. CDN bir tamamlayıcıdır: hosting sitenizi çalıştırır, CDN onu daha yakından teslim eder. Bu ikisi birbirinin alternatifi değil, birbirinin üstüne binen iki ayrı katmandır.

Cloudflare eklersem sitem kesin hızlanır mı#

Kesin değil. Sitenizin yavaşlığı sunucudaki PHP ve veritabanı süresinden geliyorsa TTFB büyük ölçüde aynı kalır, hatta ilk isteklerde birkaç on milisaniye artabilir. Yurt dışı ziyaretçisi ağırlıklı, görsel yoğun ve büyük ölçüde statik bir sitede ise fark hemen hissedilir. Karar vermeden önce yazıdaki curl ölçümünü yapıp TTFB ile toplam süreyi ayırmanız gerekir.

TTFB kaç milisaniye olmalı#

Dinamik bir sayfa için 200-500 ms iyi, 500-800 ms kabul edilebilir, 1 saniyenin üstü sorunludur. Statik bir dosyada bu değer 100 ms'nin altında olmalıdır. Ölçümü mutlaka aynı ülkeden ve birkaç kez tekrarlayarak yapın; tek ölçüm yanıltıcı olabilir çünkü ilk istek DNS ve TLS maliyetini de taşır. Aynı sayfayı arka arkaya üç kez ölçüp ortalamasını almak en sağlıklı yöntemdir.

E-ticaret sitesinde CDN işe yarar mı#

Kısmen yarar. Ürün görselleri, kategori kapakları, tema dosyaları ve yazı tipleri CDN'den servis edilerek ciddi kazanç sağlanır. Ancak sepet, ödeme, hesabım ve arama sayfaları oturum çerezi taşıdığı için önbelleğe alınamaz ve her zaman kaynak sunucudan üretilir. Dönüşüm hunisinin en kritik sayfaları bunlar olduğu için e-ticarette sunucu gücü CDN'den daha belirleyicidir.

Önce hangisini yapmalıyım#

Önce sunucu tarafını düzeltin. Sırasıyla PHP sürümünü güncelleyin, OPcache'i açın, ağır eklentileri ayıklayın, veritabanı bakımı yapın ve TTFB'yi ölçülebilir biçimde düşürün. Bu adımların çoğu ücretsizdir ve etkileri kalıcıdır. Sunucu tarafı temizlendikten sonra CDN eklerseniz hem gerçek kazancı ölçebilir hem de bir sorun çıktığında sebebini ayırt edebilirsiniz.

Paylaşımlı hostingde CDN kullanmanın anlamı var mı#

Vardır, hatta paylaşımlı pakette CDN'in katkısı görece daha büyüktür. Paylaşımlı hostingte eşzamanlı istek sayısı ve I/O bütçesi sınırlıdır; statik dosyaların CDN'e devredilmesi bu bütçeyi HTML üretimine ayırmanızı sağlar. Yine de kaynak limitine sürekli takılıyor, 503 veya 508 hataları alıyorsanız asıl çözüm paket yükseltmek ya da sanal sunucuya geçmektir; CDN bu tabloyu yalnızca hafifletir.

CDN kullanınca ziyaretçi istatistiklerim bozulur mu#

Sunucu erişim kayıtlarına dayalı istatistikleriniz eksik görünmeye başlar, çünkü CDN'den servis edilen istekler sunucunuza hiç ulaşmaz. Sunucu tarafı log analiz araçlarında görsel ve statik dosya istekleri kaybolur, sayfa görüntüleme sayıları düşük çıkabilir. JavaScript tabanlı ölçüm araçları bundan etkilenmez çünkü onlar tarayıcıda çalışır. Doğru ziyaretçi sayısını görmek için sunucu logu yerine tarayıcı tarafı ölçüm kullanmanız gerekir.

CDN aktifken sitede yaptığım değişiklikler neden görünmüyor#

Çünkü değiştirdiğiniz dosyanın eski sürümü kenar sunucularda önbellekte duruyor. CSS veya JS dosyasını güncellediyseniz CDN panelinden ilgili yolu temizlemeniz (purge) ya da dosya adına sürüm eklemeniz gerekir; örneğin style.css?v=12 yerine style.12.css gibi dosya adına gömülü sürüm en güvenli yöntemdir. Geliştirme yaparken önbelleği geçici olarak kapatan bir geliştirme modu kullanmak da yaygın bir pratiktir.

Kapanış#

CDN mi hosting mi sorusu, aslında "sorun nerede" sorusunun kılık değiştirmiş hâlidir. TTFB yüksekse sunucu, toplam süre yüksek ama TTFB düşükse ağ ve statik varlıklar. Bu ayrımı yapmadan atılan her adım karanlıkta atılmış bir adımdır. Elinizdeki en güçlü araç pahalı bir servis değil, curl -w ile alacağınız dört satırlık zaman dökümüdür. Ölçün, sunucu tarafını temizleyin, sonra CDN ekleyin ve tekrar ölçün — bu sıra sizi hem doğru karara hem de sonucu kanıtlayabildiğiniz bir iyileşmeye götürür.

Ölçüm sonucunda darboğazın sunucuda olduğunu görüp kaynak yükseltmeye karar verdiyseniz paylaşımlı hosting paketleri içinde daha yüksek CPU ve bellek payı olan bir seçeneğe geçmek çoğu site için yeterli olur; eşzamanlı ziyaretçi sayınız yüksekse ve PHP süreç limitine sürekli takılıyorsanız kaynakların size ayrıldığı bir sanal sunucu daha doğru adrestir. Kurumsal bir site veya sürekli büyüyen bir katalog yönetiyorsanız kurumsal hosting paketleri daha geniş kaynak tavanıyla gelir. Mevcut sitenizi taşırken kesinti yaşamak istemiyorsanız site taşıma hizmeti geçiş sürecini üstlenir.