Site Yavaşladı: Hosting Değiştirmeden Önce 7 Net Kontrol

Site hızındaki düşüş genellikle “hosting kötü” demeden önce ortaya çıkar. Çoğu senaryoda sorun; yanlış cache ayarı, yavaş sorgular, DNS/TLS gecikmesi, anormal trafik, hatalı eklenti/konfigürasyon veya kaynak şişmesi gibi daha somut başlıklardan gelir. Bu rehberde, hosting değiştirmeden önce uygulayabileceğiniz 7 net kontrol listesini adım adım veriyorum. Her kontrolün sonunda “neyi ölçtüğünü” ve “hangi sonuca göre ne yapacağını” netleştireceksiniz.

1) Sorunun nerede oluştuğunu ayır: Tarayıcı mı sunucu mu?

Önce gecikmenin kaynağını bulmanız gerekir. Hız testi tek başına yeterli değildir; ölçümün nereden alındığını bilmelisiniz.

Ne yapın?

• Aynı anda üç ölçüm alın:
• Tarayıcıdan (gerçek kullanıcı deneyimi)
• Sunucuya yakın bir lokasyondan (edge/CDN etkisini ayıklamak için)
• Başka bir ağdan (mobil/Wi‑Fi farkı)
• Geliştirici araçlarında (Chrome DevTools) Time to First Byte (TTFB) değerini inceleyin.

Net karar kriteri

• TTFB yüksek (ör. 1s+): Büyük ihtimalle sunucu tarafı (PHP/uygulama, veritabanı, cache kaçırma, yoğunluk).
• TTFB düşük ama sayfa yine yavaş: Büyük ihtimalle tarayıcı/varlık tarafı (sıkıştırma yok, büyük görseller, JS/CSS yüklenmesi).

Hız şikayeti başladığında, önce “TTFB mi yüksekti, yoksa render mı yavaştı?” sorusunu cevaplayın. Bu, sonraki 7 kontrolün sırasını belirler.

2) Son 30 gün değişikliklerini “hız olay zaman çizelgesi” gibi çıkarın

Hosting değiştirmeden önce, uygulamanın/konfigürasyonun değişip değişmediğini doğrulamak zorunludur. Hız artışı yerine azalış genelde belirli bir tarihle çakışır.

Ne yapın?

Aşağıdaki maddeleri tek liste halinde yazın: - Yeni eklenti/tema güncellemesi - PHP sürümü değişimi - Cache eklentisi değişimi (sayfa cache, object cache) - Cron job (planlı görev) eklendi mi/çoğaldı mı? - Veritabanına yapılan migrasyonlar - Dosya boyutları büyüdü mü (görsel, log, cache dizinleri) - CDN/WAF eklendi veya ayarı değişti mi?

Net karar kriteri

• “Tam şu tarihte yavaşladı” noktasında yapılan değişiklik varsa, önce onun ayarını ve etkisini geri kontrol edin.
• Yavaşlık “kademeli” ise: kaynak tükenmesi (CPU/RAM), disk doluluğu, log birikmesi, veritabanı şişmesi gibi durumlar daha olasıdır.

3) Gerçek yükü ölçün: CPU/RAM/disk doluluğu ve süreç yoğunluğu

Paylaşımlı hostingde bile, genellikle kontrol paneli üzerinden net sinyaller görürsünüz. Hedef “tahmin” değil, ölçüm toplamaktır.

Paylaşımlı hosting / VPS kontrol ekranı

• Kontrol panelinde:
• CPU limit / kullanım (varsa)
• RAM kullanımı (varsa)
• Disk doluluğu
• “Son 24 saat” sistem kaynakları
• Uygulama tarafında:
• PHP-FPM / mod_php durumları (servis varsa)
• Queue varsa (ör. arka plan işler)

Net karar kriteri

• Disk doluluk yaklaşmışsa (örn. %90+): i/o gecikmesi artar, log/temporary dosyalar yavaşlatır.
• CPU sürekli yüksekse: PHP istekleri veya çalışan işler (cron) tıkanıyordur.
• RAM sık kullanımdaysa: sayfa üretimi daha yavaşlar ve cache etkisi düşer.

Somut aksiyon

• Disk doluluğu yüksekse: log rotasyonu, eski cache dosyalarının temizliği, gereksiz yedeklerin kaldırılması.
• CPU yüksekse: cron/arka plan işlerini yavaş saatlere almak ve maliyetli sorguları düzeltmek (5. kontrol).

4) Cache kaçırması var mı? Sayfa cache + object cache davranışını doğrulayın

Çoğu “hosting yavaş” şikayeti aslında cache’in çalışmamasından çıkar. Sayfa cache (page cache) ve object cache (Redis/Memcached) ayrı katmanlardır.

Ne yapın?

• Sayfa cache aktif mi?
• Aynı URL’yi tekrar tekrar açtığınızda yanıt süresi düşüyor mu?
• Cache hit/oranı kontrol edin (kullanılan eklenti veya CDN varsa).
• Uygulama cache anahtarları doğru mı?
• Oturum (session) yüzünden her istekte sayfa kişiselleşiyor mu?
• Statik dosyalar doğru şekilde cache’leniyor mu?

Net kontrol testi

• Tek bir sayfada:
• İlk istek ile ikinci/üçüncü istek farkına bakın.
• Arada çok büyük fark yoksa cache büyük ihtimalle atlanıyor.

Net karar kriteri

• Cache atlanıyorsa: hosting değiştirmek yerine cache ayarını düzeltin.
• Cache hit oranı iyi ama yine TTFB yüksekse: sorun daha çok DB/uygulama kaynaklıdır (5. ve 6. kontrol).

5) Veritabanını hedefe koyun: yavaş sorguları bulun ve düzeltin

Yavaşlıkların önemli kısmı MySQL/MariaDB sorgularından gelir. En kritik noktalar: yanlış indeks, büyük tablolar, sık tekrarlanan rapor sorguları ve kilitlenmeler.

Ne yapın?

• Uygulama/DB panelinden:
• yavaş sorgu (slow query log) veya benzeri raporlar
• en çok zaman harcayan sorgular
• WordPress kullanıyorsanız:
• WP’nin “çok sık çalışan” eklentilerini tespit edin (arama, istatistik, her sayfada ek sorgu yapanlar)

Somut teşhis adımları

• 10-20 en yavaş sorguyu listeleyin.
• Her sorgu için şunları kontrol edin:
• Hangi tablolar etkileniyor?
• WHERE koşulu indeks kullanıyor mu?
• ORDER BY / JOIN alanlarında indeks var mı?

Net karar kriteri

• En yavaş 3 sorgu toplam sürenin büyük bölümünü alıyorsa: hosting değiştirmek yerine indeks ve sorgu optimizasyonu net kazanç verir.
• Sorgular “kilitlenme” içeriyorsa: transaction süreleri uzamış olabilir. Uzun transaction’ları kısaltın ve gereksiz yazmaları azaltın.

6) Ağ katmanı: DNS, CDN, TLS ve yönlendirme gecikmesini ölçün

Sunucu iyi olsa bile DNS/TLS gecikmesi veya CDN yanlış konfigürasyonu sayfayı yavaşlatır.

Ne yapın?

• DNS çözüm süresini ölçün (örn. dig/nslookup gibi araçlarla, farklı lokasyonlarda).
• TLS doğrulama süreleri ve sertifika zinciri sorunlarını kontrol edin.
• HTTP/2 veya HTTP/3 var mı? Yükleniyor mu?
• CDN/WAF kullanıyorsanız:
• Origin’e doğru yönlendiriyor mu?
• Cache header’ları (Cache-Control) doğru mu?

Net karar kriteri

• İlk bağlantı (TLS handshake) çok uzun sürüyorsa: sertifika zinciri, farklı protokol uyumsuzluğu veya hatalı ara sunucu kaynaklı olabilir.
• CDN var ama içerik her seferinde origin’den geliyorsa: cache ayarı bozuk demektir.

7) Hata ve trafik anomalisini bul: loglar ve anlık yük sinyalleri

“Hosting değiştir” kararını en çok tetikleyen şey, bir anda başlayan hatalar veya trafik patlamasıdır. Loglar burada en hızlı cevabı verir.

Ne yapın?

• Web sunucusu erişim logu ve hata logunu inceleyin:
• 4xx oranı artmış mı? (özellikle 429/403/404)
• 5xx artmış mı? (500/502/503)
• Uygulama loglarında:
• PHP fataller/timeout’lar
• “maximum execution time” veya benzeri hatalar
• WAF varsa:
• bloklanan istek sayısının artıp artmadığı
• Otomatik tarama/saldırı belirtisi:
• aynı IP aralığından çok yoğun 404/403

Net karar kriteri

• 5xx artışı + timeout: muhtemelen DB/uygulama tıkanması var (5. kontrol).
• 429/403 yoğunluğu: rate limit veya WAF kuralı aşırı tetikleniyor olabilir (6. kontrol ile birlikte).
• Belirgin tarama trafiği: önce güvenlik filtreleri ve bot yönetimi, sonra performans optimizasyonu.

Hız sorunu için 7 kontrolün kısa özet akışı

Aşağıdaki sırayla ilerlerseniz hosting değiştirme kararını daha hızlı verirsiniz: - TTFB yüksek mi? (1) - Son değişiklikler yavaşlıkla çakışıyor mu? (2) - CPU/RAM/disk kaynakları limitleniyor mu? (3) - Cache gerçekten çalışıyor mu (hit oranı)? (4) - En yavaş sorgular hangileri ve indeks sorunu var mı? (5) - DNS/TLS/CDN cache/HTTP protokol sorunu var mı? (6) - Loglarda hata veya anomali var mı? (7)

Kontrol listesi: 20 dakikada yapılacak pratik tarama

• [ ] 3 lokasyondan (ve mümkünse farklı ağdan) TTFB ölçümü
• [ ] Yavaşlığın başladığı tarihi ve yapılan değişiklikleri çıkarma
• [ ] Disk doluluğu kontrolü
• [ ] Cache hit davranışı (aynı sayfa tekrar deneme)
• [ ] En az 1 sayfada hataların/timeout’ların varlığı
• [ ] DB’de yavaş sorgu işaretleri (varsa slow query)
• [ ] Erişim logunda 4xx/5xx ve anomali IP yoğunluğu

Hosting değiştirme ne zaman gerçekten gündeme alınır?

Yapmanız gereken kontrolleri tamamladığınız halde şu tabloda kaldıysanız hosting değişimi/ölçekleme mantıklıdır:

Sonuç: Önce ölçün, sonra değiştirin

Site yavaşladı olduğunda “hosting değiştireyim” yerine önce bu 7 net kontrolü uygulayın: TTFB’yi ayırın, değişiklik zamanını yakalayın, kaynakları doğrulayın, cache’in çalıştığını test edin, yavaş sorguları hedefleyin, DNS/TLS/CDN gecikmesini eleyin ve loglardaki anomaliyi bulun. Bu adımların ardından sorun hâlâ çözülemiyorsa kapasite/altyapı planını yükseltmek veya VDS/VPS gibi daha kontrollü bir ortama geçmek doğru aksiyon olur. Eğer isterseniz, kullandığınız yazılımı (WordPress mi değil mi), hedef trafiği ve şikayetin başladığı tarihi paylaşırsanız, bu 7 kontrolü sizin senaryonuza göre önceliklendirebilirim.