--- title: "WordPress Admin Yavaş mı? Yönetici Panelini Hızlandırma Rehberi" url: https://bw.agency/blog/wordpress-admin-yavas/ date: 2026-09-25 modified: 2026-09-25 lang: tr author: "Tolga Altaş" description: "WordPress admin yavaş çalışıyor ama siteniz hızlı mı? wp-admin'i yavaşlatan gerçek nedenleri ve 15 dakikalık çözüm listesini adım adım öğrenin." categories: - "WordPress" image: https://img.poweredcache.net/bw.agency/wp-content/uploads/2026/09/wordpress-admin-yavas.avif?rs=fit&w=793&h=500&ssl=1 word_count: 2106 --- # WordPress Admin Yavaş mı? Yönetici Panelini Hızlandırma Rehberi ## Önemli Noktalar - Heartbeat API, varsayılan olarak 15 ile 60 saniye arasında tetiklenerek PHP işçilerini doldurur ve yönetici panelini yavaşlatır. - Autoload verisi 800 KB sınırını aştığında, WordPress yönetici panelindeki her sayfa yüklemesi ciddi performans kayıpları yaşar. - admin-ajax.php dosyası, her AJAX isteğinde tüm WordPress yığınını yeniden başlattığı için panelde darboğaz oluşturur. - Heartbeat sıklığını 120 saniyeye çıkarmak, arka plan admin-ajax isteklerini yüzde 87 oranında azaltır. - Panel ana ekranı, diğer admin sayfalarından 2 saniye daha yavaş yükleniyorsa sorun genellikle widget'ların çalıştırdığı dış API çağrılarıdır. Ö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](https://bw.agency/blog/wordpress-autoload-siskinligi/) `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. | Belirti | En olası neden | Sonraki adım | | ------- | --------------- | ------------- | | Panel 6 sn+ sürüyor ama site hızlı | Önbellek ve CDN wp-admin'i atlar; her eklentinin `admin_init` çağrısının ham PHP süresini hissedersiniz | Önce yapılandırma ve veritabanını tara, sonra `admin_init` çağrılarını süreye göre sırala | | Her admin sayfası bir saniye takılıyor | Aşırı büyük autoload verisi; tüm `wp_options` seti render öncesi yüklenir | Autoload boyutunu ölç (hedef 800 KB altı), en büyükleri autoload'dan çıkar | | wp-admin sadece yazı kaydederken donuyor | Yavaş `save_post` çağrıları, otomatik kayıt ve Heartbeat trafiğiyle üst üste biner | Heartbeat'i 120 sn'ye çek, sonra `save_post` çağrılarını süre bazında ölç | | Her yeni eklenti admin'i yavaşlatıyor | Birikimli `admin_init` / `admin_menu` maliyeti; her eklentinin hook'u her sayfada çalışır | Eklentileri tek tek kapatmak yerine tüm hook çağrılarını süreye göre sırala | | Gutenberg editörü yazarken takılıyor | Yavaş REST API (`/wp-json/`) yanıtları ve Heartbeat trafiği; her biri tam bir WordPress başlatması | DevTools Network'te yavaş `/wp-json/` isteklerini izle, editörde Heartbeat'i 120 sn yap | | Site sadece giriş yapmış kullanıcılarda yavaş | Giriş yapılı istekler önbelleği atlar; aynı autoload ve hook maliyeti her sayfaya biner | Nesne önbelleğini aç, giriş yapılı isteği aynı yöntemle profille | | wp-admin'de rastgele 502 hataları | ~1 MB üstü autoload verisi; memcached tabanlı hostlarda anahtar limiti 1 MB olduğu için blob önbelleğe alınamaz | Autoload sorgusunu çalıştır, toplamı 800 KB altına indir | | Eklenti veya çekirdek güncellemesi sonrası yavaşlık | Güncelleme ve lisans kontrolleri `admin_init`'te dış HTTP isteği yapar; sayfayı zaman aşımına kadar bloklar | Dışarı HTTP çağrısı yapan `admin_init` çağrılarını süreye göre incele | | Sabah normal, öğleden sonra yavaş | admin-ajax yoğunluğu; her açık sekmenin Heartbeat'i ekip giriş yaptıkça PHP işçilerini doldurur | 60 saniyede `admin-ajax.php` isteklerini say, Heartbeat'i 120 sn yap, boş sekmeleri kapat | ## 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](https://bw.agency/blog/wordpress-nesne-onbellegi/), 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](https://bw.agency/blog/ajanslar-icin-wordpress-site-teshisi/). **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. - **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–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. - **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. - **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. - **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. - **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. | Mekanizma | Ne yapar | Nasıl fark edilir | Ne yapmalı | | --------- | -------- | ------------------ | ----------- | | `admin_init`'te lisans kontrolü | Her sayfada satıcı sunucusunu arar; yanıt gelene kadar sayfayı bloklar | Query Monitor HTTP panelinde her ekranda aynı dış istek görünür | Çağrıyı ölç, yazara bildir; çözüm transient önbelleğidir | | Uzak haber / changelog widget'ları | Widget için satıcıdan RSS veya JSON akışı çeker | Panel ana ekranı yavaş, gerisi normaldir | `remove_meta_box()` ile widget'ı kaldır | | Admin'de çalışan güvenlik tarayıcıları | Zamanlama yerine `admin_init`'te dosya sistemini tarar | Her ekran yavaş, tıklamada CPU yükselir, bir çağrı yüzlerce ms gösterir | Taramayı WP-Cron'a taşı; ayar yoksa cevabınız budur | | Her yerde varlık yükleyen sayfa oluşturucular | Editör CSS/JS paketini kullanılmayan ekranlarda da yükler | Network'te oluşturucu scriptleri alakasız ekranlarda görünür | Oluşturucuyu belirli içerik türleriyle sınırla | | Dış API'yi yoklayan pazarlama eklentileri | Kampanya veya abone verisini admin yüklemesinde çeker | Her ekranda dış HTTP veya admin-ajax çağrısı görünür | İstatistik widget'ını kapat, senkron aralığını uzat | 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? - **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. - **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. - **Eklentileri tek tek kapat.** Her kapatmadan sonra yükleme süresini ölç. Hızlandığında suçluyu buldun. Bu yöntem yorucu ama kesindir. - **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. - **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: - 15 eklentinin her biri `admin_init`'e 50 ms ekler = 750 ms taban maliyet - Widget'lar her yüklemede dış API çağrısı yapar - AJAX işleyicileri basit işler için tam WordPress başlatır - 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. | Metrik | Nasıl ölçülür | "Düzeldi" neye benzer | | ------ | ------------------ | ---------------------- | | [Admin TTFB](https://bw.agency/blog/wordpress-backend-performansi/) | DevTools Network, `/wp-admin/` ilk istek. 3 kez yükle, medyanı al | Kendi tabanınızdan kabaca yarıya iner | | Autoload boyutu (KB) | Autoload bölümündeki SQL sorgusu | Toplam 800 KB altı | | En yavaş `admin_init` çağrısı (ms) | Çağrı zamanlayıcı veya `microtime()` farkları | En kötü çağrınız önceki sayının çok altında | | Dakikada Heartbeat tik | Network'te `action=heartbeat` say | 120 sn sonrası boş sekmede ~2 dakikada bir tik | | [Sayfa başına sorgu](https://bw.agency/blog/yavas-wordpress-sorgulari/) | Query Monitor toplam sorgu sayısı | 50–100; 300+ eklenti sorunudur | İ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 ### WordPress admin neden bu kadar yavaş? WordPress admin yavaştır çünkü wp-admin sayfa önbelleğini tamamen atlar. Her istek tüm WordPress yığınını başlatır, tüm eklentilerin admin hook'larını çalıştırır ve autoload verinizi yükler. Ön yüz hızlıdır çünkü önbelleklenir; panel önbelleklenemez. ### Admin yavaş ama ön yüz hızlıysa neden? Ön yüz sayfaları nesne önbelleği, sayfa önbelleği veya CDN'den sunulur. Panel her zaman PHP tarafından taze üretilir. `admin_init`'e 50 ms ekleyen bir eklenti önbellekli ön yüze dokunmaz ama her admin tıklamasında birikir. ### Panel yavaş ama diğer admin sayfaları normalse? O zaman sorun wp-admin'in tamamı değil, panel ana ekranıdır. Widget'lar her yüklemede sorgu çalıştırır ve satıcı API'sini çağırır. Günlük kontrol etmediğiniz widget'ları `remove_meta_box()` ile kaldırın. Her ekran eşit yavaşsa autoload ve `admin_init`'e bakın. ### WordPress admin'i hangi eklentinin yavaşlattığını nasıl bulurum? Manuel yöntem: eklentileri tek tek kapatıp yükleme süresini ölçmek. Hızlı yöntem: hook çağrılarını profillemek. Query Monitor eklenti başına sorguları gösterir; bir çağrı zamanlayıcı ise her çağrıyı süreye göre sıralar. ### WordPress admin'i hangi eklentinin yavaşlattığını nasıl bulurum? Manuel yöntem: eklentileri tek tek kapatıp yükleme süresini ölçmek. Hızlı yöntem: hook çağrılarını profillemek. Query Monitor eklenti başına sorguları gösterir; bir çağrı zamanlayıcı ise her çağrıyı süreye göre sıralar. ### wp-admin için ne kadar autoload verisi fazladır? WP Engine, toplam autoload verisini 800 KB altında tutmayı önerir. Üstünde her istek aşırı büyük bir set yükler. Memcached tabanlı hostlarda ~1 MB üstü, anahtar limiti nedeniyle 502 hatasına da yol açar. ### Hosting yükseltmek yavaş paneli düzeltir mi? Bazen; paylaşımlı hosting'de 128 MB PHP belleği ve önbellek yoksa. Ama zaten yönetilen hosting'deyseniz darboğaz neredeyse her zaman eklenti çağrıları veya autoload şişkinliğidir. Daha fazla RAM, her sayfada çalışan 800 ms'lik lisans kontrolünü düzeltmez. ### Eklenti kapatmadan admin'i nasıl hızlandırırım? Üç düşük riskli değişiklikle başlayın: (1) Heartbeat'i 120 sn'ye çekin, (2) dış API çağıran panel widget'larını kaldırın, (3) hosting destekliyorsa nesne önbelleğini açın. Sonra yüzlerce ms'lik fonksiyonu bulmak için hook çağrılarını profilleyin.