Site açılıyor ama geç açılıyor. Ürün sayfasına tıklıyorsun, 4–5 saniye bekliyorsun. Analytics’te hemen çıkma oranı artmış. İlk refleks genelde şu oluyor: “Hosting yetersiz, sunucu kötü.”
10 yılı aşkın süredir hem sistem yönetimi hem SEO tarafında çalışıyorum. Şunu net söyleyebilirim: Web sitesi yavaşsa her zaman sunucu suçlu değildir. Ama bazen gerçekten öyledir. Kritik nokta şu: Problemi doğru yerden yakalamazsan ya boşuna hosting değiştirirsin ya da asıl darboğazı aylarca görmezden gelirsin.
Bu yazıda meseleyi netleştirelim: Web sitesi yavaşsa sunucu mu sorun?
Web Sitesi Yavaşsa İlk Kontrol Edilmesi Gereken Yer Sunucu mu?
Hayır. İlk bakman gereken metrik TTFB (Time To First Byte) değeridir.
TTFB 150–300 ms aralığındaysa sunucu büyük ihtimalle sağlıklıdır. 800 ms ve üzerindeyse orada ciddi bir problem olabilir. Ama birçok kişi şu hatayı yapıyor:
- PageSpeed kırmızı → Sunucu kötü
- LCP yüksek → Hosting yetersiz
Oysa LCP; büyük görseller, render-blocking JavaScript dosyaları, font yüklemeleri ve temanın yapısından ciddi şekilde etkilenir.
Doğru analiz sırası şöyle olmalı:
- Sunucu CPU ve RAM kullanımı
- Disk I/O (iowait) oranı
- TTFB değeri
- Veritabanı sorgu süreleri
- Frontend optimizasyonu
Sunucuya bakmadan önce uygulama katmanını kontrol etmezsen yanlış karar verirsin.
Gerçek Bir Senaryo: Hosting Değişti Ama Hız Artmadı
Orta ölçekli bir e-ticaret firması. Günlük 5.000 ziyaretçi. WordPress + WooCommerce altyapısı.
Site yavaşladı. Ajans direkt hosting firmasını suçladı. Paylaşımlı hosting’ten VPS’e geçildi. Kaynak 2 katına çıkarıldı.
Sonuç? Hız neredeyse aynı kaldı.
Sebep:
- Ana sayfada optimize edilmemiş 5 MB slider görseli
- 35 adet JS dosyası
- Cache eklentisi yanlış konfigüre edilmiş
- Her ürün sayfasında 100+ SQL sorgusu
Sunucu CPU kullanımı %30’du. Disk I/O normaldi.
Asıl problem yazılım katmanındaydı. Hosting değişikliği sadece maliyet artırdı.
Bu yüzden web sitesi yavaşsa sunucu mu sorun sorusuna cevap vermeden önce ölçüm yapmak şart.
Hangi Durumda Sunucu Gerçekten Yavaşlığın Sebebidir?
Şu belirtiler varsa odak noktası sunucudur:
- CPU sürekli %80 üzeri
- RAM dolu ve swap kullanımı aktif
- Disk I/O %90’a dayanmış
- PHP-FPM process limiti doluyor
- MySQL slow query log sürekli artıyor
- Trafik artınca site cevap veremiyor
Özellikle paylaşımlı hosting ortamlarında “noisy neighbor” problemi yaşanır. Aynı fiziksel makinedeki başka bir site aşırı kaynak tüketiyorsa sizin site de yavaşlar.
Bu durumda daha izole ve optimize edilmiş bir altyapıya geçmek gerekir.
Paylaşımlı Hosting mi, VPS mi, Kurumsal Hosting mi Daha Hızlı?
Sahada gördüğüm ortalama tablo şu:
| Kriter | Standart Paylaşımlı | Standart VPS | Optimize Edilmiş Kurumsal Hosting |
|---|---|---|---|
| Kaynak İzolasyonu | Düşük | Orta | Yüksek |
| Disk Performansı | Değişken | Kullanıcıya bağlı | NVMe ile yüksek |
| Trafik Artışına Dayanım | Zayıf | Orta | Güçlü |
| Sistem Optimizasyonu | Genelde temel | Kullanıcı sorumlu | Sağlayıcı tarafından optimize |
| Yanlış Konfigürasyon Riski | Düşük | Yüksek | Düşük |
Birçok küçük ve orta ölçekli işletme VPS’e geçince her şeyin hızlanacağını sanıyor. Oysa VPS’te optimizasyon tamamen size kalır. Yanlış yapılandırılmış bir VPS, iyi optimize edilmiş bir paylaşımlı hosting’den daha yavaş olabilir.
Bu yüzden altyapı seçerken sadece “kaynak” değil, optimizasyon ve yönetim kalitesi de önemlidir.
Çoğu Kişinin Bilmediği Teknik Detay: PHP-FPM Kuyruk Problemi
WordPress sitelerde performansın gizli düşmanı çoğu zaman CPU değil, PHP-FPM ayarlarıdır.
Varsayılan ayarlarda:
pm.max_children = 5
Aynı anda 20 kullanıcı istek gönderirse 15’i kuyrukta bekler. Kullanıcı bunu “site dondu” olarak algılar.
CPU %40’ta olabilir ama site yavaş görünür.
Doğru yapılandırma için:
- pm.max_children RAM’e göre hesaplanmalı
- OPcache aktif olmalı
- Redis veya Memcached ile object cache kullanılmalı
- KeepAlive ayarları optimize edilmeli
Bu ayarları yapmadan “sunucu kötü” demek eksik analizdir.
Sunucu Lokasyonu Performansı Ne Kadar Etkiler?
Türkiye hedefli bir site ABD lokasyonlu bir sunucuda barındırılıyorsa 150–200 ms ekstra gecikme yaşar. Almanya lokasyonunda bile 40–60 ms fark oluşabilir.
Bu gecikme:
- TCP handshake süresini uzatır
- TLS el sıkışma süresini artırır
- TTFB’yi yükseltir
Özellikle mobil kullanıcıda bu fark daha hissedilir.
Türkiye pazarına yönelik projelerde, düşük gecikmeli ve optimize edilmiş bir altyapı tercih etmek SEO ve kullanıcı deneyimi açısından avantaj sağlar.
Bu noktada kurumsal altyapı ve performans odaklı yapılandırma önemlidir. Örneğin Perminet’in performans odaklı hosting çözümlerini https://perminet.com/web-hosting adresinden inceleyebilirsin. NVMe disk altyapısı ve optimize edilmiş sunucu konfigürasyonları, özellikle performans hassasiyeti olan projelerde stabilite sunar.
Sunucu değişimi ancak gerçekten kaynak darboğazı varsa anlamlıdır.
Web Sitesi Yavaşlığının Sunucu Dışındaki Yaygın Sebepleri Nelerdir?
Şunları kontrol etmeden hosting değiştirme:
- Optimize edilmemiş görseller
- Lazy load kullanılmaması
- Çok fazla üçüncü parti script
- Eski PHP sürümü
- CDN eksikliği
- Gzip veya Brotli kapalı olması
- HTTP/2 veya HTTP/3 kullanılmaması
Birçok sitede sadece PHP 7.4’ten 8.2’ye geçiş bile %20’ye yakın performans artışı sağlar.
Yavaşlık çoğu zaman yazılım mimarisinden gelir.
SEO Açısından Sunucu Kaynaklı Yavaşlık Ne Anlama Gelir?
Google artık Core Web Vitals metriklerine ciddi önem veriyor:
- LCP
- CLS
- INP
Eğer sunucu kaynaklı gecikme varsa, özellikle rekabetçi long-tail anahtar kelimelerde sıralama kaybı yaşanabilir.
Yavaş site = yüksek bounce rate.
Yüksek bounce rate = zayıf kullanıcı sinyali.
SEO tarafında performans, içerik kadar kritiktir.
FAQ – Web Sitesi Yavaşsa Sunucu mu Sorun?
TTFB ideal olarak kaç olmalı?
200–300 ms altı sağlıklıdır. 800 ms üzeri ciddi bir problem işaretidir.
Hosting değiştirince hız garanti artar mı?
Hayır. Eğer frontend veya veritabanı kaynaklı problem varsa değişmez.
VPS her zaman daha mı hızlıdır?
Yanlış yapılandırılmış VPS, iyi optimize edilmiş hosting’den daha yavaş olabilir.
CDN yavaşlığı tamamen çözer mi?
Statik içerikte evet. Ama dinamik işlemler için yeterli değildir.
Sunucu performansını nasıl ölçebilirim?
CPU load, RAM kullanımı, disk I/O, TTFB ve slow query log analiz edilmelidir.
Web sitesi yavaşsa önce ölç.
Veriye bak. Loglara bak.
Bazen gerçekten sunucu sınırdadır.
Ama çoğu zaman sorun, sunucunun kendisi değil; nasıl yapılandırıldığıdır.
Bir yanıt yazın