WordPress eklentileri sunucuyu yavaşlatıyorsa: Tanı ve çözüm planı

WordPress’te performans düşüşü çoğu zaman “eklentiler suçlu” diye genellenir; ancak gerçek neden genelde daha nettir: yanlış yapılandırılmış bir cache eklentisi, yoğun veritabanı sorguları, her sayfa yüklemesinde çalışan üçüncü parti script’ler, CDN ile çakışan optimizasyonlar veya çalışmayan ama yüklenen eklentiler. Bu rehberde, eklentinin gerçekten yavaşlattığını kanıtlayacak ölçümleri nasıl yapacağınızı, hangi eklentileri nasıl sırayla devre dışı bırakacağınızı ve sunucu tarafında hangi ayarların sorunu çözdüğünü adım adım göreceksiniz.

Belirti → ölçüm eşleştirmesi (rastgele değil, hedefli)

İlk hedefiniz “hız düştü” demek değil, nerede tıkanma olduğunu tespit etmektir. Aşağıdaki tabloyu bir kontrol listesi gibi kullanın.

Belirti	Büyük olasılık	Hangi metriğe bakın?
Sayfa yüklenmesi yavaş, ilk isteklerde bekleme var	PHP tarafı darboğazı veya eklenti döngüsü	CPU (yüksek mi), PHP-FPM çocukları, toplam istek süresi
Hazır sayfalar hızlı ama admin/düzenleme geç açılıyor	Admin eklentileri, cron/arka plan	admin-ajax süresi, cron tetiklenmeleri
Database sorguları artıyor, “Write” yükseliyor	Veritabanı yoğun eklenti	MySQL performans şablonu: yavaş sorgular
TTFB (First Byte) yüksek	Önbellek atlanıyor veya çakışma	cache hit oranı, sayfa önbelleği var mı
RAM doluyor, zamanla yavaşlıyor	Cache, oturum (session) yığılması veya zayıf limitler	RAM kullanımı, OOM olayları
Cache var zannediliyor ama tekrar tekrar çalışıyor	Yanlış cache kuralı veya “minify”/script eklentisi çakışması	sayfaların gerçekten cache’lenip cache’lenmediği

Ölçüm için minimum set

Ek tipsiz, pratik bir yöntem: 1) Sunucu metrikleri: CPU, RAM, disk IO ve ağ (network) 2) WordPress zaman çizelgesi: eklentinin tetiklediği istekler (özellikle admin-ajax / REST API) 3) Veritabanı: yavaş sorgu sayısı ve en uzun sorgular 4) HTTP istekleri: sayfa başına script sayısı ve üçüncü parti istekler

Eklentiyi kanıtlayın: “Devre dışı bırak ve tahmin et” yerine yöntem

Eklenti kaynaklı yavaşlatmayı doğru teşhis etmenin en hızlı yolu “kör sıralı deneme” değil, kontrollü eleme yapmaktır.

1) Staging (demo) üzerinde test edin

Canlı sitede denemeye çalışmayın. Staging’de şu hedeflerle ilerleyin: - Son eklenti güncellemelerini aynen kopyalayın. - Aynı URL’lere, aynı kullanıcı senaryolarıyla yük testini yapın. - Sonuçları karşılaştırın (TTFB, toplam yükleme süresi, hata kodları).

Eğer staging yoksa en azından “maintenance window” açıp kontrollü inceleme yapın. Yine de staging, hata riskini düşürür.

2) Query Monitor ile “hangisi çalışıyor?”

Query Monitor (ve benzeri araçlar) eklentinin gerçekten hangi noktada ağırlaştığını görmenizi sağlar. Şu bölümlere bakın: - Toplam SQL sorgusu sayısı ve yavaş sorgular - Hook kaynaklı çağrılar (hangi eklenti hangi hook’ta çalışıyor) - HTTP API çağrıları (wp_remote_get gibi) - Otomatik cron tetiklemeleri (bazı eklentiler sayfa ziyaretinde cron işletebilir)

Not: Sadece “eklentiyi kapatınca hızlandı” demek yetmez. En azından yavaşlatma modelini görün: çok sayıda sorgu mu, gereksiz dış istekler mi, cache atlama mı?

3) Performans profili çıkarın: GTmetrix / Lighthouse + TTFB

Lighthouse ve benzeri araçlar sayfa ağırlığını gösterir; asıl kritik bilgi TTFB’dir. TTFB yüksekse genelde: - PHP-FPM bekleme sırası vardır - Object Cache devre dışıdır ya da cache atlanmaktadır - Sayfa önbelleği (page cache) çalışmıyordur - Veritabanı gecikmektedir

Ortak suçlular: Eklenti türüne göre tipik yavaşlatma mekanizmaları

Eklentiler aynı sonucu farklı yollarla üretir. En sık görülen senaryolar aşağıdadır.

Cache eklentisi ile çakışma (en yaygın durum)

Bazı durumlarda iki cache eklentisi (veya cache + minify) birlikte çalışır ve cache kuralları çakışır. - TTFB artar - Her istek “dynamic” davranır - Sayfa cache hit oranı düşer

Çözüm planı: 1) Cache rolünü tek bir eklentiye verin. 2) CDN kullanıyorsanız, CDN cache ile WordPress page cache’in “aynı şeyi” yapıp yapmadığını kontrol edin. 3) Minify/combining gibi özellikleri önce kapatıp ölçün.

Veritabanı yoğun eklentiler

Kötü kurulmuş bazı eklentiler: - Her sayfa yüklemesinde gereksiz sorgular - “N+1 query” benzeri çoğalan sorgular - Admin-ajax üzerinden anlık sorgu yığılması

Çözüm planı: - Query Monitor’de en uzun 5 sorguyu bulun. - O sorgular hangi eklentiye ait hook ile tetikleniyor belirleyin. - Eklentinin ayarlarında “limit, senkronizasyon sıklığı, arkaplan iş” gibi parametreleri düşürün.

Reklam/etiket/pixel ve üçüncü parti script bolluğu

Eklenti yüklemese bile eklediği script sayısı ve dış istekler sayfa hızını düşürür. - LCP ve TBT yükselir - Network waterfall uzar

Çözüm planı: - Üçüncü parti scriptleri “tek tek” devre dışı bırakın. - Aynı amaca hizmet eden birden fazla etiket varsa tekleştirin. - Gereksiz sayfalarda çalışan scriptleri kapatın (ör. sadece ana sayfa yerine tüm sayfalara ekleniyorsa).

Güvenli teşhis süreci: 60–90 dakikalık net akış

Aşağıdaki akış, canlıda risk almadan sonuca götürür.

1) Eklentileri gruplara ayırın

Eklentileri şu gruplara bölün: - Cache / performans - SEO - Güvenlik (WAF, brute force) - Formlar / analiz - Medya / galeri - WooCommerce / üyelik - Özel özelleştirmeler

2) Tek tek değil, kontrollü eleme

Önerilen sıralama: 1) Cache + minify + script optimizasyonlarını geçici kapatıp ölçün 2) Son güncelleme yapılan eklentileri kapatın 3) Dış servis kullananları (pixel, feed, embed) kapatın 4) Admin-odaklı eklentileri sadece admin senaryosunda test edin

Her adımda şu ölçümleri aynı araçla alın: - TTFB - Toplam yükleme süresi - 4xx/5xx hata oranı - Sunucu CPU/RAM zirveleri

3) Sonuçları “varsayımla” değil sayıyla tutun

Basit bir not sistemi kurun: - Durum: “Cache açık / kapalı” - Ortalama TTFB: X ms → Y ms - CPU zirvesi: X% → Y% - Yavaş sorgu sayısı: X → Y

Bu kayıtlar, doğru eklentiyi bulmanızı hızlandırır. Ayrıca birden fazla eklenti birlikte sorun çıkarıyorsa kombinasyon hatasını da yakalarsınız.

Sunucu tarafında düzeltme: CPU/RAM ve PHP ayarları

Eklenti kaynaklı sorun olsa bile sunucu kapasitesi ve PHP yapılandırması büyüklüğü etkiler.

PHP-FPM çocuk sayısı (children) ve istek kuyruğu

Belirti: CPU yüksek, istekler kuyruğa giriyor, TTFB artıyor.

Ne yapın? - Mevcut PHP-FPM child sayısını ve max requests davranışını kontrol edin. - Aynı anda gelen isteklerde kuyruk artıyor mu bakın.

Yetersiz RAM veya yanlış cache boyutu

Belirti: Zamanla hız düşüyor, hatta servisler yeniden başlatılabiliyor.

Ne yapın? - RAM grafiğinde sürekli yukarı trend var mı kontrol edin. - Cache (object cache) gerçekten kullanılıyor mu doğrulayın.

Veritabanı bağlantı limitleri

Eklenti yoğun sorgu çalıştırdığında MySQL bağlantıları tıkanabilir. - “Max connections” limitine yaklaşma - Çok sayıda kısa bağlantı

Ne yapın? - MySQL ayarlarında bağlantı limitlerini ve uzun sorgu sürelerini inceleyin. - Uygulama tarafında yavaş sorguları azaltın (sorun kök neden değilse optimizasyon geçici kalır).

Object Cache (Redis/Memcached) gerçekten ne zaman işe yarar?

Eklentiler bazen her sayfada aynı hesapları tekrar eder. Object cache bunu azaltır.

Ne zaman etki büyük olur?

Çok sayfalı sitede (haber, dergi, kategori trafiği)
Aynı verinin tekrar tekrar okunması (ayarlar, menüler, şema verileri)
WooCommerce / üyelik senaryolarında tekrar eden sorgular

Ne zaman tek başına çözmez?

Eklenti dış API’leri her istekle çağırıyorsa
Sayfa cache tamamen devre dışıysa
Veritabanında N+1 sorgu problemi varsa

Net yaklaşım: - Önce page cache + object cache doğru çalışsın. - Sonra eklentinin sorgu maliyetini düşürün.

Hızlı karar matrisi: “Eklentiyi değiştir mi, ayarla mı?”

Aşağıdaki tablo karar vermeyi kolaylaştırır.

Durum	Hedef	Yapılacak
Eklentiyi kapatınca TTFB belirgin düşüyor	Kök neden net	Alternatif eklenti veya ayar revizyonu
Kapatsanız da yavaşlık sürüyor	Kök neden başka	Cache/tema/hosting katmanını incele
Sorgu sayısı artıyor	DB darboğaz	Eklenti ayarları + yavaş sorgu optimizasyonu
Dış istekler artıyor	Network darboğaz	Script sayısını azalt + sadece gerekli sayfalarda çalıştır
CPU ve RAM yükseliyor, zamanla artıyor	Sızıntı/yanlış limit	Cron + arkaplan işlerini kontrol et

Sonuç: Aksiyon planı (bugün uygulayabileceğiniz net adımlar)

WordPress eklentileri sunucuyu yavaşlatıyorsa çözüm “tüm eklentileri sil” değildir. Önce hangi noktada tıkandığınızı (TTFB, CPU/RAM, sorgu sayısı, dış istekler) ölçün; sonra staging üzerinde kontrollü eleme yaparak eklentiyi kanıtlayın. Ardından cache çakışmalarını temizleyin, yavaş sorguları hedefleyin ve gerekirse object cache (Redis/Memcached) ile tekrarlı okumaları azaltın.

En hızlı başlangıç için: Cache + minify tarafını tekleştirin, Query Monitor ile en pahalı 5 sorguyu çıkarın ve güncellediğiniz son eklentilerden başlayarak sırayla test edin. Bu adımlardan sonra hâlâ aynı darboğaz varsa, yalnızca eklenti değil PHP-FPM/DB ayarları ve sunucu kapasitesi de net biçimde yeniden değerlendirilmelidir.