WordPress Yönetim Paneli Neden Yavaş? wp-admin Teşhis Rehberi

Ziyaretçi tarafı hızlıyken wp-admin yavaşsa, ön yüzü büyük olasılıkla sayfa önbelleği taşıyordur. Yönetim paneline önbellek uygulanmaz ve her ekran WordPress'i baştan çalıştırır, yani panel sitenin önbelleksiz gerçek hızını gösterir. En sık bulunan nedenler şunlar: yanıt vermeyen bir sunucuyu bekleyen güncelleme ya da lisans denetimi, şişmiş autoload seçenekleri, dış servisten veri çeken gösterge paneli bileşenleri, sık tetiklenen Heartbeat ve wp-cron istekleri, ağır liste ekranları ve eski PHP. Önce tarayıcıda hangi ekranın ne kadar sürdüğünü ölçün, sonra nedenleri birer birer eleyin.

Ön yüz hızlı, panel yavaş: bu tablo ne anlatıyor?

Ana sayfanız 200 milisaniyede açılıyor ama Yazılar ekranı dört saniye sürüyor. İlk akla gelen "sunucu yavaş" olur, oysa iki sayfayı aynı sunucu üretiyor. Fark, ön yüzde ziyaretçiye çoğunlukla önbelleğe alınmış hazır HTML'in gitmesinden kaynaklanır. Bunu yanıt başlıklarındaki HIT ve MISS değerlerinden kolayca doğrulayabilirsiniz. Yönetim panelinde ise oturum açmış kullanıcıya özel içerik üretildiği için hiçbir sayfa önbelleği devreye girmez. Her tıklamada PHP çalışır, eklentiler yüklenir, veritabanı sorgulanır.

Üstelik panel ön yüzden daha fazla iş yapar. admin_init kancasına bağlanan her eklenti kodu, güncelleme denetimleri, bildirim kutuları ve ekran başına yüklenen betikler yalnız burada çalışır. Ön yüzün genel yavaşlık nedenlerini WordPress sitesinin neden yavaş açıldığını ölçerek ayırma rehberinde topladık. Bu yazı yalnız panelin kendine özgü yüküyle ilgileniyor.

Önce ölçün: hangi ekran, ne kadar?

"Panel yavaş" çok geniş bir şikâyet. Teşhisin ilk adımı onu ekran ekran sayıya çevirmektir. Chrome ya da Firefox'ta geliştirici araçlarını açın, Network sekmesine geçin ve şu ekranları sırayla açın: Başlangıç (Dashboard), Yazılar, Eklentiler, sitenizde varsa Ürünler ve Siparişler. Her birinde listenin en üstündeki belge isteğini seçin ve Timing sekmesindeki Waiting (TTFB) değerini not edin. Bu süre, sunucunun sayfayı üretmeye harcadığı zamandır. Her ekranı iki üç kez açın, ilk ölçümü saymayın.

WordPress'in kendi aracı da işe yarar. Araçlar → Site sağlığı ekranı birkaç testi doğrudan panelle ilgili olarak çalıştırır: WordPress.org ile iletişim kurulabiliyor mu, HTTP istekleri engelleniyor mu, site kendine geri döngü (loopback) isteği atabiliyor mu ve WordPress 6.6'dan bu yana otomatik yüklenen seçeneklerin toplam boyutu ne durumda. Burada çıkan kırmızı ya da turuncu bir uyarı, aşağıdaki başlıklardan hangisiyle başlayacağınızı söyler.

Ekran bazında hangi eklentinin ve hangi sorgunun süre harcadığını görmek için Query Monitor'ün bileşen bazında sorgu ve HTTP çağrısı panellerini kullanın. Query Monitor yönetim ekranlarında da çalışır ve aşağıdaki nedenlerin çoğunu doğrudan gösterir.

Ölçümlerin deseni nedeni büyük ölçüde daraltır:

Yanıt vermeyen bir sunucuyu beklemek

Panel yavaşlığında en sinsi neden, WordPress'in ya da bir eklentinin dışarıdaki bir sunucudan cevap beklemesidir. Hiçbir hata mesajı çıkmaz, sayfa yalnızca birkaç saniye geç gelir.

WordPress'in eklenti güncelleme denetimi iyi bir örnek. Çekirdek kaynak koduna göre bu istek panelden yapıldığında zaman aşımı 3 saniye artı her on eklenti için 1 saniyedir. Eklentiler ekranında son denetimin üzerinden bir saat geçmişse, diğer yönetim ekranlarında 12 saat geçmişse istek yeniden atılır. Varsayımsal olarak kırk eklentili bir sitede sunucunun dışarıya çıkan bağlantıları yanıtsız kalıp zaman aşımına düşüyorsa, Eklentiler ekranı saatte bir kez yedi saniye kadar fazladan bekler. Tema ve çekirdek denetimleri de benzer çalışır. Çekirdek, istek takılırsa tekrar tekrar beklememek için son denetim zamanını istekten önce kaydeder. Premium eklenti ve temaların kendi lisans ve güncelleme sunucuları ise her zaman bu kadar özenli yazılmaz. Bazıları her yönetim sayfasında, uzun bir zaman aşımıyla istek atar.

Kontrol için Site sağlığı ekranındaki WordPress.org iletişimi ve HTTP istekleri testlerine bakın. Query Monitor'ün HTTP API Calls panelinde ise her dış isteğin hedefini, yanıt kodunu ve süresini görürsünüz. Zaman aşımıyla biten ya da birkaç saniye süren bir satır aradığınız şeydir. Hedef adres tek bir eklentinin lisans sunucusuysa eklentinin geliştiricisine yazın. Hedef api.wordpress.org da dahil olmak üzere her yerse, sunucunuzun dışarıya HTTPS bağlantısı kurup kuramadığını sağlayıcınıza sorun.

Teşhis amaçlı bir kestirme de var. wp-config.php içinde dış istekleri engelleyip yalnız izin verdiğiniz adreslere açabilirsiniz:

define( 'WP_HTTP_BLOCK_EXTERNAL', true );
define( 'WP_ACCESSIBLE_HOSTS', 'api.wordpress.org,*.wordpress.org' );

Engellenen istekler beklemeden başarısız olduğu için panel bir anda hızlanıyorsa, suçlunun dış bir istek olduğunu kesinleştirmiş olursunuz. Bu ayarı canlı bir mağazada denemeyin. Ödeme altyapısı, kargo ve fatura entegrasyonları da aynı HTTP katmanını kullanır ve listede olmayan her servis çalışmayı bırakır. Hazırlık kopyasında birkaç dakikalık bir denemeden sonra satırları kaldırın.

Gösterge paneli bileşenleri

Başlangıç ekranı diğerlerinden belirgin biçimde yavaşsa bileşenlere bakın. SEO özetleri, ziyaret istatistikleri, sipariş grafikleri, haber akışları. Bunların bir kısmı her açılışta dış bir servisten ya da büyük tablolardan veri çeker.

Sık yapılan bir hata, bileşeni Ekran ayarları (Screen Options) menüsünden gizleyip sorunun çözüldüğünü sanmaktır. WordPress'in do_meta_boxes() fonksiyonunun kaynak koduna bakınca gizlenen kutuya yalnız bir CSS sınıfı eklendiği ve kutunun içeriğini üreten fonksiyonun yine çağrıldığı görülüyor. Yani gizli bileşen görünmez ama işini yapmaya devam eder. Gerçekten kurtulmak için önce eklentinin kendi ayarlarında pano bileşenini kapatma seçeneği arayın. Yoksa bileşeni kodla kaldırabilirsiniz. Bileşenin kimliğini tarayıcıda sağ tıklayıp İncele dediğinizde kutunun id değerinde görürsünüz:

add_action( 'wp_dashboard_setup', function () {
    remove_meta_box( 'bilesen_kimligi', 'dashboard', 'normal' );
}, 20 );

Kodu wp-content/mu-plugins/ altında, <?php ile başlayan küçük bir dosyaya koymak, tema değişikliklerinden etkilenmemesini sağlar. Eklenti bileşeni side bağlamıyla kaydettiyse üçüncü parametreyi buna göre değiştirin. Emin değilseniz normal ve side için iki ayrı satır yazmanın bir zararı yoktur.

Heartbeat ve admin-ajax.php

Bir yönetim sekmesi açık durduğu sürece WordPress, Heartbeat API aracılığıyla sunucuya düzenli aralıklarla admin-ajax.php isteği gönderir. Oturum süresi uyarısı, yazı kilitleri ve klasik düzenleyicideki otomatik kayıt bu kanal üzerinden işler. Çekirdekteki heartbeat.js dosyasına göre varsayılan aralık 60 saniyedir. Pencere odakta değilken 120 saniyeye uzar. Kullanıcı hareketsiz kalırsa istekler askıya alınır: askıya alma açıksa 10 dakika sonra, her durumda 60 dakika sonra.

Tek başına küçük bir yük. Sorun çarpanlarda. Beş editörün her birinde altışar sekme açık duruyorsa sunucu dakikada onlarca ek PHP isteği alır ve bunların her biri WordPress'i baştan yükler. Paylaşımlı hostingde bu istekler aynı eşzamanlı işlem havuzunu kullanır. Yoğun saatte 508 Resource Limit Reached hatasına kadar varan tabloların bir kısmı buradan çıkar.

Network sekmesinde süzgece admin-ajax yazın ve birkaç dakika bekleyin. İsteklerin gövdesinde action=heartbeat görüyorsanız sıklığı ve süresini not edin. Tek bir heartbeat isteği bir saniyeden uzun sürüyorsa, bir eklenti heartbeat_received süzgecine ağır bir iş bağlamış olabilir. Query Monitor bu isteğin üretim süresini AJAX yanıt başlıklarında gösterir. Aralığı uzatmak için heartbeat_settings süzgeci kullanılır:

add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 120;
    return $settings;
} );

Süzgecin belge sayfasındaki örnek 15 ile 120 saniye arasında bir değer öneriyor. Heartbeat'i bütünüyle kapatmanızı önermiyoruz. Aynı yazıyı iki kişinin düzenlemesini engelleyen kilit ve oturum süresi uyarıları bu kanala bağlıdır.

Autoload şişmesi ve geçiciler

WordPress her istekte, ön yüzde de panelde de, wp_options tablosunda otomatik yüklenmek üzere işaretlenmiş bütün seçenekleri tek seferde belleğe alır. Silinmiş eklentilerden kalan ayarlar, yıllardır büyüyen günlük kayıtları ya da büyük bir diziyi seçenek olarak saklayan eklentiler bu yükü megabaytlarca şişirebilir. Ön yüzde sayfa önbelleği bunu gizler, panelde ise her tıklamada hissedilir.

WordPress 6.6 bu konuda iki değişiklik getirdi. Site sağlığına "Autoloaded options could affect performance" testi eklendi ve otomatik yüklenen seçeneklerin toplamı 800 KB'ı aştığında kritik uyarı veriyor. Ayrıca autoload değeri açıkça belirtilmeden kaydedilen ve 150.000 baytı aşan seçenekler artık otomatik yüklenmiyor. Ama bu kural yalnız yeni yazılan değerlere uygulanır, veritabanında zaten duran yükü temizlemez.

En büyük seçenekleri görmek için phpMyAdmin'de şu sorguyu çalıştırabilirsiniz. Sorgu yalnız okuma yapar. Tablo ön ekiniz wp_ değilse değiştirin:

SELECT option_name, LENGTH(option_value) AS bayt
FROM wp_options
WHERE autoload IN ('yes', 'on', 'auto-on', 'auto')
ORDER BY bayt DESC
LIMIT 20;

Değer listesi, WordPress 6.6 ile gelen wp_autoload_values_to_autoload() fonksiyonunun varsayılan olarak otomatik yüklenmiş saydığı değerlerdir. Daha eski bir sürümdeyseniz yalnız 'yes' değeri kullanılıyordur.

Listenin tepesinde artık kullanmadığınız bir eklentinin adını taşıyan seçenekler varsa onlar ilk adaylardır. Hâlâ kullanılan ama büyük bir seçenekse silmek yerine otomatik yüklemeyi kapatmak daha güvenlidir. WordPress 6.4 ile gelen wp_set_option_autoload() fonksiyonu bunu yapar. Değer yine okunabilir, yalnız her istekte değil, gerektiğinde yüklenir. Her iki işlemden önce veritabanının yedeğini alın. Yanlış seçeneği silmek bir eklentinin ayarlarını sıfırlar.

Geçiciler (transient) de aynı tabloda durur. Çekirdeğin set_transient() kaynak koduna göre süre verilmeden kaydedilen geçiciler otomatik yüklenir, süre verilenler yüklenmez. Süresi dolmuş geçiciler okunduklarında ya da zamanlanmış bir temizlik göreviyle silinir. Cron düzgün çalışmayan sitelerde hiç okunmayanlar birikebilir. Kalıcı bir nesne önbelleği kullanılıyorsa geçiciler veritabanına hiç yazılmaz.

Büyük liste ekranları

Binlerce yazı, ürün ya da sipariş içeren bir sitede liste ekranı her açılışta durum sayılarını hesaplar, sayfa başına seçtiğiniz kadar kaydı çeker ve eklentilerin eklediği her sütun için ayrıca veri ister. Ekran ayarlarından sayfa başına öğe sayısını 20 civarında tutmak çoğu zaman tek başına fark yaratır. Biri bir gün 999 yaptıysa ve öyle kaldıysa, yavaşlığın nedeni zaten bulunmuştur.

Eklentilerin liste ekranlarına eklediği SEO puanı, stok durumu ya da çeviri durumu sütunlarını Ekran ayarlarından kapatmak da yükü azaltır. Bu ekranlarda aynı sorguların tekrar tekrar çalışması nesne önbelleğinin en çok işe yaradığı yerdir. Sayfa önbelleğinden farkını ve neden yönetim panelinde hissedildiğini Redis nesne önbelleğinin ne işe yaradığını anlattığımız yazıda bulabilirsiniz. Paylaşımlı hosting paketinizde Redis ya da Memcached sunulup sunulmadığını paket ayrıntısından kontrol edin ya da destek ekibine sorun.

wp-cron yönetim isteklerinde de tetiklenir

WordPress'in zamanlayıcısı ziyaret geldikçe çalışır ve panelde gezinen bir yönetici de ziyaretçi sayılır. Tetikleme sizin isteğinizi bekletmeyecek şekilde ayrı bir istekle yapılır, ama başlayan görevler aynı sunucuda, aynı anda çalışır. Yedek alan, e-posta kuyruğu işleyen ya da büyük senkron yapan bir görev tam siz ürün düzenlerken başlarsa paneliniz o birkaç dakika boyunca yavaşlar. Kalıcı çözüm, wp-cron'u sunucu cron'una bağlayıp ziyaretlerden ayırmaktır. WooCommerce kullanıyorsanız arka plan görevlerinin çoğu Action Scheduler kuyruğundan geçer. Action Scheduler'da bekleyen ve başarısız işlemlerin birikmesi panel yavaşlığının ayrı bir kaynağı olabilir.

PHP sürümü, OPcache ve bellek

Panel, ön yüzün önbellekle sakladığı PHP performansını çıplak hâliyle gösterdiği için eski bir PHP sürümü en çok burada hissedilir. Desteklenen güncel bir sürüme geçmeden önce uyumluluğu deneyin, adımları cPanel'de PHP sürümünü değiştirme rehberinde bulabilirsiniz. OPcache derlenmiş PHP kodunu bellekte tutar ve kapalıysa her istek bütün eklenti dosyalarını yeniden derler. Etkin olup olmadığını panelinizin PHP ayarlarında ya da Query Monitor'ün Environment panelindeki yüklü PHP eklentileri listesinde görebilirsiniz.

Ağır yönetim işlemlerinde bellek de sınıra dayanabilir. WordPress, yönetim alanı için WP_MAX_MEMORY_LIMIT sabitiyle ayrı bir bellek sınırı tanımlamanıza izin verir. Ancak paketinizin fiziksel bellek sınırı ya da sağlayıcının PHP ayarı izin vermiyorsa yükseltme bir işe yaramaz.

Geri alma: tek eklentiyi klasör adıyla kapatmak

Şüpheli bir eklentiyi denemek ya da bir değişiklik paneli tamamen kilitlediğinde geri dönmek için en güvenli yol, eklentinin klasör adını değiştirmektir. Dosya yöneticisinde wp-content/plugins/eklenti-adi klasörünü eklenti-adi.kapali yapın. WordPress eklenti dosyasını bulamayınca onu devre dışı bırakır ve Eklentiler ekranında bunu bildirir. Eklentinin ayarları veritabanında kalır, silinmez.

Geri almak için klasöre eski adını verin. Eklenti kendiliğinden yeniden açılmaz, Eklentiler ekranından tekrar etkinleştirmeniz gerekir. Bütün eklentileri birden kapatmak için plugins klasörünün adını değiştirmek de mümkün, ama o zaman hangisinin suçlu olduğunu öğrenmek için hepsini tek tek açmanız gerekir. Mümkünse bu denemeleri sitenin hazırlık kopyasında yapın ve öncesinde yedek alın.

Düzeldiğini nasıl anlarsınız?

Başta not ettiğiniz ekran listesine dönün. Aynı ekranları aynı tarayıcıda, aynı saat aralığında iki üç kez açıp Waiting (TTFB) değerlerini yan yana yazın. Değişikliği hangi ekran için yaptıysanız o ekranda belirgin bir düşüş görmeniz gerekir. Görmüyorsanız değişikliği geri alın, çünkü sorunu çözmeyen bir ayar ileride başka bir sorunun nedeni olabilir.

Site sağlığı ekranını yeniden açıp daha önce uyarı veren testlerin geçtiğini kontrol edin. Heartbeat aralığını değiştirdiyseniz Network sekmesinde admin-ajax.php isteklerinin seyreldiğini görün. Panel yavaşlığı iş saatlerine bağlıysa doğrulamayı ekip çalışırken tekrarlayın.

Bütün bu adımlardan sonra panel hâlâ yavaşsa ve ölçümler sorgu ya da PHP süresinin sitenin büyüklüğünden kaynaklandığını gösteriyorsa, artık daha fazla kaynak ve nesne önbelleği gerekiyordur. Kurulu eklentilerinizi, ölçtüğünüz ekran sürelerini ve Query Monitor bulgularını destek talebine ekleyin. Paket seçenekleri için WordPress hosting paketlerine bakabilirsiniz.