Ez az egyik legfélrevezetőbb hibajelenség a WordPressben: a nyilvános oldal villámgyors, a PageSpeed 90 pont fölött van, az ügyfelek nem panaszkodnak — te viszont a saját admin felületeden percekig vársz, amíg betöltődik a bejegyzéslista, és minden mentés után kávéért mész.
Ez nem a te géped, és nem a böngésződ. És nem is csak kényelmi kérdés: a lassú admin szinte mindig annak a jele, hogy az oldal valódi generálási ideje rossz — csak a gyorsítótár eltakarja a látogatók előtt. Amit az adminban érzel, azt érzi az a látogató is, aki bejelentkezik, kosárba tesz vagy fizet.
Az admin azért lassú, mert ott nincs gyorsítótár, és minden oldalbetöltéskor lefut egy csomó dolog, ami a nyilvános oldalon nem: automatikusan betöltött beállítások, frissítés- és licencellenőrzés, a Heartbeat API, meg a bővítmények admin-oldali munkája. A legtöbb esetben a wp_options tábla automatikusan betöltött sorai és a 15 másodpercenként futó admin-ajax.php a két fő gyanúsított. Mindkettő mérhető 10 perc alatt.
Miért teljesen más az admin, mint a nyilvános oldal
Négy lényeges különbség van, és ezek együtt magyarázzák a legtöbb esetet:
- Nincs lapgyorsítótár. A cache bővítmények szándékosan kihagyják a bejelentkezett felhasználókat és a
/wp-admin/útvonalat. Minden admin oldal a nulláról generálódik, minden alkalommal. - Nincs CDN sem. A Cloudflare és társai a statikus tartalmat szolgálják ki, az admin kéréseit átengedik a szerverre. Ha a szerver lassú, az adminban semmi nem tompítja.
- A bővítmények az adminban dolgoznak igazán. Statisztikák, naplók, frissítésfigyelés, licencek, importok: ezek nagy része kizárólag admin oldalon fut.
- Folyamatos háttérforgalom. Amíg nyitva van egy admin fül, a WordPress rendszeresen kérdezget a szervertől a
admin-ajax.phpvégponton. Ez nem egy kérés, hanem sok, egész nap.
Kilenc tipikus ok, gyakoriság szerint
1. Az automatikusan betöltött beállítások (a legtöbbször ez)
A WordPress minden egyes oldalbetöltéskor beolvassa a wp_options tábla összes olyan sorát, aminek az autoload értéke yes. Ez normál esetben néhány száz kilobájt. Évek alatt viszont felhalmozódik: elavult bővítmények hátrahagyott beállításai, soha le nem járó átmeneti adatok, hibás naplózás, importált termékek maradékai. Láttam már 40 megabájtos autoload adatot — azt a WordPress minden kérésnél beolvasta és feldolgozta.
Az adminban ez azért érződik jobban, mert ott nincs mögötte sem lapgyorsítótár, sem objektumgyorsítótár, és egy admin oldal betöltése amúgy is több kört tesz.
2. A Heartbeat API
A WordPress 15 másodpercenként (szerkesztőben), illetve 60 másodpercenként (máshol) kérést küld a admin-ajax.php-ra: automatikus mentés, bejegyzés-zárolás, értesítések. Ez önmagában kevés terhelés. De minden ilyen kérés egy teljes WordPress-indítás, és a bővítmények rá tudnak kapcsolódni. Elementorral, WooCommerce-szel és egy-két értesítő bővítménnyel együtt könnyen oda jut, hogy minden negyedpercben fut egy fél másodperces PHP-folyamat — ami osztott tárhelyen a párhuzamos folyamatok korlátjába is beleütközhet.
Felismerni egyszerű: nyisd meg a böngésző fejlesztői konzolját (F12), a Hálózat fülön szűrj a admin-ajax szóra, és hagyd ott egy percre. Ha másodpercenként pörögnek a kérések, vagy egy-egy kérés 2–5 másodperc, megvan a gyanúsított.
3. Frissítés- és licencellenőrzés minden oldalbetöltésnél
A WordPress naponta ellenőrzi a core, a bővítmények és a sablonok frissítéseit. Ez rendben is lenne, de a fizetős bővítmények saját licencellenőrzést is futtatnak a saját szerverük felé, és nem mindegyik gyorsítótárazza az eredményt. Ha egy ilyen szerver lassú vagy elérhetetlen, a te admin oldalad arra vár — akár 10–30 másodpercig, amíg a timeout le nem jár.
Tipikus tünete: az admin egyes oldalai lassúak, és nem mindig ugyanazok, vagy a lassúság napokra megszűnik, aztán visszajön. Ha a Query Monitor „HTTP API Calls” fülén egy külső domain mellett 8 másodperc áll, nem kell tovább keresni.
Ne kapcsold ki a frissítésellenőrzést azért, hogy gyorsabb legyen az admin. Pontosan ez az a döntés, amiből két év múlva feltört oldal lesz. A lejárt licencű bővítményeket inkább cseréld le vagy újítsd meg — a probléma nem az ellenőrzés, hanem a válaszra várás.
4. A vezérlőpult kezdőlapja
A „Vezérlőpult” főoldal külön eset: ott hírfolyamok, bővítmény-statisztikák, SEO összefoglalók és biztonsági jelentések töltődnek, gyakran külső forrásból. Ha csak ez a lap lassú, a többi admin oldal pedig rendben van, akkor nem rendszerszintű gondod van — egyszerűen csukd össze vagy kapcsold ki a felső „Beállítások” fülön azokat a kis blokkokat, amiket nem használsz.
5. A bejegyzés- és rendeléslista
WordPress 7.0 óta az admin listák a DataViews felületre épülnek, ami rugalmasabb, de több adatot kér le. Ha emellé jön 15 000 bejegyzés, egy nagy wp_postmeta tábla, és három bővítmény, ami saját oszlopot ad a listához (minden sorhoz külön lekérdezéssel), akkor egy 20 soros lista könnyen 300 lekérdezést jelent.
WooCommerce-nél a rendeléslista a kritikus pont. Ha nincs bekapcsolva a nagy teljesítményű rendeléstárolás (HPOS), a rendelések a wp_posts és wp_postmeta táblákban vannak, és néhány tízezer rendelésnél a lista használhatatlanul lassú lesz.
6. A médiatár
Néhány tízezer fájl fölött a médiatár rácsos nézete lassú lesz, mert minden kép minden méretváltozatáról adatot kér. Ehhez jön, hogy a WordPress 7.0-tól a feltöltés egy része a böngészőben történik — ami jó, de nem a régi fájlokon segít. Ha csak a médiatár lassú, váltsd át listanézetre, és ne futtass rajta „újragenerálás” típusú bővítményt munkaidőben.
7. A biztonsági bővítmény élő naplója
Több biztonsági bővítmény tud „élő forgalom” nézetet: minden kérést, botot és blokkolt próbálkozást naplóz az adatbázisba. Ez remek dolog nyomozáskor, és borzasztó dolog folyamatosan bekapcsolva: minden látogatói kérésre írást jelent, és a napló táblája hónapok alatt több gigabájtra hízik. Amikor aztán megnyitod a bővítmény admin oldalát, az egy több gigás táblából szeretne összesítést számolni.
8. Nincs objektumgyorsítótár — vagy van, de rosszul
Az objektumgyorsítótár (Redis vagy Memcached) a lekérdezések eredményét tartja a memóriában. Ez az admint arányosan többel gyorsítja, mint a nyilvános oldalt, mert ott nincs mögötte lapgyorsítótár. Ha a tárhelyed ad Redist, érdemes használni.
A fordítottja viszont alattomos: ha a Redis beállítva van, de nem fut, nem elérhető, vagy folyton kiüríti magát a memóriakorlát miatt, akkor a WordPress minden lekérdezésnél hiába próbálkozik, és lassabb lesz, mint gyorsítótár nélkül. Ezt a bővítmény állapotlapja megmutatja — érdemes ránézni, mielőtt továbbkeresnél.
9. A te géped és a hálózat
Ritka, de létezik, és egy perc alatt kizárható: nyisd meg az admint másik gépről vagy mobilhálózatról, inkognitó ablakban. Ha ott gyors, akkor a böngésző kiegészítői (különösen a jelszókezelők és a reklámszűrők), vagy egy helyi VPN a gond. A WordPress admin sok DOM-elemet használ, és néhány kiegészítő mindegyiken végigmegy.
A mérés: két eszköz, tíz perc
Query Monitor
Tedd fel a Query Monitor bővítményt. Egy felső sávot ad az adminban, és minden oldalbetöltésnél megmutatja a lekérdezések számát és idejét, a leglassabb lekérdezéseket, a kimenő HTTP-hívásokat, valamint azt, hogy melyik bővítmény mennyi időt vitt el. Ez önmagában a legtöbb esetet eldönti.
Amit keress benne:
- Queries fül: ha 200 fölötti a lekérdezésszám egy admin oldalon, az baj. Rendezd „Time” szerint, és nézd meg, melyik bővítmény neve szerepel a lassúak mellett.
- HTTP API Calls fül: minden kimenő kérés és annak ideje. Itt bukik le a licencellenőrzés és a külső hírfolyam.
- Scripts / Styles: ha túl sok fájl töltődik, az inkább a frontendet érinti, de az adminban is tud számítani.
Az autoload-vizsgálat
Ehhez elég egy csak-olvasó lekérdezés a phpMyAdminban (a wp_ előtagot cseréld a sajátodra):
SELECT ROUND(SUM(LENGTH(option_value))/1024/1024, 2) AS autoload_mb
FROM wp_options WHERE autoload = 'yes';Nagyjából 0,3–0,8 MB alatt rendben vagy. 2 MB fölött már érezhető, 10 MB fölött ez a te problémád. Ha nagy, nézd meg, mi teszi ki:
SELECT option_name, ROUND(LENGTH(option_value)/1024, 1) AS kb
FROM wp_options WHERE autoload = 'yes'
ORDER BY LENGTH(option_value) DESC LIMIT 25;A lista első tíz sorából általában azonnal látszik, melyik bővítmény a felelős. Gyakori nevek: elavult gyorsítótárazó bővítmények adatai, lejárt átmeneti adatok (_transient_ és _site_transient_ előtaggal), hírlevélküldő statisztikák, régi importok naplói.
Mentés nélkül egyetlen sort se törölj. Az autoload-tisztítás önmagában biztonságos művelet, de csak akkor, ha tudod, melyik bővítményhez tartozik a sor — és ha van visszaút. Egy rossz sor törlése egy webshopnál készletadatot vagy fizetési beállítást visz magával.
Mit tegyél, és milyen sorrendben
| Sorrend | Lépés | Jellemző hatás |
|---|---|---|
| 1. | Query Monitor felrakása, mérés három különböző admin oldalon | Megmondja, hol keress. Nem gyorsít, de megment a vaktában nyúlkálástól. |
| 2. | Autoload mérése, a lejárt átmeneti adatok törlése | A legnagyobb egyszeri ugrás, ha nagy volt. Néha 3–4 másodperc kérésenként. |
| 3. | Vezérlőpult-blokkok kikapcsolása, biztonsági bővítmény élő naplójának lekapcsolása | Pár tized másodperc, de a naplótábla nem hízik tovább. |
| 4. | Nem használt bővítmények eltávolítása (nem csak kikapcsolása) | Kevesebb admin-oldali munka és kevesebb licencellenőrzés. |
| 5. | WooCommerce-nél a HPOS rendeléstárolás bekapcsolása | Nagy rendelésszámnál ez a legnagyobb lépés. Mentés után, és először próbamásolaton. |
| 6. | Objektumgyorsítótár (Redis), ha a tárhely adja | Adminban gyakran 30–50% javulás. |
| 7. | Heartbeat gyakoriságának csökkentése | Nem a betöltést gyorsítja, hanem a háttérterhelést veszi le. |
A sorrend nem véletlen: az első kettő mérés és tisztítás, a többi már beállítás. Ha a sorrendet felcseréled, nem fogod tudni, melyik lépés mit hozott.
Amikor nem az admin lassú, hanem a szerkesztő
Külön kategória, és érdemes megkülönböztetni: ha a bejegyzéslista gyorsan jön, de az Elementor vagy a blokkszerkesztő betöltése tart egy percig, akkor nem ugyanaz a hiba.
A szerkesztő egy nagy JavaScript-alkalmazás, ami a saját beállításait, az összes widgetet, a globális stílusokat és a sablonkönyvtárat is betölti. A WordPress 7.0 óta a blokkszerkesztő kötelezően külön keretben fut, ami rendet tesz a stílusok között, de a betöltendő eszközök számát nem csökkenti. Ha itt van a gond, a Query Monitor keveset mond — a böngésző Hálózat fülét kell nézni, és azt, melyik fájl vagy kérés tart sokáig.
Tipikus okok itt: nagyon hosszú oldal sok száz elemmel, elavult Elementor-gyorsítótár (Eszközök → Fájlok és adatok törlése segít), a wp-content/uploads/elementor/css alatt felgyűlt több tízezer fájl, vagy egy bővítmény, ami minden widgethez saját vezérlőket ad.
Gyakori kérdések
Ha az admin lassú, a látogatók is lassúnak látják az oldalt?
A gyorsítótárból kiszolgált látogatók nem. Akik viszont bejelentkeznek, kosárba tesznek vagy fizetnek, igen — ők ugyanazt a generálási időt kapják, amit te az adminban. Webshopnál ez közvetlenül a bevételt érinti, ezért nem érdemes „csak kényelmi kérdésként” kezelni.
Megéri kikapcsolni a Heartbeat API-t teljesen?
Nem javaslom. A bejegyzés-zárolás és az automatikus mentés rajta múlik — e nélkül két szerkesztő egymás munkáját írja felül, és egy böngésző-összeomlásnál elvész a félkész szöveg. A gyakoriság csökkentése (például 60 másodpercre) észszerű kompromisszum; a teljes letiltás nem.
Mennyi lekérdezés a sok egy admin oldalon?
Nincs szent szám, de tapasztalati érték: 100 alatt jó, 100–200 között elfogadható sok bővítménnyel, 300 fölött szinte biztosan van egy bővítmény, ami minden sorhoz külön kérdez. A lekérdezések összideje fontosabb, mint a számuk: 400 darab 0,2 ms-os lekérdezés gyorsabb, mint négy darab 300 ms-os.
Segít-e, ha nagyobb tárhelycsomagra váltok?
Ha a korlátokba ütközöl, igen. Ha az autoload 20 MB, vagy egy bővítmény minden kérésnél külső szerverre vár, akkor nem — a nagyobb csomagon ugyanaz fog történni, csak drágábban. Ezért van a mérés az első helyen a listán.
Mi az a wp_options autoload, egyszerűen?
Egy beállításlista, amit a WordPress minden oldalbetöltésnél egyben beolvas, mert gyakran kell belőle valami. Normális esetben pár száz kilobájt. Ha egy bővítmény nagy adatot tesz bele, azt is minden egyes kérésnél beolvassa — akkor is, ha egyszer sem használja.
Kimérem, mi lassítja az adminodat
Query Monitor-mérés, autoload-vizsgálat, lekérdezés-elemzés — és egy konkrét lista arról, mi mennyit hoz. Mentéssel, próbamásolaton, az éles oldal megzavarása nélkül.
Kimérem, mi lassítja az adminodat
Query Monitor-mérés, autoload-vizsgálat, és egy konkrét lista arról, mi mennyit hoz.
Kapcsolódó: Időszakosan lassul be a WordPress oldalad? · Hol van a WordPress hibanapló · Karbantartás és frissítés
