WordPress Yönetici Paneli Çok Yavaş Açılıyor: Nedenleri

Sitenizi ziyaretçi gözüyle açtığınızda her şey yolunda: sayfa bir saniyenin altında geliyor, hız testleri yeşil skor veriyor. Ama /wp-admin adresine girdiğinizde başka bir dünyaya geçiyorsunuz. Panel açılırken beş altı saniye bekliyorsunuz, yazı listesi geç geliyor, editörde yazarken imleç takılıyor, "Güncelle" düğmesine bastıktan sonra sayfa donuyor. wp-admin yavaş açılıyor şikâyeti, WordPress dünyasında genel hız sorunlarından tamamen ayrı bir arıza sınıfıdır ve tamamen farklı bir teşhis gerektirir.

Bunun sebebi tek cümleyle şudur: yönetici paneli önbelleklenemez. Ziyaretçi tarafını hızlandıran ne varsa — sayfa önbelleği, CDN, statik HTML üretimi — panelde devre dışıdır, çünkü her ekran o kullanıcıya özel ve o ana ait veriyi göstermek zorundadır. Yani panelde gördüğünüz süre, sunucunuzun PHP + veritabanı gerçek performansının filtresiz hâlidir. Bu yazıda o gerçek performansı ölçmeyi, panelde arka planda sessizce dönen istekleri (Heartbeat, admin-ajax, wp-cron) tespit etmeyi, wp_options tablosundaki autoload şişmesini sorguyla bulmayı ve suçlu eklentiyi elemeli yöntemle yakalamayı adım adım anlatacağım. Yıllardır gördüğüm panel yavaşlıklarının büyük çoğunluğu bu dört başlıktan birine düşüyor.

Panel Neden Ziyaretçi Tarafından Farklı Davranır#

Yönetici paneli, WordPress'in önbelleklenmeyen tek bölümüdür. Bir ziyaretçi ana sayfayı istediğinde WP Rocket, LiteSpeed Cache veya Nginx FastCGI önbelleği devreye girer; PHP çoğu zaman hiç çalışmaz, veritabanına tek sorgu bile gitmez. Panelde ise her ekran yeniden üretilir:

• Her sayfa yüklemesinde wp_options tablosundan autoload işaretli tüm satırlar belleğe çekilir.
• Aktif her eklenti, hem ön yüz hem panel için plugins_loaded kancasına bağlanır ve panele özel ek işler yapar (lisans kontrolü, güncelleme sorgusu, istatistik toplama).
• Panel açıkken tarayıcı, arka planda düzenli aralıklarla admin-ajax.php adresine POST isteği atar (Heartbeat API).
• wp-cron.php, gerçek bir cron görevi tanımlanmadıysa ziyaretçi isteklerine yapıştırılır — ve panelde de tetiklenir.

Sonuç: ziyaretçi 40 ms'de statik HTML alırken, siz aynı sunucuda 3 saniyelik bir PHP çalıştırma süresine bakıyor olabilirsiniz. Bu bir çelişki değil, beklenen davranıştır. Sorun, o 3 saniyenin nereye gittiğini bilmemektir.

Yavaşlığı Ölçmek: Tarayıcı Ağ Sekmesinden Gerçek Veri Almak#

Tahmin yürütmeden önce ölçün; panel yavaşlığında ilk 5 dakikanızı tarayıcı geliştirici araçlarına ayırmak, sonraki iki saati kurtarır.

1. Panelde herhangi bir ekranı açın (önce Panelim/Dashboard, sonra Yazılar listesi).
2. F12 ile geliştirici araçlarını açın, Network / Ağ sekmesine geçin.
3. Disable cache / Önbelleği devre dışı bırak kutusunu işaretleyin.
4. Sayfayı Ctrl+F5 ile yenileyin.
5. Listenin en üstündeki belge isteğine (index.php, edit.php, post.php) tıklayın ve Timing / Zamanlama sekmesine bakın.

Burada tek bir sayı önemlidir: Waiting (TTFB). Bu değer, tarayıcının isteği gönderdikten sonra ilk baytı beklediği süredir ve doğrudan PHP + MySQL süresidir.

Ardından aynı Ağ sekmesinde filtreyi XHR / Fetch yapın ve paneli açık bırakıp bir dakika bekleyin. Burada göreceğiniz tekrarlayan admin-ajax.php istekleri ile wp-cron.php çağrıları, bir sonraki iki bölümün konusu.

Heartbeat API Panelde Arka Planda Ne Kadar Trafik Üretiyor#

Heartbeat, WordPress'in tarayıcı ile sunucu arasında düzenli aralıklarla mesaj taşıyan API'sidir; otomatik taslak kaydetme, "bu yazıyı şu an başka biri düzenliyor" kilidi ve eklentilerin canlı bildirimleri bunun üzerinden çalışır. Sorun, çalışma sıklığındadır:

• Yazı düzenleme ekranında varsayılan aralık 15 saniyedir. Yani editör açık kaldığı sürece dakikada 4 POST isteği.
• Panel ana ekranında aralık 60 saniyedir.
• Her istek admin-ajax.php üzerinden gider, yani her seferinde WordPress çekirdeği ve tüm aktif eklentiler baştan yüklenir.

Editörü açık bırakıp öğle yemeğine giden bir kullanıcı, bir saatte 240 tam WordPress yüklemesi tetikler. Üç editör aynı anda açıksa bu sayı üçe katlanır. Paylaşımlı hosting kaynak limitlerinde ya da dar CPU'lu bir sunucuda bu yük tek başına paneli hissedilir biçimde yavaşlatır.

Aralığı temanızın functions.php dosyası yerine, güncellemelerde silinmeyecek küçük bir mu-plugin dosyasına (wp-content/mu-plugins/heartbeat-ayari.php) koyun:

<?php
// Heartbeat aralığını yavaşlat. Kabul edilen aralık: 15-120 saniye.
add_filter( 'heartbeat_settings', function ( $settings ) {
    $settings['interval'] = 120;
    return $settings;
} );

// Panel ana ekranında Heartbeat'e hiç ihtiyaç yok, tamamen kaldır.
add_action( 'init', function () {
    global $pagenow;
    if ( 'index.php' === $pagenow ) {
        wp_deregister_script( 'heartbeat' );
    }
}, 1 );

Filtrenin kabul ettiği aralık 15–120 saniyedir; 300 yazarsanız WordPress değeri sınırlar. Heartbeat'i tamamen kapatmayın: kapattığınızda otomatik taslak kaydetme ve yazı kilidi de gider, iki editörün aynı yazıyı ezmesi ihtimali doğar. 120 saniye, çoğu site için güvenli ve yeterli bir uzlaşmadır.

admin-ajax.php Yavaşsa Suçluyu Nasıl Bulursunuz#

Ağ sekmesinde admin-ajax.php isteklerinin süresi 400 ms'yi geçiyorsa, sorumlu Heartbeat değil, o isteği yapan eklentidir. Suçluyu bulmanın yolu isteğin gövdesine bakmaktır:

1. Ağ sekmesinde admin-ajax.php satırına tıklayın.
2. Payload / Request sekmesine geçin.
3. action= parametresinin değerini okuyun.

action=heartbeat görüyorsanız yukarıdaki bölüme dönün. Ama action=wpforms_analytics, action=woocommerce_json_search_products ya da action=falanca_eklenti_stats gibi bir değer görüyorsanız, adı geçen eklenti panelde arka plan işi çalıştırıyor demektir. Süreyi de aynı ekranda ölçüp karar verin: 50 ms'lik bir istek zararsızdır, 1,2 saniyelik bir istatistik isteği panelinizi tek başına yavaşlatır.

Sunucu tarafında da aynı şeyi görebilirsiniz. Erişim kayıtlarında admin-ajax.php isteklerinin sıklığını sayın:

grep 'admin-ajax.php' /var/log/nginx/access.log | wc -l
grep 'admin-ajax.php' /var/log/nginx/access.log | awk '{print $1}' | sort | uniq -c | sort -rn | head

cPanel kullanıyorsanız aynı veri Metrics → Raw Access altındaki günlük dosyalarında bulunur; hata kayıtlarına da aynı menüdeki Errors ekranından ulaşabilirsiniz.

wp_options Tablosundaki Autoload Şişmesi#

Panel yavaşlığının en sık gördüğüm ve en az bilinen sebebi budur. WordPress her istekte — panelde de, ön yüzde de — wp_options tablosundan autoload işaretli tüm satırları tek sorguyla çeker ve belleğe alır. Bu veri normalde birkaç yüz kilobayttır. Yıllar içinde silinen eklentilerin geride bıraktığı ayarlar, biriken transient kayıtları ve devasa serileştirilmiş diziler yüzünden bu boyut 5–10 MB'a çıkabilir. O noktada her sayfa yüklemesi, işe 10 MB veri okuyup PHP'de diziye çevirerek başlar.

Önce ne kadar veri olduğunu ölçün. WordPress 6.6 ile birlikte autoload sütunu yes/no dışında on, off, auto gibi değerler de alabildiği için sorguyu geniş yazmak gerekir:

SELECT ROUND( SUM( LENGTH( option_value ) ) / 1024 / 1024, 2 ) AS autoload_mb,
       COUNT(*) AS satir_sayisi
FROM wp_options
WHERE autoload IN ( 'yes', 'on', 'auto', 'auto-on' );

1 MB üstü bir sonuç incelenmeyi hak eder, 3 MB üstü kesinlikle sorunludur. Şimdi kimin şişirdiğine bakın:

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 25;

Çıkan listeyi şöyle okuyun:

• _transient_* ve _site_transient_* ile başlayanlar: süresi geçmiş geçici veriler, temizlenebilir.
• Artık kurulu olmayan bir eklentinin adını taşıyanlar (eskiEklenti_settings, xyz_license_cache): kalıntı, silinebilir.
• rewrite_rules: kalıcı bağlantı kuralları. Çok büyükse aşırı sayıda özel yazı tipi/taksonomi var demektir.
• cron: zamanlanmış görev listesi. Yüzlerce kilobayt ise binlerce ölü görev birikmiştir.

Temizliğin güvenli yolu WP-CLI'dir; SQL ile elle silmeden önce mutlaka yedek alın:

# Süresi geçmiş tüm transient kayıtlarını sil
wp transient delete --expired

# Kalıntı bir seçeneği ismen sil
wp option delete eskiEklenti_settings

# Devasa bir seçeneği silmek yerine autoload dışına al
wp option set buyuk_ayar "$(wp option get buyuk_ayar)" --autoload=no

Bu temizliğin ardından wp_postmeta ve wp_commentmeta tablolarındaki yetim satırları da gözden geçirin; tablo şişmesi panel yavaşlığının ikinci ayağıdır.

Eklentileri Elemeli Yöntemle Teşhis Etmek#

Ölçümler eklentiyi işaret ediyorsa, tahminle uğraşmayın; ikili eleme yapın. Canlı sitede yapıyorsanız trafiğin en düşük olduğu saati seçin ve önce yedek alın.

SSH erişiminiz varsa en hızlı yol WP-CLI'dir:

# Mevcut durumu not al
wp plugin list --status=active --field=name > aktif-eklentiler.txt

# Hepsini kapat
wp plugin deactivate --all

# Paneli ölç. Hızlandıysa tek tek aç:
wp plugin activate woocommerce
# ... her açmadan sonra paneli yenileyip TTFB'ye bak

# Bittiğinde eski hâle dön
wp plugin activate $(cat aktif-eklentiler.txt | tr '\n' ' ')

SSH yoksa cPanel Dosya Yöneticisi'nden wp-content/plugins klasörünü plugins-kapali olarak yeniden adlandırın; WordPress tüm eklentileri devre dışı sayar ve panele girebilirsiniz. İsmi geri verdiğinizde eklentiler pasif hâlde durur, tek tek aktifleştirirsiniz. Panele hiç giremiyorsanız WordPress admin paneline giremiyorum yazısındaki kurtarma adımları bu iş için yazılmıştır.

Ölçümü daha görünür yapmak isterseniz wp-config.php dosyasına geçici olarak şunu ekleyin ve Query Monitor eklentisini kurun:

define( 'SAVEQUERIES', true );

Query Monitor panelin üst çubuğunda her ekran için toplam sorgu sayısını, en yavaş sorguyu ve hangi eklentinin kaç milisaniye harcadığını dosya bazında gösterir. Teşhis bitince SAVEQUERIES satırını mutlaka kaldırın — her sorguyu bellekte tuttuğu için canlıda açık kalması başlı başına bir yavaşlık sebebidir.

wp-cron ve Güncelleme Kontrolleri#

WordPress'in zamanlanmış görevleri gerçek bir sistem cron'u değildir; varsayılan olarak gelen isteklere yapıştırılır. Panelde bir ekran açtığınızda süresi gelmiş görev varsa, sunucu kendi kendine bir HTTP isteği (loopback) açar ve onu çalıştırır. Yüzlerce görev birikmişse ya da loopback istekleri güvenlik duvarına takılıp zaman aşımına uğruyorsa, panel her açılışta 20–30 saniye bekleyebilir.

Önce kuyruğa bakın:

wp cron event list --fields=hook,next_run_relative,recurrence | head -30

Geçmiş tarihli onlarca overdue satır görüyorsanız cron çalışmıyordur. Doğru çözüm, WordPress'in kendi tetiklemesini kapatıp işi sisteme devretmektir:

// wp-config.php içine, "That's all, stop editing!" satırının üstüne
define( 'DISABLE_WP_CRON', true );

Ardından sunucuda gerçek bir zamanlanmış görev tanımlayın (cPanel → Cron Jobs veya sunucuda crontab -e):

*/5 * * * * curl -s -o /dev/null https://ornekalanadi.com/wp-cron.php?doing_wp_cron

Bu tek değişiklik, "panel bazen çok yavaş, bazen normal" tarifine uyan vakaların çoğunu çözer — çünkü yavaşlık, cron'un kime denk geldiğine bağlı olarak rastgele görünür. Beş dakikalık aralık çoğu site için yeterlidir; yayın zamanlaması yoğun bir haber sitesindeyseniz bir dakikaya çekebilirsiniz.

Bir başka sessiz gecikme kaynağı, panel açılışında yapılan güncelleme kontrolleridir. Eklenti sayısı fazlaysa ve bazıları kendi lisans sunucusuna sorgu atıyorsa, o sunucu yavaşladığında sizin paneliniz yavaşlar. Bu isteklerin varlığını Query Monitor'ün HTTP API Calls sekmesinden görebilirsiniz; 2 saniyenin üzerinde süren bir dış istek varsa, kaynağı olan eklentiyi gözden geçirin.

Sunucu Tarafı Sınırlar: Bellek, PHP-FPM ve Nesne Önbelleği#

Yukarıdaki adımların hepsi temizse sorun yazılımda değil, kaynaktadır. Üç şeye bakın:

1. PHP bellek limiti. Panel, ön yüzden daha fazla bellek ister; medya kütüphanesi ve güncelleme ekranları özellikle açtır. wp-config.php içinde panele özel limit tanımlayabilirsiniz:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

Bu değerler sunucudaki memory_limit ayarının üzerine çıkamaz; PHP tarafındaki değeri aşan bir tanım sessizce yok sayılır. Limit yetmediğinde panel yavaşlamaz, doğrudan boş sayfa verir — o durumdaysanız WordPress beyaz ekran hatası yazısı sizin adresiniz.

2. PHP-FPM işçi sayısı. Panelde Heartbeat, admin-ajax ve normal sayfa isteği aynı anda sıraya girer. Havuzdaki işçi sayısı azsa istekler birbirini bekler ve panel "takılıyor" hissi verir. Kabaca pm.max_children değeri, kullanılabilir belleğin bir PHP işleminin ortalama bellek tüketimine bölünmesiyle bulunur; panelde eşzamanlı çalışan editör sayısını da bu hesaba katın.

3. Nesne önbelleği. Sayfa önbelleği panelde işe yaramaz ama nesne önbelleği yarar. Redis ya da Memcached kurulu bir sitede wp_options ve wp_postmeta sorguları bellekten gelir, panelin sorgu yükü belirgin biçimde düşer. Panel yavaşlığında gerçekten fark yaratan tek önbellek türü budur; kurulum için Redis object cache yazısını izleyin.

Son olarak, XML-RPC üzerinden gelen otomatik istekler de sunucuyu meşgul edip paneli yavaşlatabilir. Kullanmıyorsanız kapatın: WordPress XML-RPC kapatma.

Sıkça Sorulan Sorular#

wp-admin neden önbelleklenemiyor#

Yönetici paneli oturuma özel ve anlık veri gösterdiği için önbelleklenemez. Bekleyen yorum sayısı, güncelleme uyarıları, taslak yazılar ve o an oturum açmış kullanıcının yetkileri her istekte yeniden hesaplanır; bunları statik HTML olarak saklamak yanlış veri göstermek anlamına gelir. Bu yüzden WP Rocket, LiteSpeed Cache gibi eklentiler panelde kendilerini otomatik devre dışı bırakır. Panelde gerçekten fayda sağlayan tek önbellek türü, sorgu sonuçlarını bellekte tutan nesne önbelleğidir.

Heartbeat API'yi tamamen kapatmak zararlı mı#

Tamamen kapatmak önerilmez, aralığı uzatmak yeterlidir. Heartbeat kapalıyken otomatik taslak kaydetme çalışmaz, yani tarayıcı çöktüğünde yazdıklarınız kaybolur; ayrıca yazı kilidi devre dışı kalır ve iki editör aynı yazıyı birbirinin üzerine yazabilir. Doğru yaklaşım, filtreyle aralığı 15 saniyeden 120 saniyeye çekmek ve panel ana ekranında betiği tamamen kaldırmaktır. WooCommerce gibi canlı bildirim kullanan eklentileriniz varsa 60 saniyede kalın.

admin-ajax.php isteği kaç milisaniyeyi geçerse sorunlu sayılır#

Pratikte 400 milisaniyenin üzeri incelenmeyi hak eder. Heartbeat isteği tipik olarak 100–250 ms bandında tamamlanır; çünkü içeriği küçüktür ama arka planda tam bir WordPress yüklemesi vardır. Bir eklentinin kendi action değeriyle yaptığı istek 1 saniyeyi aşıyorsa, o eklenti panel açıkken sürekli sorgu çalıştırıyor demektir. İsteğin action parametresini tarayıcının Ağ sekmesindeki Payload bölümünden okuyup sorumluyu ismen tespit edebilirsiniz.

Panel yavaşlığı hosting paketinden mi kaynaklanır#

Bazen evet, ama önce yazılım tarafını elemek gerekir. Paylaşımlı bir pakette CPU ve eşzamanlı işlem sınırları vardır; panelde aynı anda dönen Heartbeat, cron ve normal istek bu sınıra dayandığında istekler kuyruğa girer. Ancak aynı belirtiyi 8 çekirdekli bir sunucuda 6 MB autoload verisi de üretir. Doğru sıra şudur: önce autoload boyutunu ölçün, sonra eklenti elemesi yapın, ikisi de temizse kaynak yükseltmeyi konuşun.

wp_options tablosunu temizlemek veri kaybına yol açar mı#

Süresi geçmiş transient kayıtlarını silmek veri kaybı değildir, çünkü bunlar zaten yeniden üretilebilen geçici verilerdir. Riskli olan, adını tanımadığınız bir seçeneği silmektir: hâlâ kurulu bir eklentinin ayarları olabilir. Güvenli yöntem, silmek yerine --autoload=no ile seçeneği her istekte yüklenmekten çıkarmaktır; veri yerinde kalır, sadece ihtiyaç duyulduğunda okunur. Her durumda işlem öncesi veritabanı yedeği alın.

Query Monitor eklentisi canlı sitede açık bırakılabilir mi#

Kurulu bırakılabilir ama SAVEQUERIES sabiti açık bırakılmamalıdır. Query Monitor yalnızca yönetici yetkisine sahip kullanıcılara çıktı verdiği için ziyaretçiler hiçbir şey görmez. Ancak wp-config.php içindeki SAVEQUERIES tanımı, her isteğin tüm SQL sorgularını ve çağrı yığınını bellekte tutar; bu, ölçmeye çalıştığınız yavaşlığı bizzat üretir. Teşhis bittiğinde o satırı kaldırın, eklentiyi isterseniz bırakın.

Sunucu değiştirmek panel hızını kesin olarak çözer mi#

Hayır; taşınan veritabanı sorunlu ise yavaşlık da taşınır. Şişmiş bir wp_options tablosu, binlerce ölü cron görevi ve panelde arka plan işi çalıştıran bir eklenti yeni sunucuda da aynı işi yapar. Daha hızlı bir makine süreyi kısaltır ama sebebi ortadan kaldırmaz. Bu yüzden taşıma kararından önce autoload ölçümünü ve eklenti elemesini yapın; taşımaya karar verirseniz de temizlenmiş bir veritabanıyla taşıyın.

Kapanış#

Panel yavaşlığında yol haritası nettir: önce tarayıcının Ağ sekmesinden belge isteğinin TTFB değerini ölçün, sonra XHR filtresiyle admin-ajax.php isteklerinin sıklığını ve action parametresini okuyun, ardından wp_options tablosundaki autoload boyutunu SQL ile sorgulayın. Bu üç ölçüm, vakaların büyük çoğunluğunda suçluyu doğrudan gösterir. Kalan durumlarda eklentileri toptan kapatıp tek tek açarak eleme yapın ve DISABLE_WP_CRON ile zamanlanmış görevleri gerçek bir sistem cron'una devredin. Sunucu kaynağını yükseltmek listenin sonundadır, başında değil — çünkü ölçmeden yapılan yükseltme, sorunu daha hızlı bir makinede tekrarlamaktan ibarettir.

Bu adımları kendiniz uygulamak istemiyorsanız ya da uyguladığınız hâlde panel hâlâ ağırsa, işi devretmek makul bir tercihtir. Autoload temizliği, eklenti denetimi ve düzenli güncelleme takibi WordPress bakım hizmetinin kapsamındadır. Nesne önbelleği açık, PHP sürümü güncel ve kaynak limitleri WordPress'e göre ayarlanmış bir ortam arıyorsanız WordPress hosting paketleri bu yapılandırmayla gelir; panelde aynı anda çok sayıda editör çalışan, ağır eklenti kullanan sitelerde ise izole kaynak sunan VDS sunucu çözümleri daha doğru adrestir. Sunucu tarafındaki PHP-FPM ve önbellek ayarlarıyla uğraşmak istemiyorsanız sunucu yönetimi hizmeti bu yapılandırmayı sizin adınıza üstlenir.