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

WordPress sitelerinde hız düşüşlerinin önemli bir kısmı eklentiler kaynaklıdır. Sorun; aşırı istek atan (request yoğun), kötü yazılmış (inefficient) sorgular üreten ya da arka planda işleri sürekli çalıştıran eklentilerde görülür. Bu rehberde, eklentinin gerçekten performans düşürdüğünü kanıtlamayı, kök nedeni bulmayı ve kalıcı olarak düzeltmeyi adım adım öğreneceksiniz. Hedef, “sorun eklenti mi?” sorusundan başlayıp ölçüm ve kontrol listesiyle net aksiyona varmak.

Eklenti kaynaklı performans sorununu doğru tanımlayın

İlk adım, yavaşlamanın nerede başladığını belirlemektir. Sunucu kaynaklarını (CPU, RAM, disk I/O) ve WordPress katmanını (veritabanı, PHP, uygulama kodu) birlikte değerlendirdiğinizde “tahmin” yerine ölçüm yaparsınız.

1) Yavaşlama belirtilerini eşleştirin

Aşağıdaki belirtiler, eklenti kaynaklı sorunlarda sık görülür: - Sayfa açılış süresi artıyor ama ziyaretçi trafiği değişmiyor. - Admin panelinde (wp-admin) veya WooCommerce/checkout gibi ek alanlarda gecikme belirgin. - Site yoğun saatlerde değil, belirli zaman aralıklarında yavaşlıyor (cron/planlanmış işler). - Veritabanı sorgu sayısı artıyor ya da bazı sorgular uzun sürüyor. - CPU kullanımı dalgalanıyor; PHP-FPM worker’ları sürekli meşgul kalıyor.

Bu sinyaller varken eklenti kontrolüne geçin. Tek eklentiyi suçlamak yerine, ölçümle “hangisi” olduğunu çıkarın.

2) “Son değişiklik” kontrolü

WordPress tarafında yapılan son değişiklikleri sıraya koyun: - Yeni eklenti kuruldu mu? - Güncelleme yapıldı mı? - Cache (sayfa önbelleği, OPcache, CDN) ayarı değişti mi? - PHP sürümü değişti mi?

Eklentinin yavaşlatıp yavaşlatmadığını netleştirmek için en hızlı yöntem, değişiklik zamanlarıyla performans düşüş zamanlarını çakıştırmektir.

Hız düşüşünü 30 dakikada kanıtlayın (teşhis planı)

Aşağıdaki süreç, hem eklentiyi bulmayı hem de kanıt toplamayı hedefler. 30 dakikada tamamlanabilecek bir “net teşhis” akışı kurun.

Adım 1: Uptime/TTFB ve log zamanlarını eşleştirin

• Uptime/monitoring veriniz varsa: yavaşlama başladığı saat aralığını not edin.
• Sunucu tarafı loglardan (örn. web server access log, PHP-FPM log) aynı saat aralığını filtreleyin.
• WordPress hata kayıtlarında (debug log) eş zamanlı uyarı/hatayı kontrol edin.

Adım 2: Eklenti çalışmasını durdurmayı kontrollü yapın

Amacınız “sitede her şeyi kapatıp körlemesine silmek” değil; kontrollü biçimde eklenti etkisini görmek.

Yöntem (kademeli pasifleştirme): 1. Tüm eklentileri değil, gruplar halinde kapatın. 2. Her kapatma sonrası 3–5 dakika içinde sayfa yükleme süresini tekrar test edin. 3. Aynı test metodunu kullanın (aynı sayfa, aynı cihaz/konum, aynı saat aralığı).

Bu yöntem özellikle şu durumda etkilidir: aynı anda çalışan birden fazla eklenti sorun yaratıyor olabilir.

Adım 3: Stres testi değil, “gerçek uç senaryo” ölçün

Yavaşlama eklentiden geliyorsa, çoğu zaman belirli bir akışta (ör. ürün listeleme, arama, checkout, kullanıcı girişi) daha net görünür. - Kullandığınız en kritik 1–2 sayfayı seçin. - Uygulama testi yapın: hızlı bir baseline alın, sonra eklentiyi kapatın/test edin.

Adım 4: WordPress veritabanı sorgularını izleyin

Eklenti yavaşlatmanın en sık yolu veritabanına kötü sorgularla yük bindirmektir. - Uzun süren sorgular var mı? - Aynı sorgu sürekli tekrar ediyor mu? - JOIN/LIKE gibi ağır sorgular var mı?

Eğer managed bir barındırma kullanıyorsanız, kontrol panelinde (phpMyAdmin, DB monitoring, slow query log) slow query (yavaş sorgu) verisine bakın.

Hangi eklentiler en sık sunucu yükü oluşturur?

WordPress ekosisteminde “her site için aynı” suçlu yoktur; ancak yük oluşturan sınıflar nettir. Aşağıdaki tablo, tipik yük kaynaklarını ve beklenen etkileri özetler.

Sunucu tarafında doğrulama: CPU, RAM, IOPS ve PHP-FPM

Eklenti, uygulama katmanında çalışır; ancak etkisi sunucu kaynaklarında görünür. Bu nedenle teşhisi sunucu metrikleriyle doğrulayın.

PHP-FPM worker tıkanması nasıl anlaşılır?

• CPU kullanımı yükselirken yanıt süreleri uzuyorsa,
• PHP-FPM worker sayısı doygunluğa yakınsa,
• “yanıt üretme” süresi artıyorsa,

bu durum genellikle eklentinin yoğun iş yaptığını gösterir (ör. sık sorgu, ağır hesap, dış servis çağrıları).

IOPS/DB disk gecikmesi eklentiyle artar

Veritabanı tablolarına sık yazan veya çok okuma yapan eklentiler disk I/O’yu artırır. - Yoğun saatlerde değil, eklenti cron çalışırken disk gecikmesi yükseliyorsa, - WP veritabanında yazma oranı artıyorsa,

kök neden eklentidir. Bu, özellikle “planlanmış senkronizasyon” yapan eklentilerde yaygındır.

Önemli not: Sadece RAM’e bakmayın

RAM düşüklüğü başka sorunlar da doğurur; ama eklenti kaynaklı yavaşlamada en belirgin iz CPU + DB sorgu davranışı olur. Bu yüzden teşhis planında mutlaka veritabanı ve PHP davranışına odaklanın.

Çözüm: Sorunlu eklentiyi bulduktan sonra kalıcı düzeltme

Eklentinin suçlu olduğunu kanıtladıktan sonra 3 yol vardır: kaldırma, yapılandırma veya alternatif.

1) Yapılandırma ile düzeltin: Sık yapılan hatalar

Aşağıdaki ayar türleri, performans sorununu düzeltirken en hızlı kazancı verir: - Gereksiz tarama/yeniden işleme kapatın (özellikle görsel ve indeksleyen eklentiler). - Cron aralığını düşürün; gereksiz sık çalışmayı durdurun. - Dış servis çağrıları için zamanlayıcı ve cache kullanın. - Güvenlik eklentilerinde aşırı log/alert ayarlarını azaltın.

Bu adımlar “kaldırma” zorunluluğunu azaltır.

2) Veritabanı yükünü azaltın

Eklenti kötü sorgu yapıyorsa veya gereksiz veri üretiyorsa şu kontrolleri uygulayın: - Gereksiz meta verisi temizliği (dikkat: doğru silme şart). - Eski transients (geçici cache) temizliği. - Periyodik “revisions” ve otomatik taslaklar kontrolü.

Bu temizlik işlemlerini yoğun trafik döneminde değil, düşük trafikte yapın.

3) Cache katmanını tekleştirin (çakışmayı kesin)

Çakışan cache çözümleri, hız yerine yavaşlık yaratır. Şu kontrol listesi net sonuç verir: - Sayfa önbelleği yapan eklenti ile sunucu cache aynı anda gereksiz mi? - OPcache (PHP opcode cache) aktif mi? - CDN varsa, cache header’ları doğru mu?

Cache çakışması olduğunda, eklenti kapatıldığında hız artışı net şekilde görülür.

4) Alternatif eklenti seçerken performans kriteri kullanın

Eklentiyi değiştirecekseniz “popülerlik” yerine şu kriterleri temel alın: - Son güncellemeler: son 6-12 ayda güncelleme var mı? - İssue/geri bildirim yoğunluğu: performans şikayetleri var mı? - Dokümantasyon: cron, cache, DB kullanımına dair net ayar var mı?

Bu yaklaşım, aynı tür sorunun başka eklentide tekrar etmesini engeller.

Uygulanabilir kontrol listesi (sorunu hızla kapatmak için)

Aşağıdaki listeyi, eklenti yavaşlatma şüphesi olan her senaryoda aynı sırayla çalıştırın.

• [ ] Yavaşlama başladığı saat aralığını belirleyin.
• [ ] Son 24–72 saatte yapılan WordPress değişikliklerini yazın.
• [ ] Eklentileri gruplar halinde kapatıp test edin (aynı sayfalar, aynı koşullar).
• [ ] Yavaşlama tekrarlıyor mu kontrol edin (en az 2 tekrar).
• [ ] Slow query log (yavaş sorgu kaydı) var mı inceleyin.
• [ ] PHP-FPM/Cpu dalgalanması ve yanıt süresi ilişkisini doğrulayın.
• [ ] Sorunlu eklentinin cron/arka plan işlerini gözden geçirin.
• [ ] Cache çakışmasını ortadan kaldırın.
• [ ] Gerekirse eklentiyi kaldırın ve alternatifle aynı test senaryosunu tekrar çalıştırın.

Ne zaman sunucuyu büyütmek yerine eklentiyi düzeltmelisiniz?

Bu karar noktası önemlidir. Eklenti kaynaklı sorunlarda “sadece RAM/CPU artırmak” geçici çözüm olur.

Aşağıdaki durumlar eklenti düzeltmesini zorunlu kılar: - Eklenti kapatılınca 5–15 dakika içinde belirgin hız artışı oluşuyorsa, - DB sorgu süreleri azalınca toplam yanıt süresi düşüyorsa, - Cron saatlerinde dalgalanan CPU/IO değerleri düzelince site stabil oluyorsa,

Bu senaryolarda asıl hedef eklentiyi yeniden yapılandırmak veya değiştirmektir.

Tersine, eklenti kaynaklı değil de genel ölçek sorunu varsa (ör. trafik arttı ve sistem her durumda doyuma yaklaşıyor) o zaman kapasite planı gündeme alınır. Ama bunun kanıtı da metriklerle gelmelidir.

Sonuç: Önce ölçün, sonra tek değişiklikle düzeltin

WordPress eklentileri sunucuyu yavaşlatıyorsa çözüm yolu “deneyerek silmek” değil, zamanlı ölçüm ve kontrollü testtir. Yavaşlama saatlerini loglarla eşleştirin, eklentileri gruplar halinde pasifleştirip net farkı doğrulayın; ardından sorunlu eklentinin cron, veritabanı sorguları ve cache çakışmasını hedefleyerek kalıcı düzeltmeyi uygulayın. Hemen bugün yapmanız gereken aksiyon: Kritik 2 sayfayı seçin, 1 eklenti grubu kapatıp 3 test yapın ve sonucu tablo halinde not edin; bir sonraki adımı bu veriye göre verin.