Sitem Neden Yavaş Açılıyor? Teşhis Sırası ve Kalıcı Çözümler

“Sitem yavaş açılıyor” şikâyetinin arkasında çok farklı sebepler olabilir ve bunların yalnızca bir kısmı hostingle ilgilidir. Doğru yaklaşım, tahmin yürütüp eklenti silmeye başlamak değil, önce yavaşlığın nerede geçtiğini ölçmektir.

Bir sayfanın açılması iki ayrı aşamadır: sunucunun cevabı üretmesi ve tarayıcının o cevabı çizmesi. İkisi tamamen farklı sebeplerden yavaşlar ve çözümleri de farklıdır. Aşağıdaki teşhis sırası, hangi aşamada olduğunuzu 10 dakikada belirler.

Bu ayrımı yapmadan atılan her adım kör atıştır; çoğu sitede haftalar süren “optimizasyon” çabası, aslında yanlış aşamaya harcanmış emektir.

Adım 1: TTFB mi, yükleme mi?

TTFB (Time To First Byte), tarayıcının isteği gönderdiği an ile sunucudan ilk baytın geldiği an arasındaki süredir. Ölçmek için tarayıcıda F12 > Network sekmesini açın, sayfayı yenileyin, ilk satırdaki belgeye tıklayın ve Timing altındaki Waiting (TTFB) değerine bakın.

TTFB iyi ama sayfa yine de geç görünüyorsa sorun sunucuda değil, tarayıcıya gönderdiğiniz yükte demektir. TTFB kötüyse doğrudan 4. adıma geçin.

Adım 2: Doğru araçla ölçün

• PageSpeed Insights: Google’ın ölçümü. Puanla değil, LCP, CLS ve INP değerleriyle ilgilenin. LCP hedefi 2,5 saniyenin altıdır.
• WebPageTest: Test konumunu seçmenizi sağlar. Ziyaretçileriniz Türkiye’deyse İstanbul ya da Frankfurt konumundan ölçün; Virginia’dan yapılan test size gereksiz kötü sonuç verir.
• Tarayıcı Network sekmesi: Hangi dosyanın kaç KB olduğunu ve ne kadar sürdüğünü tek tek gösterir. En değerli araç budur.
• Query Monitor (WordPress): Sayfa üretimindeki sorgu sayısını, yavaş sorguları ve hangi eklentinin ne kadar süre harcadığını gösterir.

Ölçümü her zaman önbellek kapalıyken ve ikinci kez tekrarlayın; ilk ölçüm çoğu zaman soğuk önbellek yüzünden yanıltıcıdır.

Adım 3: Ön yüz sorunları (TTFB iyiyse buraya bakın)

Optimize edilmemiş görseller

En sık bulunan tek sebep budur. Network sekmesinde 500 KB’ı aşan her görsel bir sorundur. Kontrol edin:

• Görsel gerçek gösterim boyutundan büyük mü? 400 piksel gösterilen alana 3000 piksellik dosya konması yaygın hatadır.
• Biçim WebP mi, hâlâ JPEG/PNG mi? WebP’ye geçiş tipik olarak %25-35 kazandırır.
• Ekranın altındaki görsellerde loading="lazy" var mı?

Eklenti ve script şişkinliği

Her eklenti kendi CSS ve JS dosyasını her sayfaya ekler. Yalnızca iletişim sayfasında kullanılan bir form eklentisinin dosyalarının ana sayfada yüklenmesi sık görülür. Network sekmesinde 40’tan fazla JS/CSS isteği görüyorsanız birleştirme ve koşullu yükleme gerekir. WordPress eklenti seçimi yazısı hangi eklentinin ne kadar yük getirdiğini ölçmeyi anlatıyor.

Üçüncü taraf script’leri

Canlı destek widget’ı, ısı haritası, üç ayrı reklam etiketi, iki analitik: bunlar toplamda 800 KB’ı ve 1 saniyeyi kolayca bulur. Hepsini kapatıp tek tek açarak etkilerini ölçün.

Adım 4: Sunucu tarafı sorunları (TTFB kötüyse buraya bakın)

Önbellek yokluğu

Önbelleksiz bir WordPress sayfası her ziyarette baştan üretilir: PHP çalışır, 40-80 veritabanı sorgusu koşar, HTML oluşur. Sayfa önbelleği bunu hazır HTML dosyası sunmaya indirir ve TTFB 800 ms’den 80 ms’ye düşebilir. Sunucuda LiteSpeed varsa LSCache modülü bunu sunucu düzeyinde yapar; ayrıntısı LiteSpeed nedir yazısında.

Veritabanı

Yavaş sorguların tipik kaynakları: wp_options tablosunda birikmiş autoload verisi (1 MB’ı geçmemeli), temizlenmemiş revizyonlar, süresi dolmuş transient kayıtları, indekssiz özel tablolar. WooCommerce’de wp_postmeta tablosunun milyon satıra çıkması yaygındır.

Kaynak limitleri

Paylaşımlı hesapta yoğun saatte limite çarpıyorsanız site “bazen” yavaşlar; bu düzensizlik iyi bir ipucudur. cPanel > Resource Usage ekranında EP, CPU ve IO fault sayılarına bakın. Sıfırdan büyük değerler ve yavaşlık saatlerinin çakışması, sorunun kod değil kapasite olduğunu söyler. Bu noktada paylaşımlı hosting ve VPS karşılaştırması karar vermenize yardım eder.

Uzak servis çağrıları

En sinsi sebep budur. Sayfa üretilirken PHP’nin başka bir sunucuya istek atması (kur bilgisi, kargo sorgusu, stok entegrasyonu, lisans doğrulaması) ve o sunucunun geç cevap vermesi, sitenizi sizin hiçbir hatanız olmadan yavaşlatır. Query Monitor’ün HTTP API Calls bölümü bu çağrıları ve sürelerini listeler. Çözüm: sonucu önbelleğe alın ve zaman aşımını 5 saniyeye düşürün.

Eski PHP sürümü

PHP 7.4’ten 8.2’ye geçiş, tipik bir WordPress kurulumunda sayfa üretim süresinde %20-40 kazanç sağlar. Bedava bir iyileştirmedir ve Select PHP Version ekranından birkaç dakikada yapılır.

Adım 5: Sıra dışı ama sık görülen üç sebep

1. DNS gecikmesi: Yavaş bir DNS sağlayıcısı her ilk ziyarete 200-400 ms ekler. Network sekmesinde DNS Lookup süresine bakın.
2. Yönlendirme zinciri: http://ornek.com → https://ornek.com → https://www.ornek.com zinciri iki ek gidiş-dönüş demektir. Tek adımda hedefe gidin.
3. Kötü niyetli trafik: Erişim günlüğünde aynı IP’den saniyede onlarca istek varsa site yavaşlığının sebebi ziyaretçi değil bot taramasıdır.

Özetle

• Önce TTFB’ye bakın: 200 ms’nin altındaysa sorun ön yüzde, 600 ms’nin üstündeyse sunucudadır.
• Ön yüzde en sık iki sebep, optimize edilmemiş görseller ve gereksiz yüklenen eklenti dosyalarıdır.
• Sunucu tarafında sırayla önbellek, veritabanı, kaynak limitleri, uzak servis çağrıları ve PHP sürümüne bakın.
• Yavaşlık “bazen” oluyorsa neredeyse her zaman kaynak limiti ya da bot trafiğidir; sürekliyse kod ve önbellek sorunudur.
• Her değişiklikten sonra tek tek ölçün; aynı anda beş şeyi değiştirirseniz neyin işe yaradığını asla bilemezsiniz.