WordPress Admin Yavaş mı? Yönetici Panelini Hızlandırma Rehberi

Ön yüzünüz 1,2 saniyede açılıyor. WordPress yönetici paneliniz ise 6 saniyeyi buluyor. wp-admin içindeki her tıklama çevirmeli internet hızında.

Sorun sunucunuz değil. Sorun, her istekte wp-admin içinde çalışan şeyler.

WordPress Yönetici Paneliniz Neden Yavaş?

WordPress admin yavaş çalışıyorsa ama ön yüz hızlıysa, bu bir yanılsama değildir. Yavaş yönetici paneli, siteyi optimize ettikten sonra karşılaşılan en yaygın şikayettir.

Önbellek eklentileri wp-admin’i atlar. CDN yönetici paneline dokunmaz. Her tıklama taze bir PHP isteği çalıştırır ve tüm autoload verinizi wp_options tablosundan çeker.

Tekrarlayan senaryo: Ön yüz 1,2 saniyede yüklenir, panel 6 saniyeyi bulur. Hosting yükseltirsiniz, bir hafta düzelir, sonra yine yavaşlar.

Önbellek yardım etmez çünkü admin sayfalarını kasıtlı olarak atlar. CDN de yardım etmez çünkü panel dinamiktir. Yavaşlık doğrudan WordPress’in içinden gelir.

Doğru Ama Sorunu Bulmayan Tavsiyeler

Sık verilen mantıklı tavsiyeler şunlardır:

• “PHP sürümünü yükselt”
• “Daha iyi hosting’e geç”
• “Önbellek eklentisi kur”
• “Kullanmadığın eklentileri kapat”
• “Bellek limitini artır”

Bunların size söyleyemediği şeyler ise şunlardır:

• Bir eklentinin admin_init fonksiyonu 800 ms sürüyor
• Heartbeat API editörde her 15 saniyede bir tetikleniyor
• admin-ajax.php sayfa başına birden fazla isteği sıraya alıyor
• Her istekte 2 MB autoload verisi yükleniyor
• Her admin sayfasında yavaş bir sorgu çalışıyor

Bu adımların hepsi faydalıdır. Ancak hiçbiri 4 saniyeyi hangi fonksiyonun yediğini söylemez. “Eklentileri kapat” değil; hangi eklenti, hangi hook ve hangi fonksiyon sorusunun cevabına ihtiyacınız var.

Belirtinize Göre Nedeni Bulun

“WordPress admin yavaş” tek bir sorun değildir. Panelden aynı hissedilen beş altı farklı sorundur. Aşağıdan kendi belirtinizi bulun.

Adım 0: Zamanlamadan Önce Tüm Siteyi Tarayın

Aşağıdaki her adım tek bir şeyi ölçer. Bunu elle yapmadan önce bütünsel bir tarama yapın. İyi bir tarama; OPcache, nesne önbelleği, Redis sağlığı, önbellek kontrolü ve veritabanı şişkinliğini tek geçişte inceler.

Henüz eklenti kurmadıysanız, dışarıdan bir TTFB testi sunucunun yavaş olup olmadığını gösterir. Bu test sunucu tarafı kontrolleri yapmaz. O yüzden dış ölçümü aldıktan sonra derin taramaya geçin.

Tarama ne zaman yanlış ilk adımdır: Tek bir isteği hata ayıklıyorsanız onu doğrudan Query Monitor ile açın. Amaç ön yüzü hızlandırmaksa bu bir önbellek işidir, teşhis değil.

wp-admin’i Hızlandırma: 15 Dakikalık Kontrol Listesi

Burada teori yok. DevTools, veritabanı erişimi ve 15 dakikanız yeterli. Her adım bir başarı eşiğiyle biter, böylece ne zaman duracağınızı bilirsiniz.

1. 0–2. dakika: Heartbeat sayımı. DevTools Network sekmesinde “admin-ajax” filtrele. 60 saniye bekle ve action=heartbeat içeren istekleri say. Dakikada birden fazlaysa 2. adıma geç.
2. 2–4. dakika: Heartbeat’i 120 saniyeye çek. Aşağıdaki heartbeat_settings filtresini ekle. Sayımı tekrarla. Başarı: tikler yaklaşık 2 dakikada bire düşer.
3. 4–6. dakika: Panel ile düz ekranı karşılaştır. /wp-admin/ ve Ayarlar → Genel yükleme sürelerini karşılaştır. Panel 2 saniye daha yavaşsa sorun widget’lardadır.
4. 6–9. dakika: Autoload boyutunu ölç. Aşağıdaki SQL sorgusunu çalıştır. Başarısızlık: 800 KB üstü. En büyük kaynakları önce düzelt.
5. 9–12. dakika: Nesne önbelleği testi. Redis veya Memcached varsa aç-kapat yaparak aynı sayfayı üçer kez yükle. İlk yüklemeyi at, ısınmış medyanları karşılaştır.
6. 12–15. dakika: admin_init çağrılarını sırala. Bu hook’ta ne çalıştığını ölç. 200 ms üstü tek bir çağrı hedefinizdir; onu düzeltin veya değiştirin.

WordPress Panel Yavaş, Diğer Sayfalar Normal mi?

“Yavaş panel” ve “yavaş wp-admin” birbirinin yerine kullanılır. Ama bunlar iki farklı sorundur. Panel ana ekranı (/wp-admin/index.php), başka hiçbir ekranın çalıştırmadığı işleri çalıştırır.

Sadece panel ana ekranı yavaşsa neden şunlardır:

• Her widget yüklemede kendi sorgularını çalıştırır
• Etkinlik & Haber widget’ı uzak bir WordPress.org akışı çeker
• Eklenti widget’ları sadece kutu göstermek için satıcı API’sini çağırır
• “Bir Bakışta” kutusu büyük tablolardaki satırları sayar

Her wp-admin ekranı yavaşsa neden şunlardır:

• Autoload wp_options verisi her istekte yüklenir
• admin_init çağrıları her ekranda çalışır
• Lisans kontrolleri dış HTTP ile sayfayı bloklar
• Heartbeat ve admin-ajax trafiği PHP işçilerini doldurur

Test bir dakika sürer. /wp-admin/ ve Ayarlar → Genel sürelerini karşılaştırın. Panel 2+ saniye daha yavaşsa suçlu widget’lardır. İkisi de yavaşsa sorun autoload boyutu ve admin_init çağrılarıdır.

Yavaş WordPress Admin Performansının 4 Gerçek Nedeni

1. admin-ajax.php Darboğazı

WordPress tüm AJAX isteklerini tek dosyadan geçirir: admin-ajax.php. Her istek tüm WordPress yığınını baştan başlatır. Panelde 5 eklenti AJAX çağrısı yaparsa, bu sayfa başına 5 ekstra tam başlatma demektir.

# Tarayıcıda admin-ajax trafiğini kontrol edin:
# DevTools → Network → "admin-ajax" filtresi
# Tek sayfa yüklemesinde kaç istek tetikleniyor bakın

2. Heartbeat API Yükü

WordPress Heartbeat, otomatik kayıt ve bildirim için her 15–60 saniyede bir AJAX isteği gönderir. Her istek tüm WordPress yığınını yükler. Paylaşımlı hosting’de bu tek başına PHP işçilerinizi doldurabilir.

// Heartbeat'i yavaşlatarak yükü azaltın:
add_filter('heartbeat_settings', function($settings) {
    $settings['interval'] = 120; // saniye (varsayılan: 15-60)
    return $settings;
});

3. admin_init Üzerindeki Yavaş Eklenti Çağrıları

Eklentiler admin_init, admin_menu ve admin_enqueue_scripts hook’larına bağlanır. Bunlar sadece kendi ayar sayfalarında değil, her admin sayfasında çalışır. Kötü yazılmış tek bir çağrı her isteğe 500 ms ekleyebilir.

4. Autoload Şişkinliği

Ön yüzü etkileyen aynı wp_options autoload sorgusu her admin sayfasında da çalışır. Ama admin sayfaları asla önbelleğe alınmaz. Bu yüzden tam maliyeti her seferinde hissedersiniz.

Genellikle WordPress Admin’i Yavaşlatan Eklenti Türleri

İsim listesi vermeyeceğim çünkü sürümler değişir ve her liste yayınlandığı gün eskir. Ancak mekanizmalar değişmez. Şu beş sınıf, gördüğüm yavaş panellerin çoğuna neden olur.

Hangi sınıfla uğraştığınızı doğrulamak için: Query Monitor’ün HTTP paneli lisans ve yoklama sınıflarını yakalar. DevTools varlık ve widget sınıflarını yakalar. admin_init üzerindeki çağrı zamanlaması ise tarayıcı sınıfını yakalar.

Nasıl Teşhis Edilir?

1. Herhangi bir admin sayfasında DevTools’u aç. Network sekmesine git. Sayfa yükleme süresini not et, sonra admin-ajax isteklerini say. 5+ çağrı, 5 tam başlatma demektir.
2. Hook çağrılarını profille. SAVEQUERIES sadece sorguları kaydeder, PHP süresini değil. admin_init‘te çalışan fonksiyonları ölçmek için bir profilleyici kullan.
3. Eklentileri tek tek kapat. Her kapatmadan sonra yükleme süresini ölç. Hızlandığında suçluyu buldun. Bu yöntem yorucu ama kesindir.
4. Sorgu sayısını kontrol et. Sağlıklı bir admin sayfası 50–100 sorgu çalıştırır. 300+ görüyorsan eklentiler gereksiz sorgu ekliyor demektir.
5. Heartbeat sıklığını izle. Network’te 60 saniye izle ve action=heartbeat isteklerini say. Az heartbeat ama çok admin-ajax varsa sorun eklentilerdir.

Query Monitor Sorguları Gösterir, Çağrı Zamanlaması Fonksiyonları

Query Monitor doğru ilk adımdır. “Queries by Component” paneli eklenti başına sorgu ve HTTP çağrılarını gösterir. Ama sorgu sayısı normalken WordPress admin yavaş kalıyorsa, darboğaz genellikle admin_init üzerindeki PHP süresidir. Bu, Query Monitor’ün ölçtüğü bir şey değildir.

Çözüm, her kayıtlı çağrıyı milisaniye bazında sıralayan bir çağrı zamanlayıcıdır. Böylece “hangi eklentiyi kapatsam” diye tahmin etmek yerine tam fonksiyonu görürsünüz.

Nedeni Bulunca Hızlı Kazançlar

Heartbeat Sıklığını Azaltın

Heartbeat’i 15 saniyeden 120 saniyeye çekmek arka plan admin-ajax isteklerini %87 azaltır. Çoğu site işlevsellikte fark hissetmez.

Panel Widget’larını Kapatın

Her widget yüklemede kendi sorgularını çalıştırır. Günlük kontrol etmediğiniz eklentilerin widget’larını kaldırın:

add_action('wp_dashboard_setup', function() {
    remove_meta_box('dashboard_quick_press', 'dashboard', 'side');
    remove_meta_box('dashboard_primary', 'dashboard', 'side');
    // Dış API çağrısı yapan eklenti widget'larını kaldırın
});

Nesne Önbelleği Ekleyin

Redis veya Memcached admin performansını artırır. Çünkü admin sayfaları sorgu yoğundur ve asla önbelleğe alınmaz. Her sayfada çalışan veritabanı aramaları bellekten sunulur.

Rakamlarla özet:

• %87 daha az arka plan isteği (editör sekmeleri, 15 sn → 120 sn)
• 300+ → 50 ısınmış nesne önbelleğinde bellekten sunulan sorgu
• 300+ şişkin admin sayfalarındaki sorgu sayısı

wp-admin Zamanla Neden Yavaşlar?

Admin yavaşlığı genellikle tek bir büyük sorun değildir. Tek bir kötü eklenti yoktur. Bu, şu birikimin sonucudur:

1. 15 eklentinin her biri admin_init‘e 50 ms ekler = 750 ms taban maliyet
2. Widget’lar her yüklemede dış API çağrısı yapar
3. AJAX işleyicileri basit işler için tam WordPress başlatır
4. Autoload verisi eklenti değişimiyle her ay büyür

Göremediğinizi düzeltemezsiniz. Her fonksiyonun tam süresini bilmeniz gerekir, sadece hangi eklentinin yavaş olduğunu değil.

Yönetilen Hosting’te Autoload Verisi (WP Engine, Flywheel)

WP Engine veya Flywheel kullanıyorsanız ve WordPress admin yavaş çalışıyorsa, önce autoload verinizi kontrol edin. WP Engine, toplam autoload seçeneklerini 800 KB altında tutmayı önerir. Üstünde, her istek aşırı büyük bir set yükler.

1 MB tuzağı: Memcached tabanlı hostlarda, ~1 MB üstü autoload şişkinliği aralıklı 502 hatalarına yol açar. Anahtar başına limit 1 MB olduğu için blob sessizce önbelleğe alınamaz.

Autoload boyutunuzu tek sorguyla denetleyin:

-- Toplam autoload verisi (hedef: 800 KB altı)
SELECT ROUND(SUM(LENGTH(option_value)) / 1024, 1) AS autoload_kb
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on');-- En büyük 20 autoload seçeneği
SELECT option_name, ROUND(LENGTH(option_value) / 1024, 1) AS kb
FROM wp_options
WHERE autoload IN ('yes','on','auto','auto-on')
ORDER BY LENGTH(option_value) DESC
LIMIT 20;

Yaygın suçlular: eski transient’ler, eklenti güncelleme önbellekleri ve sayfa oluşturuculardan gelen büyük seçenek blobları. Güvenli çözüm, satırları toplu silmek değil, tek tek autoload’dan çıkarmaktır: wp option set-autoload OPTION_NAME off.

Autoload zaten 800 KB altındaysa ve panel hâlâ yavaşsa, darboğaz hook çağrılarına kaymıştır.

Öncesi ve Sonrası: “Düzeldi” Neye Benzer?

Uydurma müşteri rakamları göstermeyeceğim. Ölçmediğiniz bir öncesi/sonrası kurgudur. Verebileceğim şey, hiçbir şeye dokunmadan önce doldurduğum ölçüm tablosudur.

Önce doldurun, tek seferde tek şey değiştirin, her değişiklikten sonra yeniden ölçün. “Öncesi” sütunu olmadan hangi düzeltmenin işe yaradığını asla bilemezsiniz.

İki kural rakamları dürüst tutar. Aynı sayfa, aynı tarayıcı, aynı saatte ölçün. Ve ölçümler arasında tek şey değiştirin, yoksa gelişmeyi hiçbir şeye bağlayamazsınız.

WordPress Yavaş Admin SSS