WordPress eklentileri sunucuyu yavaşlatıyorsa: Net tespit & çözüm

WordPress siteleri genellikle eklentilerle büyür; ancak her eklenti ek CPU, RAM ve disk kullanımı getirir. Sonuç: sayfa yüklenme süreleri uzar, bazı istekler zaman aşımına uğrar ve sunucuda yük artar. Bu yazıda, "hangi eklenti yavaşlatıyor?" sorusunu ölçümle yanıtlayıp, ardından etkili ve kalıcı optimizasyon adımlarını uygulayacağınız net bir süreç öğreneceksiniz.

1) Yavaşlamanın eklenti kaynaklı olduğuna net şekilde karar verin

Önce “eklentidir” varsayımını ölçümle doğrulayın. Sunucu katmanında (RAM azlığı, disk doluluğu, CPU throttling, I/O bekleme) ya da hosting altyapısında (network throttling, barındırma yoğunluğu) sorun olabilir. Net teşhis için şu sırayı uygulayın.

Hedef metrikler: CPU, RAM, disk I/O ve istek gecikmesi

Sunucu kontrol panelinizden veya sağlayıcı panelinden şu değerleri izleyin: - CPU kullanımı: sürekli yüksekse (ör. %70+ ve dalgalı) eklenti kaynaklı yoğun işlem olabilir. - RAM kullanımı: RAM neredeyse doluysa (ör. %85+) PHP süreçleri swap’a düşer ve performans düşer. - Disk I/O: özellikle log yazma, cache dosyaları oluşturma ve dosya tarama yapan eklentiler I/O’yu artırabilir. - Ağ (network) gecikmesi: bazen eklenti değil, arka uç servis (API, harici görsel optimizasyonu, CDN dolaylı istek) geciktirir.

Ayrıca WordPress tarafında şu testleri yapın: - Sayfayı açtığınızda tarayıcıda “ilk yükleme” mi yoksa “tekrar ziyaret” mi yavaş? - İlk yükleme yavaşsa çoğu zaman cache/optimizasyon eksikliği ve ilk derleme (opcode cache kapalı olabilir) etkiler. - Tekrar ziyaret de yavaşsa tarayıcı önbelleği veya sunucu cache mekanizması zayıf olabilir. - Aynı anda yönetici paneli mi yavaş, yoksa sadece kullanıcı sayfaları mı? - Yönetici tarafı (wp-admin) daha yavaşsa veritabanı arka plan görevleri veya cron eklentileri öne çıkar.

Basit “izolasyon” testi: eklentileri körlemesine değil, kontrollü devre dışı bırakın

Net yöntem, eklentileri tek tek kapatmak yerine gruplar halinde izole etmektir.

1. Uygulama olarak değil, WordPress eklentilerini geçici kapatıp ölçüm yapın.
2. Eklentileri üç gruba ayırın: - Grup A: Cache, minify, görsel optimizasyon (image optimization) - Grup B: Güvenlik, firewall, bot engelleme (ör. rate limit) - Grup C: Sosyal medya, slider, form, analytics, çok amaçlı eklentiler
3. Önce sadece Grup A aktifken yük ve sayfa süresini ölçün.
4. Sonra A+ B aktif, ardından sadece C aktif olacak şekilde ilerleyin.

Bu sayede “hangi kategori” etkili çıkar. Ardından aynı grupta eklentiyi tek tek ele alırsınız.

2) WordPress’te yavaş eklentiyi bulmak için ölçüm aracını doğru seçin

Yavaş eklentiyi “hissetmek” yerine log ve zaman ölçümüyle bulun.

Query Monitor (Query + PHP zaman analizi)

Query Monitor eklentisi, sayfada kaç sorgu çalıştığını, hangi sorguların yavaş olduğunu ve bazı durumlarda PHP tarafındaki zaman dağılımını görmenizi sağlar.

Kritik kontrol listesi: - Aynı sayfada aşırı sayıda veritabanı sorgusu var mı? (ör. yüzlerce query) - “wp_options” ve “wp_postmeta” gibi tablolar yoğun mu? - Admin sayfasında otomatik cron çağrıları çoğalıyor mu?

WP-CLI veya debug log ile süreçleri yakalayın

Sunucu üzerinde hata ayıklama için sağlayıcınızın önerdiği debug yaklaşımını kullanın. Ama hedef debug değil, performans ölçümüdür.

• PHP error/log seviyesini performansı bozmayacak düzeyde tutun.
• Özellikle eklentiye ait log üreten modülleri kontrol edin: bazı eklentiler her istekte dosyaya yazıp I/O’yu artırabilir.

Not: Debug açıkken performans düşebilir. Bu nedenle “kısa süreli ölçüm + kapatma” yapın.

3) En sık suçlular: eklentilerin hangi davranışları sunucuyu yorar?

Eklentiler sunucuyu yavaşlatırken genellikle şu desenleri görürsünüz. Aşağıdaki maddeler, teşhis sürecinizi hızlandırır.

A) Her sayfa yüklemesinde ağır tarama/yeniden üretim

Örnek davranışlar: - Sitemap’i her istekle güncellemek - Görsel optimizasyonunu her sayfa render’da yapmak - Her sayfada “tüm gönderileri” meta ile filtreleyip tekrar hesaplamak

Net kontrol: - Site yavaşladığında hangi dosya yolları ve fonksiyonlar tetikleniyor? - Query Monitor’da aynı sayfada tekrar tekrar çalışan “döngü” sorguları var mı?

B) Veritabanı şişiren eklentiler

Şunlar sorguları artırır: - Her ziyaret için seçenek/metadata kaydı yapan eklentiler - Yanlışlıkla “session benzeri” verileri veritabanına yazan modüller - Uzun vadede temizlenmeyen transient (geçici önbellek) kullanımı

Net çözüm: - Eklentinin “log/istatistik” ayarlarında veri saklama süresini kısaltın. - Transient/option verilerini temizleme seçenekleri varsa düzenli bakım planı kurun.

C) Cron (planlı görev) taşması

WordPress’te cron, ayarlı aralıklarla çalışır; ancak trafiğe bağlı tetiklenir. Bazı eklentiler gerçek zamanlı gibi davranır ve cron kuyruğunu şişir.

Net kontrol: - Yönetici panelinde sistem durum/cron tablosu benzeri ekran var mı? - Sağlayıcı tarafında sistem cron’u ile çakışma var mı? - Görsel optimizasyon veya eklentili “toplu güncelleme” görevleri sürekli yeniden mi çalışıyor?

D) Harici API çağrıları ve üçüncü parti servisler

Bir eklenti her sayfa yüklemesinde harici API çağırıyorsa gecikme doğurur. Bu doğrudan CPU değil, bekleme ile de “worker” süreçlerini meşgul eder.

Net kontrol: - Sunucu tarafında bekleme (latency) artışı var mı? - Ağ istekleri aynı eklentiye ait mi?

4) Sorunlu eklentiye net çözüm: 10 adımda performans toparlama

Aşağıdaki adımlar, eklentinin türüne göre uygulanır; ama tümü “ölç-uygula-geri test et” mantığında çalışır.

1. Eklentiyi “tek noktada” azaltın

Amaç: aynı işi yapan iki eklentiyi kaldırmak. - Cache/minify alanında birden fazla araç çakışır. - Görsel optimizasyonu hem eklenti hem de sunucu (veya CDN) yapıyorsa çift dönüş olur.

2. Eklentinin çalıştığı sayfaları daraltın

Çoğu eklenti “her sayfada” çalışacak şekilde kurulur. Bu ayarı sayfa türüne göre kısın: - Sadece blog yazılarında / sadece ürün sayfalarında - Arama sonuçlarında devre dışı - Üyelik girişlerinde farklı davranış

3. Cache davranışını netleştirin: sayfa cache + object cache

Eğer sunucuda object cache yoksa (APCu/Redis gibi), yoğun DB sorgusu yapan eklentiler tüm yükü artırır.

• Cache eklentisi tek başına her sorunu çözmez; DB yoğunluğunu azaltmak için object cache gerekir.

4. Veritabanı bakımını düzenli yapın

Eklenti “temizlik” sunmuyorsa bile bakım şu başlıklarda olmalı: - transient (geçici) temizliği - spam/comment temizliği - eski revizyonların sınırlandırılması

5. Cron tetikleme stratejisini düzeltin

Eğer cron sürekli taşıyorsa: - Görevleri daha seyrek yapın - Yoğun görevleri (toplu görsel işleme gibi) trafik dışı saatlere alın - Gereksiz cron tetikleyen eklentileri kaldırın

6. Verimli veri saklama seçin

Bazı eklentiler “file-based” yerine “DB-based” çalışır. Sunucuda disk I/O sorunsa dosya yazma yapanlar daha kötü etkiler; RAM sorunsa DB/queue şişebilir.

Net karar: - Sunucuda disk I/O yüksekse dosya tabanlı log/önbellek üreten eklentileri sınırlandırın. - CPU ve DB sorguları yüksekse DB yazma yoğun eklentileri hedefleyin.

7. Minify/combination çakışmasını keskinleştirin

Minify ve script birleştirme: - Çakışırsa hem doğruluk hem performans düşer. - Yeni “tam sayfa cache” ile birlikte bazı eklentiler gereksiz hale gelir.

Net yaklaşım: - Tek bir yerde minify yapın. - Yedekleme/geri alma planıyla A/B test yapın.

8. Görsel optimizasyonu tek katmanda yürütün

En yaygın net hata: eklenti görselleri her sayfa yüklemesinde dönüştürür veya CDN ile çakışır.

Çözüm: - Dönüşümün yalnızca bir kez yapılmasını sağlayın (background işlem veya toplu imaj dönüştürme) - “Yeni görsel” eklendiğinde tetiklenen bir akış kullanın

9. Güvenlik eklentisini doğru modda kullanın

Bazı güvenlik eklentileri her istekte kapsamlı tarama yapar.

Net kontrol: - WAF/rate limit gibi mekanizmaları mümkünse sağlayıcı seviyesinde de kullanın. - WordPress tarafında gereksiz taramaları azaltın.

10. Değişiklikleri sürümlü ilerletin ve ölçün

Her adımı yaptıktan sonra: - 5 dakikalık gerçek trafik benzeri yüklemede test edin. - Sayfa süresi + hata oranı + sunucu CPU/RAM değerini kıyaslayın.

5) Eklenti giderilemeyen durumda: hosting tarafında net ayarlar

Bazı WordPress kurulumlarında eklenti tamamen kaldırılamaz. Bu durumda hosting ayarları fark yaratır.

PHP yürütme kapasitesi: worker ve PHP-FPM

Eğer CPU yükseliyor ve istekler zaman aşımına gidiyorsa şu soruları sorun: - PHP-FPM worker sayısı yeterli mi? - CPU throttling var mı? - RAM artışı gerekli mi?

Net karar rehberi: - İstek sayısı yüksek, CPU sürekli yüksekse: önce eklenti ve cache’i düzeltin; sonra ölçeklendirin. - CPU değil de RAM sorunsa: object cache + uygun PHP ayarları + bellek optimizasyonu gündeme gelir.

Disk ve log yönetimi

Eklentiler log dosyalarına yazıyorsa disk I/O ve disk doluluk sorun olur.

Net kontrol: - Log döndürme (log rotation) var mı? - Eklentinin log seviyesi ve saklama süresi nedir?

Cache katmanları: sayfa cache, CDN, object cache

“Her şeyi eklentiyle çözme” yerine katmanları netleştirin: - CDN: statik dosyaları (CSS/JS/imaj) hızlı sunar - Sayfa cache: istekleri WordPress render’dan çıkarır - Object cache: DB yükünü azaltır

Aşağıdaki tablo, hangi sorunda hangi katmanın daha etkili olduğunu netleştirir.

Sonuç: Aksiyon planı ile net ilerleyin

Eklenti kaynaklı yavaşlamada en iyi yaklaşım “tahmin” değil “ölçüm + izolasyon”dur. Önce sunucu metrikleriyle sorunun büyüklüğünü görün, sonra Query Monitor ve eklenti gruplama testiyle tetikleyiciyi bulun. Bulduğunuzda tek bir amaç hedefleyin: cache katmanını netleştirmek, cron taşmasını durdurmak ve aynı işi yapan eklentileri kesmek. Değişiklikleri her adımda ölçerek ilerleyin; 1-2 gün içinde hem CPU/RAM dalgasını hem de sayfa sürelerini belirgin şekilde düşürmeniz beklenir.

İsterseniz bir sonraki adım olarak, kullandığınız eklentilerin listesini ve sunucu panelinizde son 30 dakikadaki CPU/RAM değerlerini paylaşın; hangi eklentilerin en yüksek risk taşıdığına dair net bir öncelik sıralaması çıkarabilirim.