Çok Fazla WordPress Eklentisi Sitenizi Nasıl Etkiler

Yazar:komut.io ekibi Rehber & İpuçları
0 Yorum

Kaç yıldır WordPress sitelerinin performans sorunlarına bakıyorum ve neredeyse her seferinde aynı manzarayla karşılaşıyorum: eklenti listesi açılıyor, 40-50 aktif eklenti sıralanıyor. Bazen 70-80’e kadar çıkanını da gördüm. Site yavaş mı? “Hosting sorunudur” deniyor. Sayfa yüklenmiyor mu? “Cache ayarlanmalı” deniyor. Oysa sorun çoğu zaman çok daha basit, ama aynı zamanda çok daha derin.

Eklenti Yükü Nedir, Neden Önemlidir

WordPress her eklenti yüklendiğinde, o eklentinin PHP dosyaları hafızaya alınır, veritabanı sorguları çalışır, JavaScript ve CSS dosyaları kuyruğa eklenir. Tek bir eklenti için bu maliyet kabul edilebilir. Ama 50 eklentide bu maliyetin 50 katına çıktığını düşünüyorsanız yanılıyorsunuz; bazı durumlarda üssel bir büyüme söz konusu çünkü eklentiler birbirleriyle etkileşime giriyor, aynı kütüphaneleri farklı versiyonlarda yüklemeye çalışıyor ve birbirlerinin hook’larını tetikliyor.

Sunucu tarafında bunu somutlaştıralım. Bir WordPress sayfası yüklenirken PHP süreci başlatılır, WordPress çekirdeği yüklenir, ardından aktif eklentiler sırayla dahil edilir. Bunu ölçmek için en basit yöntem wp-config.php içine SAVEQUERIES sabitini açmaktır:

# wp-config.php'ye eklenecek satırlar (sadece geliştirme ortamında!)
define('SAVEQUERIES', true);
define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);

Ardından temanızın footer.php dosyasına şu kodu ekleyerek aktif sorgu sayısını görebilirsiniz:

# Veritabanı sorgu sayısını terminal üzerinden WP-CLI ile kontrol etmek için:
wp db query "SELECT COUNT(*) FROM wp_options WHERE autoload = 'yes';" --allow-root

Bu sorgunun döndürdüğü değer 800’ün üzerindeyse, sitenizin her yüklenişinde ciddi bir otomatik yükleme yükü var demektir.

PHP Bellek Kullanımı ve Yürütme Süresi

Her eklenti PHP belleği tüketir. Bazıları 2-3 MB yerken, kötü yazılmış ya da aşırı işlevli eklentiler 20-30 MB tüketebilir. Bunu ölçmek için şu yöntemi kullanıyorum:

# memory_limit ve max_execution_time değerlerini görmek için
php -r "echo ini_get('memory_limit') . PHP_EOL;"
php -r "echo ini_get('max_execution_time') . PHP_EOL;"

# PHP bilgi dosyası oluşturmadan CLI üzerinden kontrol:
php -r "phpinfo();" | grep -E "memory_limit|max_execution_time|post_max_size"

Benim müdahale ettiğim bir e-ticaret sitesinde, 42 aktif eklentisiyle PHP bellek limiti 512 MB’a çekilmişti. Hosting sağlayıcısı “yeterli kaynak” verdiğini söylüyordu, ama aslında sorun kaynak yetersizliği değil, kaynağın verimsiz kullanımıydı. Limit düşürüldüğünde hata alındığı için limit sürekli artırılmıştı. Bu kısır döngünün ta kendisi.

Gerçek kullanılan belleği ölçmek için WP-CLI’nin profile uzantısını kullanabilirsiniz:

# WP-CLI profile eklentisini kurun
wp package install wp-cli/profile-command --allow-root

# Sayfa yüklemesini profil olarak inceleyin
wp profile stage --all --spotlight --allow-root

# Eklenti bazlı yavaşlama tespiti
wp profile hook --all --spotlight --allow-root

Bu komutlar size hangi eklentinin ne kadar süre harcadığını ve kaç sorgu çalıştırdığını gösterir. Rakamları gördüğünüzde bazı eklentilerin ne kadar yer kapladığına inanamayabilirsiniz.

Veritabanı Şişmesi: Sessiz Katil

Eklentiler veritabanına veri yazar. Bu normalde beklenen bir şeydir. Ama bazı eklentiler silerken veya devre dışı bırakılırken kendi verilerini temizlemez. Yıllarca biriken bu veriler wp_options tablosunu şişirir ve her yüklenişte bu tablo taranır.

# wp_options tablosunun boyutunu kontrol edin
wp db query "SELECT SUM(LENGTH(option_value)) / 1024 / 1024 AS size_mb FROM wp_options;" --allow-root

# En büyük autoload verilerini listeleyin
wp db query "SELECT option_name, LENGTH(option_value) as size FROM wp_options WHERE autoload='yes' ORDER BY size DESC LIMIT 20;" --allow-root

# Geçici (transient) verilerin boyutu
wp db query "SELECT COUNT(*) as count, SUM(LENGTH(option_value))/1024/1024 as size_mb FROM wp_options WHERE option_name LIKE '%_transient_%';" --allow-root

Geçmişte bir haber sitesinde wp_options tablosunun 200 MB’ı aştığını gördüm. Bunun 150 MB’ı kaldırılmış eklentilerin bıraktığı kalıntı verilerdi. Bu tablo temizlendiğinde sayfa yükleme süresi neredeyse yarıya düştü.

Tablo büyüklüğünü daha kapsamlı incelemek için:

# Tüm WordPress tablolarının boyutlarını görün
wp db query "SELECT table_name, ROUND(((data_length + index_length) / 1024 / 1024), 2) AS size_mb FROM information_schema.TABLES WHERE table_schema = DATABASE() ORDER BY size_mb DESC;" --allow-root

# wp_postmeta şişmesini kontrol edin (fazla eklenti bu tabloyu da şişirir)
wp db query "SELECT COUNT(*) FROM wp_postmeta;" --allow-root

JavaScript ve CSS Yükü: Frontend Cephesi

Sunucu tarafı temizlendikten sonra iş frontend’e geliyor. Her eklenti kendi JavaScript ve CSS dosyalarını yükler. Bazıları bunu her sayfada yapar, bazıları sadece ilgili sayfalarda. Ama çoğu zaman ilgisiz sayfalara da yüklendiğini görürsünüz.

Bunu test etmek için şu bash scriptini kullanabilirsiniz:

#!/bin/bash
# Yüklenen script ve style sayısını kontrol etmek için sayfa kaynağını analiz edin
URL="https://example.com"
RESPONSE=$(curl -s "$URL")

JS_COUNT=$(echo "$RESPONSE" | grep -o '<script' | wc -l)
CSS_COUNT=$(echo "$RESPONSE" | grep -o '<link.*stylesheet' | wc -l)

echo "JavaScript dosyası sayısı: $JS_COUNT"
echo "CSS dosyası sayısı: $CSS_COUNT"
echo "---"
echo "Toplam istek potansiyeli: $((JS_COUNT + CSS_COUNT))"

# Sayfa boyutunu da görelim
PAGE_SIZE=$(echo "$RESPONSE" | wc -c)
echo "Sayfa boyutu (bayt): $PAGE_SIZE"
echo "Sayfa boyutu (KB): $((PAGE_SIZE / 1024))"

Ortalama bir WordPress sitesinde 20-25 JS ve CSS dosyası normal kabul edilebilir. 50’nin üzerine çıktığında, her biri için ayrı bir HTTP isteği yapılacağını ve bu isteklerin sıralı ya da yarı-sıralı şekilde işleneceğini unutmayın.

Güvenlik Yüzeyinin Genişlemesi

Bu konuyu teknik performanstan bağımsız düşünmemek gerekiyor. Her eklenti potansiyel bir saldırı vektörüdür. WPScan veya benzeri araçlar sitenizi tararken eklenti versiyonlarını kontrol eder ve bilinen zafiyetleri listeler.

# WPScan ile eklenti zafiyet taraması (API token gerektirir)
wpscan --url https://example.com --enumerate p --plugins-detection aggressive --api-token YOUR_TOKEN

# Güncel olmayan eklentileri WP-CLI ile listeleyin
wp plugin list --update=available --format=table --allow-root

# Aktif olmayan eklentileri tespit edin (saldırı yüzeyi azaltma)
wp plugin list --status=inactive --format=table --allow-root

Aktif olmayan ama silinmemiş eklentiler özellikle tehlikelidir. Güncellenmezler çünkü “zaten kullanılmıyor” diye düşünülür. Ama dosya sistemi üzerinde dururlar ve bir güvenlik açığı varsa istismar edilebilirler. Bu yüzden kullanılmayan her eklentiyi silmek, sadece devre dışı bırakmaktan çok daha doğrudur.

Çakışmalar ve Hata Ayıklama

İki eklentinin aynı JavaScript kütüphanesinin farklı versiyonlarını yüklemeye çalışması, sadece performans değil, işlevsellik sorunu da yaratır. jQuery çakışmaları bu kategorinin en bilinen örneğidir.

# WordPress hata günlüğünü gerçek zamanlı izleyin
tail -f /var/log/nginx/error.log | grep -i "wordpress|php"
tail -f /var/www/html/wp-content/debug.log

# PHP hata logunu filtreleyin
grep -E "Fatal error|Warning|Notice" /var/log/php/error.log | tail -50

# Belirli bir eklentiye ait hataları tespit edin
grep "plugins/ucretsiz-eklenti-adi" /var/www/html/wp-content/debug.log | tail -20

Gerçek bir senaryodan bahsedeyim: Bir müşterinin sitesinde iki farklı form eklentisi vardı. İkisi de kendi reCAPTCHA kütüphanesini yüklüyordu. Sonuç? Formlar çalışmıyordu, ama neden çalışmadığını anlamak 2 saat sürdü. Çünkü hata konsola düşüyordu, ama müşteri “her şey düzgün görünüyor sadece form gönderilmiyor” diyordu. Debug log açık olsaydı 10 dakika sürerdi.

Eklenti Denetimi Nasıl Yapılır

Sistematik bir eklenti denetimi için şu adımları izliyorum:

Envanteri çıkarın:

# Tüm eklentileri JSON formatında listeleyin
wp plugin list --format=json --allow-root | python3 -m json.tool

# Sadece aktif eklentileri, yazar bilgisiyle birlikte listeleyin
wp plugin list --status=active --fields=name,version,update,author --format=table --allow-root

# Her eklentinin son güncelleme tarihini kontrol edin
wp plugin list --format=json --allow-root | python3 -c "
import json, sys
plugins = json.load(sys.stdin)
for p in plugins:
    print(f"{p['name']}: {p['status']} - Güncelleme: {p.get('update', 'bilinmiyor')}")
"

Bu envanteri aldıktan sonra her eklenti için şu soruları soruyorum:

  • Bu eklenti aktif olarak kullanılıyor mu? Sadece kurulu değil, gerçekten işe yarıyor mu?
  • Başka bir eklenti aynı işi yapıyor mu? Çakışan işlevler mi var?
  • Bu işlevi tema veya az satır kodla yapabilir miyim? Basit bir kısayol menüsü için 5 MB’lık eklentiye gerek var mı?
  • Eklenti ne kadar süredir güncellenmedi? 2 yılı aşmışsa tehlike sinyali.
  • Kaç aktif kurulumu var ve yorumları nasıl? Topluluk güveni önemli.

Performans Ölçümü ve Karşılaştırma

Eklenti temizliği öncesi ve sonrası farkı somutlaştırmak için ölçüm şart. Sezgiyle hareket etmek yetmez.

#!/bin/bash
# Basit bir yükleme süresi ölçüm scripti
URL="https://example.com"
ITERATIONS=5
TOTAL=0

echo "Sayfa yükleme süresi ölçümü ($ITERATIONS iterasyon):"
echo "URL: $URL"
echo "---"

for i in $(seq 1 $ITERATIONS); do
    TIME=$(curl -o /dev/null -s -w "%{time_total}" "$URL")
    echo "İterasyon $i: ${TIME}s"
    TOTAL=$(echo "$TOTAL + $TIME" | bc)
done

AVERAGE=$(echo "scale=3; $TOTAL / $ITERATIONS" | bc)
echo "---"
echo "Ortalama yükleme süresi: ${AVERAGE}s"

Bu scripti eklenti temizliği öncesi çalıştırın, sonuçları kaydedin. Temizlik sonrası tekrar çalıştırın. Fark genellikle ilk ölçümden çok daha büyük çıkar.

Daha kapsamlı ölçüm için ab (Apache Benchmark) veya wrk kullanabilirsiniz:

# Apache Benchmark ile yük testi
ab -n 100 -c 10 https://example.com/ | grep -E "Requests per second|Time per request|Failed"

# wrk ile daha gelişmiş test
wrk -t4 -c50 -d30s https://example.com/

Makul Eklenti Sayısı Ne Kadardır

Bu sorunun kesin bir yanıtı yok, ama deneyimlerime dayanarak şunu söyleyebilirim: iyi optimize edilmiş bir WordPress sitesi 15-20 eklentiyle çok şeyi başarabilir. SEO için bir tane, güvenlik için bir tane, cache için bir tane, form için bir tane… Bunlar gibi temel kategorilerde birer eklenti, bazı özel işlevler için birkaç tane daha.

Ama asıl önemli olan sayı değil, kalite ve gereklilik. 10 eklentiyle yavaş bir site olabilir, 30 eklentiyle hızlı bir site de. Sorun salt sayıda değil, kötü yazılmış, gereksiz ve bakımsız eklentilerin birikiminde.

Şu tür eklentilerden özellikle kaçının:

  • Her sayfada JavaScript yükleyen ama sadece bir sayfada kullanılan eklentiler
  • Son 18 ayda güncellenmemiş eklentiler
  • Mevcut WordPress versiyonuyla uyumluluğu test edilmemiş eklentiler
  • Ücretsiz sürümde yoktan var eden ama asıl işlevi premium’a kilitleyen eklentiler (bu tür eklentiler genellikle tracking kodu da çalıştırır)
  • Her biri kendi jQuery versiyonunu yükleyen birden fazla slider/carousel eklentisi

Staging Ortamında Test Etme

Hiçbir zaman production ortamında eklenti silerken test etmeyin. Bir staging ortamı kurun, temizliği orada yapın, sonuçları ölçün, ardından production’a geçin.

# WP-CLI ile staging ortamına geçerken veritabanını kopyalamak
wp db export /tmp/backup_$(date +%Y%m%d).sql --allow-root

# Tüm eklentileri devre dışı bırakarak (toplu test için)
wp plugin deactivate --all --allow-root

# Tek tek aktifleştirerek sorunu izole edin
wp plugin activate eklenti-adi --allow-root

# Eklentiyi tamamen silmek için (dikkatli kullanın)
wp plugin delete eklenti-adi --allow-root

Staging ortamı yoksa en azından tam bir yedek alın. Bu hem veritabanı hem de dosya sistemi yedeğini kapsamalı:

# Tam yedek scripti
#!/bin/bash
BACKUP_DIR="/backup/wordpress"
DATE=$(date +%Y%m%d_%H%M%S)
WP_DIR="/var/www/html"

mkdir -p "$BACKUP_DIR"

# Veritabanı yedeği
wp db export "$BACKUP_DIR/db_$DATE.sql" --path="$WP_DIR" --allow-root

# Dosya sistemi yedeği (wp-content)
tar -czf "$BACKUP_DIR/files_$DATE.tar.gz" "$WP_DIR/wp-content"

echo "Yedek tamamlandı: $BACKUP_DIR"
ls -lh "$BACKUP_DIR"

Sonuç

WordPress eklentileri güçlü bir araçtır ve bu gücü küçümsemiyorum. Ama güç, sorumluluk gerektirir. Her eklenti kurulumu bir maliyet kararıdır; performans maliyeti, güvenlik maliyeti, bakım maliyeti. Bu maliyeti bilinçli olarak ödüyorsanız sorun yok. Ama çoğu zaman bu kararlar farkındasız alınıyor ve yıllar içinde birikim oluyor.

Periyodik eklenti denetimleri, yani üç ya da altı ayda bir yukarıdaki adımları sistematik şekilde uygulamak, hem performans hem güvenlik açısından en etkili önlemlerden biridir. WP-CLI komutlarını bir script haline getirin, cron’a ekleyin, raporları mail olarak alın. Otomasyona taşıdığınızda bu işin sizi fazla zamanınızı almadığını göreceksiniz.

En iyi eklenti, işini yapan ve arkasında iz bırakmayan eklentidir. Bunu sağlayamıyorsanız, o işi kod düzeyinde çözmeyi düşünün. Birkaç satır PHP, bakımı zor bir eklentiden her zaman daha temizdir.

Bir yanıt yazın

E-posta adresiniz yayınlanmayacak. Gerekli alanlar * ile işaretlenmişlerdir