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

Site yavaşlaması çoğu zaman “hosting kötüdür” sonucuna varılmadan önce çözülebilir. DNS kaynaklı gecikme, yanlış cache ayarı, hatalı eklenti, disk/CPU doygunluğu veya bant genişliği limitleri gibi etkenler çoğu senaryoda ilk 30 dakikada yakalanır. Bu rehberde, hosting değiştirmeden önce yapmanız gereken 7 kontrolü net adımlarla sıralıyoruz; her kontrolün sonunda hangi veriyi görmeniz gerektiğini de belirtiyoruz.

1) Sorun gerçekten sunucuda mı? Kullanıcı tarafı ve zaman çizelgesi

İlk hedef: gecikme şikayeti tek bir kullanıcıda mı, yoksa tüm trafik mi? Çünkü kullanıcı tarafı (tarayıcı, DNS önbelleği, internet rotası) ile sunucu tarafını ayırmadan doğru kararı vermek zor.

Ne yapın

• 3 farklı ağdan test edin: ofis/ev mobil/Wi‑Fi üzerinden. Mümkünse farklı ülkeler de ekleyin.
• Aynı anda bir hız aracı kullanın (ör. Chrome Lighthouse/Pagespeed Insights, ayrıca “traceroute” benzeri rota analizi).
• Zaman çizelgesi çıkarın: hız düşüşü belirli bir saatte mi başladı? Son değişiklik (tema/eklenti/konfig) o saate denk geliyor mu?

Hangi sonuca bakın

• Sadece belirli kullanıcı gruplarında yavaşlık varsa: CDN/DNS rotası veya istemci tarafı önceliklidir.
• Herkes için ve özellikle ilk bayt süresi (TTFB) artıyorsa: sunucu kaynak/uygulama tarafı daha olasıdır.

İpucu: Hız düşüşü “aniden” başladıysa, çoğu zaman en yakın deploy/ayar değişikliği işaret eder. “Kademeli” düşüyorsa kaynak doygunluğu veya bekleyen büyüme (index, log, DB boyutu) daha sık görülür.

2) DNS ve TTL: Alan adı çözümünde gecikme var mı?\nDNS sorunları, hosting değiştirmeden önce en sık gözden kaçan sebeplerden biridir. Özellikle TTL (Time To Live) değişmişse veya kayıtlar yanlış/eksikse tarayıcı ilk sorgularda bekler.

Ne yapın

• dig veya nslookup ile A/AAAA kayıtlarını ve cevap süresini ölçün.
• TTL değerlerini kontrol edin. Çok yüksek TTL, değişiklik sonrası düzelmeyi geciktirir; çok düşük TTL ise doğru yönetilmezse sürekli sorgu maliyeti yaratır.
• DNS provider’ınızda (nameserver) gecikme ve hata logları varsa inceleyin.

Hangi sonuca bakın

Aşağıdakilerden biri görülürse DNS tarafı şüphelidir: - Aynı kaydın farklı resolver’larda belirgin gecikme farkları göstermesi - “SERVFAIL”, “NXDOMAIN” gibi hata durumlarının artması - TTL değişikliğinden sonra düzelmenin gecikmesi

3) Cache katmanlarını doğrulayın: sayfa, uygulama ve tarayıcı

Cache yoksa veya yanlış ayarlanmışsa sunucu her istekte dinamik üretim yapmak zorunda kalır. Bu da CPU ve DB yükünü büyütür; sonuçta TTFB yükselir.

Ne yapın

Cache’i üç katmanda düşünün: 1. Tarayıcı cache (Cache-Control, ETag) 2. Uygulama cache (WordPress cache, OPcache) 3. Sunucu/CDN cache (nginx/Apache cache, CDN)

Örnek kontrol listesi: - Statik dosyalar için Cache-Control: public, max-age=... var mı? - 200/304 oranı dengeli mi? (Çok fazla 200 dönüyor ve 304 düşük kalıyorsa cache çalışmıyor olabilir.) - WordPress kullanıyorsanız sayfa cache ile DB query azaltılıyor mu?

Hangi sonuca bakın

• İlk istek yavaş, tekrar eden istekler hızlıysa: cache devreye girmemiş veya süreleri düşük.
• Her istek yavaşsa: cache tamamen pasif veya “cache bypass” yapan bir durum var (query string, çerez, admin oturumu, yanlış varyantlar).

4) WordPress/uygulama tarafı: eklenti, cron ve istek başına maliyeti ölçün

Site yavaşlamasının en yaygın kaynağı eklentilerin (veya tema fonksiyonlarının) istek başına maliyeti artırmasıdır. Özellikle admin-ajax, REST çağrıları ve yanlış cron işlerinin yük bindirmesi görülebilir.

Ne yapın

• Son 7-14 günde kurulan/güncellenen eklenteleri listeleyin.
• Geçici olarak şunları izole edin:
• Tüm eklentileri pasif edip (mümkünse staging’de) site hızını ölçün.
• Son eklenti gruplarını tek tek aktif ederek “fail” eden eklentiyi bulun.
• WordPress için: WP debug/log, ayrıca query monitor tarzı araçlarla en pahalı sorguları yakalayın.
• Cron (WP-Cron veya sistem cron) çalışıyor mu? Çalışıyorsa iş kuyruğu birikiyor mu?

Hangi sonuca bakın

• Sunucu yanıt süresi artışıyla birlikte belirli endpoint/URL’lerde anormal yük görülüyorsa: o endpoint veya eklenti hedef alınır.
• “Aşırı sayıda aynı sorgu” (özellikle N+1 problemi) varsa DB tarafı optimize edilmeli; hosting değiştirmek sorunu tek başına çözmez.

5) Sunucu kaynak kullanımı: CPU/RAM/disk I/O ve yük dağılımı

Hosting değiştirmeden önce ilk teşhis: kaynak doygunluğu. CPU %90+ uzun süre çalışıyorsa, RAM tükenmeye yakınsa veya disk I/O queue büyüyorsa site yavaşlar.

Ne yapın

Kontrol paneli veya sunucu izleme aracı üzerinden şu metrikleri 15 dakikalık aralıklarla inceleyin: - CPU kullanım yüzdesi (ve load average) - RAM kullanım yüzdesi ve swap kullanımı - Disk I/O (özellikle read/write gecikmesi) - Web server request sayısı (gelen istek) ve hata kodları

Eğer VDS/VPS kullanıyorsanız, sistem seviyesinde örnek olarak şu tür metrikleri inceleyin: - top/htop ile en çok kaynak alan süreç - Disk için iostat/benzeri araçlarla gecikme - Uygulama için servis loglarında zaman damgaları

Hangi sonuca bakın

Aşağıdaki durumlarda hosting değişimi yerine önce kapasite/konfig düzeltmesi gelir: - Swap kullanımı başlıyorsa: RAM yetersiz veya süreçler yanlış davranıyor. - Disk I/O bekleme artıyorsa: yavaş disk, yoğun I/O, index/backup işlemi gibi tetikleyiciler olabilir. - CPU yükselip düşüyorsa: belirli cron işleri veya yoğun trafik anları sebep olabilir.

6) Bant genişliği (bandwidth), saldırı ve tarif limitleri

Hız düşüşü “CPU yavaşlığı” gibi görünse de aslında bant genişliği doygunluğu veya anormal trafik olabilir. Özellikle limitli planlarda egress (çıkış) trafiği kısılır veya gecikme artar.

Ne yapın

• Son 24 saatte transfer (in/out) grafiğini inceleyin.
• 4xx/5xx oranlarını kontrol edin. Anormal yükseliş var mı?
• Web server access log’da aynı IP aralıklarından yoğun istek var mı?
• Fail2ban/WAF varsa aktif mi?

Hangi sonuca bakın

• Egress yükselip eşzamanlı gecikme/timeout artıyorsa: bant genişliği veya throttling ihtimali.
• Sürekli aynı URL’lere yüksek istek ve 401/403/404 karması varsa: bot trafiği/saldırı şüphesi.
• 5xx artıyorsa: uygulama çöküyor veya kaynak sınırına dayanıyor.

7) Loglar ve hata kodları: “Nerede yavaşlıyor?” sorusunu cevaplayın

Hosting değiştirmeden önce en hızlı yol, uygulama ve web server loglarında zaman damgalarıyla birlikte kök nedeni bulmaktır. “Neden”i bulmadan “başka plan/başka sağlayıcı” denemek pahalı olur.

Ne yapın

Şu veri setini toplayın: - Web server logları: nginx/apache access ve error log - Uygulama logları (WordPress debug log, PHP-FPM logları) - Veritabanı logları (MySQL/MariaDB yavaş sorgu) - Sistem logları (OOM, disk dolu, servis restart)

Ayrıca hata kodlarını sınıflayın: - 408/504: upstream zaman aşımı, arka uç yanıtı gecikmiş - 502/503: servisler arası problem veya kapasite/konfig - 429: rate limit (CDN/WAF/app limitleri) - 404/301 zinciri: yönlendirme döngüsü veya yanlış cache varyantı

Hangi sonuca bakın

• Belirli bir endpoint’te 504/502 artıyorsa: uygulama/DB tarafı ilk hedef.
• “Disk dolu” veya “permission denied” mesajları varsa: konfig ve dosya yönetimi.
• “Yavaş sorgu” loglarında aynı query tekrar ediyorsa: index/SQL optimizasyonu.

7 kontrolü tek sayfada karar ağacına bağlama

Aşağıdaki tablo, elde ettiğiniz bulguya göre doğru sonraki adımı seçmenize yardımcı olur.

Ne zaman gerçekten hosting değiştirmelisiniz?

Yukarıdaki 7 kontrol tamamlandıktan sonra şu koşullar netleşiyorsa hosting değişimi veya kaynak artırımı gündeme alınır: - Loglarda belirli saatlerde CPU/RAM disk I/O doygunluğu ve “yavaş sorguların” düzelmeye rağmen devam etmesi - Aynı optimizasyonlara rağmen TTFB ve hata oranı düşmüyor - Plan limitleri (bant genişliği/CPU limit throttling) düzenli tetikleniyor - Kullanılan mimari (ör. PHP-FPM worker sayısı, nginx cache) düzgün olsa bile kapasite yetersiz kalıyor

Bu noktada hosting değiştirmek yerine önce VDS/VPS tarafında daha doğru bir çözüm sıklıkla “daha uygun kaynak dağılımı” olur: worker sayısı, cache sürümü, veritabanı ayarları, disk türü ve IOPS hedefi netleştirilir.

Sonuç: Değiştirmeden önce 7 kontrolü sırayla uygulayın

Site yavaşladıysa “hemen yeni hosting” yerine önce 1) sorun kapsamı, 2) DNS, 3) cache katmanları, 4) uygulama/eklenti ve cron, 5) CPU/RAM/disk I/O, 6) bant genişliği ve bot, 7) log ve hata kodları adımlarını izleyin. Bu kontrollerin her biri, kök nedeni veriyle netleştirir ve gereksiz taşıma masrafını engeller.

Aksiyon önerisi: Bugün 30 dakika içinde 1-3 kontrolleri bitirin, ardından 4-7 ile saat saat log eşleştirmesi yapın. Sorunun “sunucu kaynak” mı “konfig/uygulama” mı “DNS/CDN” mi olduğunu netleştirdikten sonra yalnızca gerçekten gerekli olduğunda plan değişikliğine geçin.