Site Yavaşladı: Hosting Değiştirmeden Önce 7 Kontrol
Siteniz yavaşladığında hosting değiştirmek ilk akla gelen çözümdür — ancak sorunların büyük bölümü sunucudan değil, yapılandırmadan kaynaklanır. 7 adımlı teşhis rehberi.
Site hızı düştüğünde çoğu kullanıcı doğrudan hosting firmasını suçlar ve plan yükseltmeyi ya da sağlayıcı değiştirmeyi düşünür. Ancak gerçekte yavaşlığın kaynağı çoğunlukla sunucu kapasitesiyle ilgili değildir; optimize edilmemiş görseller, gereksiz eklentiler, yavaş veritabanı sorguları veya eksik CDN yapılandırması çok daha sık rastlanan nedenlerdir. Hosting değiştirmek hem zaman hem para maliyeti yaratır ve yanlış bir kökenden yapılacak bu değişiklik sorunu çözmez. Bu rehberde, hosting kararı vermeden önce yapılması gereken 7 sistematik kontrolü somut araçlar ve eşik değerlerle açıklıyoruz.
1. TTFB Değerini Ölçün — Sunucu Gerçekten Yavaş mı?
TTFB (Time to First Byte), tarayıcının isteği göndermesinden sunucunun ilk baytı döndürmesine kadar geçen süredir. Bu değer, sorunun sunucu tarafında mı yoksa içerik/yapılandırma tarafında mı olduğunu anlamanın en hızlı yoludur.
| TTFB Değeri | Yorumu |
|---|---|
| < 200 ms | Sunucu sağlıklı |
| 200–500 ms | Dikkat edilmeli, PHP ve DB incelenmeli |
| 500 ms – 1 s | Ciddi sorun, kök neden araştırılmalı |
| > 1 s | Sunucu kapasitesi veya ağ sorunu olabilir |
Nasıl ölçülür:
curl -w "%{time_starttransfer}" -o /dev/null -s https://siteniz.com
GTmetrix ve WebPageTest da TTFB değerini milisaniye cinsinden gösterir. TTFB 200 ms altındaysa sunucunuz sağlıklı çalışıyor demektir — yavaşlığın kaynağı başka bir katmandadır. Bu değer yalnızca 500 ms'yi aşıyorsa hosting altyapısı gerçekten sorgulanmalıdır.
2. Sunucu Kaynak Kullanımını Kontrol Edin
TTFB yüksek çıktığında ikinci adım sunucunun CPU ve RAM kullanımına bakmaktır. VDS veya VPS kullanıyorsanız SSH üzerinden anlık durumu görebilirsiniz:
top -bn1 | head -20
free -m
Kritik eşikler:
- CPU sürekli %80 üzerinde: Kapasite sorunu var, plan yükseltmesi veya optimizasyon gerekir.
- RAM dolu, swap kullanılıyor: Bellek yetersizliği — uygulama veya önbellek (cache) konfigürasyonu gözden geçirilmeli.
- CPU zirveleri kısa süreli, ortalama düşük: Kötü yazılmış tek bir sorgu ya da belirli bir sayfa baskı yapıyor olabilir; bu genel kapasite sorunu değildir.
Sürekli yüksek CPU'ya rağmen ziyaretçi sayısı normalse, kaynağı tüketen süreç büyük olasılıkla bir eklenti, kötü amaçlı yazılım taraması veya optimize edilmemiş bir cron job'dır.
3. Veritabanı Sorgularını İnceleyin
Özellikle WordPress gibi içerik yönetim sistemleri kullanan sitelerde yavaşlığın başlıca kaynağı veritabanı sorgularıdır. MySQL'de yavaş sorgu kaydı (slow query log) etkinleştirilerek hangi sorguların ne kadar süre aldığı tespit edilebilir.
/etc/mysql/my.cnf veya /etc/my.cnf dosyasına eklenecek ayar:
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 1
Bu ayarla 1 saniyeden uzun süren sorgular loglanır. Kayıtları analiz etmek için mysqldumpslow veya Percona Toolkit'in pt-query-digest aracı kullanılabilir.
WordPress'te hızlı kontrol için Query Monitor eklentisi, her sayfa yüklemesinde çalışan sorgu sayısını ve süresini gösterir. Sayfa başına 50'den fazla sorgu veya toplam sorgu süresi 500 ms üzeri normalden fazladır. Tek bir yavaş sorguyu optimize etmek, çoğu zaman hosting değişikliğinden 10 kat daha etkili sonuç verir.
4. Görsel ve Statik Dosya Boyutlarını Kontrol Edin
Bir sayfanın toplam boyutu, sunucunuzla doğrudan ilgisi olmadan yüklenme süresini etkiler. Görseller optimize edilmemişse, 200 ms TTFB'ye sahip mükemmel bir sunucudan bile 3 MB'lık sayfa yavaş yüklenir.
Hızlı tanı: Tarayıcıda F12 → Network sekmesini açın, sayfayı yenileyin ve en büyük dosyalara bakın.
| Kaynak Türü | Önerilen Maksimum Boyut |
|---|---|
| Ana sayfa toplam | < 1,5 MB |
| Tek görsel (JPEG/WebP) | < 150 KB |
| CSS toplamı (minify sonrası) | < 100 KB |
| JavaScript toplamı | < 300 KB |
Görseller için WebP formatına geçiş ve srcset kullanımı, statik dosyalar için Gzip/Brotli sıkıştırma ve minifikasyon uygulanmadan hosting değiştirmek anlamsızdır — aynı sorun yeni sunucuda da devam eder.
5. Render-Blocking Kaynakları Değerlendirin
Tarayıcı bir sayfayı işlerken <head> içindeki JavaScript ve CSS dosyalarını yükleyip ayrıştırana kadar görsel içeriği oluşturmayı durdurur. Bu render-blocking (görsel işlemeyi engelleyen) kaynaklar, TTFB mükemmel olsa bile sayfanın uzun süre boş görünmesine neden olur.
Google PageSpeed Insights veya Lighthouse bu kaynakları tespit eder ve somut tasarruf sürelerini gösterir.
Yapılacaklar:
- JavaScript dosyalarını
deferveyaasyncözniteliğiyle yükleyin - Kritik olmayan CSS'i asenkron yükleyin
- Kullanılmayan CSS/JS'i kaldırın (DevTools Coverage sekmesiyle tespit edilebilir)
- Üçüncü taraf scriptleri (canlı sohbet, analitik, reklam) birleştirin veya sayfa yüklendikten sonraya erteleyin
Eklentilerin yüklediği 20–30 ayrı script dosyası, zayıf sunucu kapasitesinden çok daha fazla yavaşlığa neden olabilir.
6. CDN Yapılandırmasını ve Önbellek Başlıklarını Denetleyin
İçerik Dağıtım Ağı (CDN), statik dosyaları kullanıcıya coğrafi olarak yakın sunuculardan sunar. CDN yoksa veya yanlış yapılandırılmışsa Türkiye dışı ziyaretçiler için gecikme kaçınılmazdır ve bu sorun hosting kapasitesiyle çözülmez.
CDN çalışıyor mu? Kontrol:
Yanıt başlığında cf-cache-status: HIT (Cloudflare için) veya x-cache: Hit görünüyorsa dosya CDN'den geliyor demektir. MISS veya bu başlıkların yokluğu CDN'nin etkin olmadığını gösterir.
Önbellek (cache) başlıkları kontrol listesi:
| Başlık | Beklenen Değer |
|---|---|
Cache-Control |
max-age=31536000 (statik dosyalar için) |
Expires |
Gelecekte bir tarih |
ETag |
Mevcut olmalı |
Vary |
Accept-Encoding içermeli |
CDN olmadan ya da önbellek başlıkları eksikken her ziyaretçi için her dosya sunucudan yeniden çekilir. Bu yapısal bir sorundur ve hosting değişikliğiyle çözülmez.
7. Eklenti Sayısını ve Harici İstekleri Sayın
WordPress sitelerinde her aktif eklenti veritabanına sorgu atar, JavaScript/CSS dosyası yükler ve zaman zaman harici servislere istek gönderir. 40–50 eklentili bir site tek başına en güçlü sunucuyu dahi zorlayabilir.
Tanı yöntemi:
- Tarayıcı → F12 → Network — tüm istekleri listeleyin
- Harici alan adı sayısına bakın (
fonts.googleapis.com,cdn.somewhere.com,tracker.example.comgibi) - Her harici istek, DNS çözümlemesi ve bağlantı kurma süresi ekler
Dikkat gerektiren durumlar:
- Toplam HTTP istek sayısı > 80
- Harici alan adı sayısı > 10
- Herhangi bir tek istek > 2 saniye (genellikle harici API)
Gereksiz eklentileri devre dışı bırakmak ve harici fontları yerel olarak sunmak, ücretli plan geçişi kadar etkili olabilir — ve ücretsizdir.
7 Kontrolün Özet Tablosu
| # | Kontrol | Araç | Kritik Eşik |
|---|---|---|---|
| 1 | TTFB ölçümü | curl, GTmetrix | > 500 ms sorun |
| 2 | CPU/RAM kullanımı | top, kontrol paneli | CPU sürekli > %80 |
| 3 | Yavaş DB sorguları | slow query log, Query Monitor | > 50 sorgu/sayfa |
| 4 | Görsel ve dosya boyutu | Browser DevTools | Toplam > 1,5 MB |
| 5 | Render-blocking kaynaklar | Lighthouse, PageSpeed | Tespit edilen her kaynak |
| 6 | CDN ve önbellek başlıkları | curl -I | Cache-Control eksikse |
| 7 | Eklenti ve harici istek sayısı | Network sekmesi | > 80 istek |
Sonuç: Hosting Değişikliği Ne Zaman Gerçekten Gereklidir?
Yukarıdaki 7 kontrolü tamamladıktan sonra karar verme tablosu şudur:
- TTFB < 200 ms, CPU normal: Hosting suçlu değil — optimizasyon yapın.
- TTFB 200–500 ms, CPU zirveleri var ama ortalama düşük: Önce veritabanı ve eklenti optimizasyonu deneyin.
- TTFB > 500 ms, CPU sürekli > %80, kaynak gerçekten yetersiz: Plan yükseltme veya hosting değişikliği haklıdır.
Yavaşlık şikayetlerinin büyük bölümü — optimize edilmemiş görseller, fazla eklenti, CDN eksikliği — mevcut hosting üzerinde ücretsiz veya düşük maliyetle çözülebilir. Hosting değişikliği, tüm bu adımlar tamamlandıktan sonra hâlâ somut bir sunucu kapasitesi sorunu varsa başvurulacak son çaredir; birinci adım değil.
Hosting karşılaştırması yapmaya hazır mısın?
100+ firmanın fiyatlarını tek tıkla karşılaştır, en uygun paketi bul.
Hosting Karşılaştır →İlgili Yazılar
DKIM, SPF, DMARC: E-posta Deliverability Net Rehberi
DKIM, SPF ve DMARC ayarlarını doğru kurun: kayıt örnekleri, test adımları, yaygın hatalar ve deliverability etkisi için net kontrol listesi.
Hosting Paketi Seçerken Yapılan 5 Hata ve Net Çözüm Rehberi
Hosting paketi seçerken yapılan 5 yaygın hatayı öğrenin: yanlış kaynak planlama, kontrol paneli beklentisi, yedekleme/SSL eksikleri ve daha fazlası.
Açık Portları Kapatma: Sunucu Hardening Rehberi
Açık portları kapatmak için net kontrol adımları: hangi portlar riskli, nasıl taranır, güvenli kapatma ve kalıcı hardening ayarları.
ModSecurity nedir, paylaşımlı hostingde aktif mi?
ModSecurity (WAF) nasıl çalışır, hangi saldırıları engeller ve paylaşımlı hostingde aktif edilip edilmediğini nasıl kontrol edeceğinizi öğrenin.