WordPress Eklentileri Sunucuyu Yavaşlatıyorsa: Net Teşhis Rehberi

WordPress’te hız problemlerinin önemli bir bölümü eklenti kaynaklıdır: hatalı sorgular, gereksiz script yüklemeleri, yanlış önbellek kullanımı veya aynı işlemin birden fazla eklentiyle tekrar çalıştırılması. Bu yazıda “site yavaş” şikâyetini tahmine değil ölçüme bağlayacak bir teşhis akışı bulacaksınız. Hangi metriğin neyi gösterdiğini, eklentiyi nasıl izole edeceğinizi ve hangi kalıcı ayarlarla geri dönüş almadan düzelteceğinizi net adımlarla öğreneceksiniz.

WordPress yavaşlaması eklentiden mi geliyor? 4 net belirti

Eklentinin suçlu olup olmadığını anlamak için önce belirtileri doğru okuyun. Aşağıdaki durumlar, çoğu senaryoda eklenti/konfigürasyon kaynaklı performans düşüşüne işaret eder:

• Yük testi veya yoğun saatlerde CPU kullanımı sürekli yükseliyor (özellikle PHP-FPM/CPU grafikleri). Tekil istekler değil, işlem yoğunluğu artıyor.
• Sayfa ilk yükleme yavaş, ama önbellek açık olunca düzeliyor. Eklenti çakışması veya cache katmanında yanlış davranış var.
• Admin panel (wp-admin) veya belirli sayfa türlerinde belirgin yavaşlık var. Örneğin sadece WooCommerce, sadece arama sayfası, sadece eklenti ayar ekranı.
• DB (MySQL/MariaDB) sorgu sayısı/lock bekleme artıyor. Eklenti kısa aralıklarla yoğun sorgu çalıştırıyor veya masraflı bir WP hook’u döngüye alıyor.

Bu dört belirtiyi görüyorsanız sıradaki adım “tüm eklentileri söküp deneme” değil; eklentiyi sistematik şekilde izole etmektir.

1. adım: Sorunu ölçün (sunucu değil siteyi değil, doğru yeri ölçün)

Eklentinin performans etkisini kanıtlamak için üç katmanda ölçüm yapın: tarayıcı/HTTP, PHP çalışması, veritabanı.

Tarayıcı/HTTP tarafı: Lighthouse tek başına yetmez

Şunlara bakın: - TTFB (Time To First Byte): İlk yanıt gecikiyorsa sunucu tarafı gecikiyor. - Tam sayfa yüklenmesi (Load time): Statik dosyalar geç yükleniyorsa eklenti script/stil yüklüyor olabilir.

Aynı zamanda DevTools Network üzerinden her isteğin yüklenme sürelerini görün. Örneğin bir sayfada aynı anda çok fazla JS dosyası gelmesi (özellikle üçüncü parti widget’lar) eklenti kaynaklıdır.

Sunucu tarafı: CPU/RAM/Load + PHP-FPM

VDS/VPS yönetiminde şu metrikler kritik: - CPU (özellikle PHP-FPM worker’ları meşgulse) - Load average (çekirdek sayısını aştığında darboğaz artar) - RAM (swap kullanımı başlarsa ciddi yavaşlama)

WordPress yavaşlığında çoğu zaman CPU artışı “tek bir eklenti anormal çalışıyor” ipucudur.

Veritabanı tarafı: sorgu maliyeti ve lock

MySQL/MariaDB tarafında: - Toplam sorgu sayısı (Queries per second) - Uzun süren sorgular - Lock wait / deadlock izleri

Eklentiler özellikle şu durumlarda DB’yi şişirir: - Abone/yorum/sosyal paylaşım gibi alanlarda gereksiz sorgu - Her sayfa yüklenirken “ayrı ayrı” hesap yapılan kodlar - Yanlış cron (WP-Cron) kullanımı

2. adım: Eklentiyi izole edin (körlemesine değil, kontrolle)

Tek tek denemek yerine kontrollü bir izolasyon uygulayın. Amaç: “hangi eklenti hangi metrikte değişim yaratıyor?”

A/B testi gibi düşünün: eklentileri gruplara ayırın

• Eklentileri işlevlerine göre 3-5 gruba ayırın: cache/optimizasyon, SEO, güvenlik, formlar/CRM, WooCommerce vb.
• Her grupta “siteyi aynı saat aralığında” test edin. (Yoğunluk dalgalanmasını azaltmak için.)

Net hedef örnekleri: - “TTFB 2.8 sn → 1.3 sn oldu mu?” - “CPU ortalaması 65% → 35% oldu mu?” - “DB’de uzun sorgu sayısı azaldı mı?”

WordPress’te devre dışı bırakma (plugin isolation) yöntemi

• Panelden devre dışı bırakma yerine, hızlı sonuç için önce kritik olmayanları kapatın.
• En sık sorunun kaynağı olan eklenti sınıfları:
• Cache/optimizasyon eklentileri birbiriyle çatışıyorsa
• Görsel optimizasyon + lazy load + CDN aynı anda “çift iş” yapıyorsa
• Güvenlik eklentileri ek WAF kurallarıyla her isteği ağırlaştırıyorsa
• Sitemap/SEO eklentisi her istek sırasında ağır üretim yapıyorsa

3. adım: Ortak eklenti hatalarını net şekilde tespit edin

Aşağıdaki sorunlar, eklenti kaynaklı yavaşlamalarda sık görülür. Her birinde “neye bakacağınızı” net yazıyorum.

1) Çifte cache: Aynı katmanda iki eklenti

Belirti: Sayfa “aynı anda” birden fazla cache üretiyor ya da cache var/yok mantığı sürekli bozuluyor. - Test: Cache header’larını kontrol edin. Aynı istekte tekrarlandığı hissi varsa çakışma olabilir. - Çözüm: Tek bir cache stratejisi belirleyin: - Ya eklenti cache, - Ya sunucu cache (reverse proxy/CDN katmanı), - Ya da her ikisi arasında doğru entegrasyon.

2) JS/CSS şişkinliği: Her sayfaya gereksiz yük

Belirti: Özellikle ana sayfa/ürün liste sayfalarında script yükleri artıyor. - Test: DevTools’ta her eklentinin yüklediği dosyaları tek tek görün. - Çözüm: Eklentide “sayfaya göre yükle” (conditional loading) ayarını açın veya kullanılmayanları devre dışı bırakın.

3) WP-Cron’un yanlış kullanımı

Belirti: CPU sabit aralıklarla yükselir; özellikle yoğun saatlerde “ani spike” olur. - Test: WP-Cron tetiklerinin ne zaman çalıştığını kontrol edin. - Çözüm: WP-Cron’u gerçek cron ile yönetmeye alın. (Eklenti yoğunluğu sabit aralıklarla üretim yapmasın.)

4) Veritabanı ağır sorgular

Belirti: DB CPU artışı, “long query” raporları. - Test: Uzun süren sorguları raporlayın. - Çözüm: Eklentide ayarları değiştirin (ör. log tutma, sayım/istatistik frekansı) veya eklentiyi değiştirin.

4. adım: Hız profilini çıkarın (hangi işlem yavaş?)

Eklenti kaynağını netleştirmenin en hızlı yolu, hangi kısmın pahalı olduğunu anlamaktır.

Debug ile yükü görün

• Query monitor (query sayısı ve süresi) benzeri eklentiler, hangi hook’un ağır çalıştığını yorumlamayı kolaylaştırır.
• Hedef: “Toplam yanıt süresi içinde en büyük pay hangi bileşende?”

Bu noktada amaç şunu yapmaktır: - Eğer yavaşlık PHP tarafında (TTFB yüksek) ise eklenti iş mantığı veya DB sorgusu ağırdır. - Eğer yavaşlık tarayıcı tarafında (DOM/JS yük) ise eklenti script/stil/üçüncü parti çağrıları ağırdır.

5. adım: Net çözüm listesi (etkisi yüksek sıralı aksiyonlar)

Aşağıdaki adımları, “önce en hızlı, sonra en kalıcı” mantığıyla uygulayın.

Hızlı aksiyonlar (genelde ilk 1-2 saat içinde ölçülebilir)

1. Cache çakışmasını temizleyin: Aynı kategoride birden fazla cache/optimizasyon eklentisini iptal edin.
2. Eklentileri gruplu test edin: En muhtemel çakışma grupları (cache/SEO/güvenlik) önce.
3. Üçüncü parti scriptleri erteleyin: Çerez duvarı, canlı sohbet, sosyal widget’lar için “lazy/load after interaction” tercih edin.

Orta seviye aksiyonlar (aynı gün sonuç alınır)

1. Cron yönetimini düzeltin: WP-Cron’u sistem cron ile kontrol edin.
2. Log ve istatistik frekansını düşürün: Güvenlik ve analytics eklentileri yoğun log yazıp DB’yi şişirebilir.
3. Görsel optimizasyonu tekleştirin: Aynı işi yapan birden fazla eklentiyi kapatın (ör. lazy load + image compression + CDN optimizasyon).

Kalıcı aksiyonlar (kalıcı performans ve bakım)

1. Eklenti envanteri çıkarın: Kurulu tüm eklentilerin amacı, yüklendiği sayfalar ve kritik olup olmadığı.
2. Eklenti sürüm kontrolü: Eski sürüm veya sık güncellenmeyen eklentiler performans sorunlarını uzatır.
3. Gerçek trafikle test edin: Staging (sürüm/test ortamı) iyi; ama son karar için gerçek yoğunluğa yakın test gerekir.

6. Sunucu tarafı eklentiyi “daha da kötü” yapıyorsa: kaynak planı

Eklentiler tek başına her zaman suçlu değildir. Yetersiz CPU/RAM veya yavaş disk, eklentinin etkisini büyütür. Bu yüzden teşhis sırasında “sunucu zayıf mı, yoksa eklenti mi?” ayrımını net yapın.

• Eğer CPU/RAM zaten sınırda ise: eklenti “küçük” bir ek maliyet bile spike yaratır.
• Eğer DB hızlı değilse: sorgu maliyeti büyür.

Bu durumda şu tabloyu kullanın:

7. Ölçümden sonra karar: Eklentiyi düzeltmek mi, değiştirmek mi?

Net karar için şu ölçütleri kullanın:

Eklentiyi düzeltin (ayar/değişiklik yeterli)

• Sorun tek bir ayarda (ör. cache çakışması, cron frekansı, lazy load çakışması) çözülüyorsa
• Aynı eklentiyi devre dışı bırakınca değil, yalnızca ayarı güncelleyince metrikler düzeliyorsa

Eklentiyi değiştirin (kod/iş mantığı uyumsuz)

• Eklenti kapatılınca sorun tamamen bitiyorsa ve tekrar açınca geri geliyorsa
• Uzun query üretimi sürekli aynı eklentiden geliyorsa
• Aynı işi yapan başka eklenti daha düşük sorgu/CPU ile çalışıyorsa

8. Son kontrol: Staging ve geri alma planı

Eklentileri çok hızlı şekilde devre dışı bırakıp sistem bozmak istemezsiniz.

Staging ortamı kurun (varsa)

• Aynı WordPress sürümü ve PHP sürümüyle test edin.
• Eklenti değişiminden sonra en az 10-20 istekle hızlı metrik kontrolü yapın.

Geri alma (rollback) kuralı

• Her testte “ne yaptığınızı” not alın.
• Sonuç kötüleşirse geri almayı tek hamlede yapın: eklenti aktif/pasif durumunu, cache ayarlarını ve cron ayarlarını.

Sonuç: Aksiyon planı (hedefe yönelik şekilde başlayın)

WordPress’te eklenti kaynaklı yavaşlamayı çözerken en doğru yaklaşım, tahmin yerine ölçüm ve izolasyondur. Önce TTFB/CPU/DB metrikleriyle sorunun yönünü bulun; sonra eklentileri gruplara ayırarak kontrollü şekilde izole edin. İlk gün içinde cache çakışmasını temizleyin, WP-Cron yönetimini düzeltin ve DB’yi şişiren uzun sorguları hedefleyin. Eğer aynı eklenti geri geldikçe sorun tekrar oluşuyorsa, düzeltmekten önce değiştirme kararını verin. Bu adımları uygularsanız “hangi eklenti yavaşlatıyor?” sorusuna net cevap alıp performansı kalıcı olarak geri kazanırsınız.