Van egy hibatípus, amit mindenki utál: az oldal néha lassú. Nem mindig, nem kiszámíthatóan, és pont akkor sosem, amikor leülsz megnézni. Hívod a tárhelyszolgáltatót, ők ránéznek, és azt mondják: „nálunk minden rendben”. Megnyitod a PageSpeed Insightsot, az 88 pontot ad. Aztán másnap reggel fél tízkor egy ügyfél ír, hogy fél percig töltött a kapcsolati oldal.
Ez a cikk nem arról szól, hogyan gyorsítsd fel a WordPresst általában. Arról szól, hogyan találd meg, mi lassítja le időnként — mert amíg ez nincs meg, minden optimalizálás vaktában lövés.
Az időszakos lassulásnál az időbélyeg a bizonyíték, nem a sebességteszt. Kezdd azzal, hogy 24–48 órán át óránként rögzíted a válaszidőt (egy soros curl is elég). A minta megmondja az okot: mindennap ugyanabban az órában = ütemezett feladat; óránként pontban = cron; kiszámíthatatlan rohamokban = botforgalom; forgalomcsúcsban = erőforráskorlát; hónapok alatt romló = adatbázis.
Miért nem mutat semmit a sebességteszt
A PageSpeed Insights, a GTmetrix és a Lighthouse mind egyetlen pillanatot mérnek, és általában a főoldalt. Ha a lassulás napi egy órában jön, 23/24 esély van rá, hogy a teszt pont a jó időszakra esik. Ráadásul ezek az eszközök főleg a frontend teljesítményt mérik: képméret, JavaScript, renderelés. Az időszakos lassulás viszont szinte mindig szerveroldali, és egyetlen számban látszik: a TTFB-ben.
A TTFB (Time To First Byte) az, hogy a kérés elindulása után mennyi idő telik el az első válaszbájtig. Ebben benne van a PHP futása, az összes adatbázis-lekérdezés és minden külső hívás, amit az oldal indít. Ha ez 300 ms helyett néha 8 másodperc, akkor nem a képeket kell tömöríteni.
A leggyakoribb félremérés: bejelentkezve nézed az oldalt. Bejelentkezett felhasználónak a cache plugin kikapcsol, tehát te a lassú, gyorsítótár nélküli változatot látod — a látogatók pedig a gyorsat. És fordítva is igaz: ha kijelentkezve méred, lehet, hogy egy több órája eltárolt oldalt kapsz, miközben az oldal generálása valójában 6 másodperc.
Először rögzítsd, mikor lassú
Három adatot kell feljegyezni minden alkalommal, amikor te vagy valaki más lassulást észlel:
| Mit jegyezz fel | Miért pont ezt |
|---|---|
| Pontos időpont (perc) | Ez a legértékesebb adat. Egy ütemezett feladat mindig ugyanabban a percben indul. |
| Mit nyitottál — frontend vagy admin, melyik oldal | Ha csak az admin lassú, teljesen más okokat kell keresni. Erről külön cikk szól lentebb. |
| Be voltál-e jelentkezve | Eldönti, hogy a cache-elt vagy a generált változatot láttad. |
| Meddig tartott — 3 másodperc vagy 3 perc | A másodperces lassulás terhelés, a perces inkább időtúllépés külső szolgáltatásnál. |
Ha több kollégád vagy ügyfeled is jelezte már, kérd meg őket, hogy legközelebb írják fel az időpontot. Három-négy időbélyeg után a minta általában kiesik magától.
A 24 órás válaszidő-napló
Ennél egyszerűbb mérést nem tudok mondani. Bármilyen Linux gépen (akár a saját gépeden) ez egy sor:
* * * * * /usr/bin/curl -o /dev/null -s -w "%{time_starttransfer} %{http_code}\n" \
https://sajatoldalam.hu/ | awk '{print strftime("%F %T"), $0}' >> ~/ttfb.logPercenként egy kérés, és a napló soronként ennyit tartalmaz: időpont, TTFB másodpercben, HTTP státuszkód. Egy nap után:
sort -k3 -n -r ~/ttfb.log | head -40Ez kilistázza a 40 leglassabb mérést. Ha mind a 40 ugyanabba az órába esik, két perc alatt megvagy. Ha szétszórva vannak, akkor nem ütemezett feladat, hanem terhelés vagy külső hívás.
Ha nincs gépközeled ehhez, a Query Monitor bővítmény és a tárhely vezérlőpultjának erőforrás-grafikonja is elég jó kiindulás — de ott az időfelbontás általában ötperces vagy durvább, és az ütemezett feladatok rövid csúcsait elmossa.
Nyolc tipikus ok, az időbélyeg szerint
1. Mindennap ugyanabban az órában, 5–30 percig
Ez majdnem mindig ütemezett feladat. Sorrendben a leggyakoribbak: biztonsági mentés, vírus- és fájlintegritás-ellenőrzés (Wordfence „scan”), termék- vagy feed-import, XML-szinkron a készletkezelővel, hírlevél-kiküldés.
Ahol megtalálod: a mentő bővítmény saját naplójában (az UpdraftPlus esetén a beállítások alatt látszik a következő futás), a biztonsági bővítmény ütemezésénél, és a tárhely cron-listájában. A megoldás szinte sosem az, hogy kikapcsolod — hanem hogy áthelyezed hajnali 3-ra, és ha lehet, lebontod kisebb részekre.
2. Óránként, pontban vagy közel pontban
Ez a WP-Cron, vagy egy rá épülő bővítmény. A WordPress saját ütemezője a látogatói kéréseken „lóg”: amikor valaki megnyitja az oldalt, a WordPress megnézi, van-e lejárt ütemezett feladat, és ha van, annak a látogatónak a kérésében lefuttatja. A látogató tehát megvárja a feladatot. Ha az a feladat egy 40 másodperces API-szinkron, akkor valaki 40 másodpercig bámul egy fehér képernyőt.
Erről külön cikk szól a sorozatban — a „kihagyott ütemezés” hibajelenség, a valódi cron beállítása és a cron-sor átvizsgálása együtt tartozik. Addig egy gyors ellenőrzés: ha a wp-config.php-ban nincs DISABLE_WP_CRON, és a tárhelyen sincs beállítva valódi cron, akkor biztosan ez a modell fut nálad.
3. Hirtelen, kiszámíthatatlanul, 2–10 percre
Ez botforgalom. 2026-ban ennek a nagy része már nem keresőrobot, hanem AI-tartalomgyűjtő és adathalmaz-építő, plusz a klasszikus wp-login.php és xmlrpc.php ellen próbálkozó jelszótörő hullámok. Ezek nem a nyitóoldalt kérik le egyszer, hanem mindent, gyorsan, párhuzamosan — és a cache nem segít, mert gyakran olyan URL-eket találnak ki (szűrőparaméterek, kereső, oldalszámok), ami nincs eltárolva.
A bizonyíték a hozzáférési naplóban van (access_log), nem a WordPressben. A felismeréséről és a szűrésről külön cikk szól lentebb.
4. Munkaidőben, forgalomcsúcsban
Ha a lassulás a napi látogatószám-csúccsal esik egybe, akkor erőforráskorlátba futsz. Osztott tárhelyen ez általában az „entry process” vagy a párhuzamos PHP-folyamatok száma: nem a szerver fogy ki az erőből, hanem eléred azt a plafont, amit a csomagod megenged, és onnan minden új kérés sorba áll. Kívülről ez lassulásnak látszik, néha 503-as hibának.
A tárhely vezérlőpultján ez mérhető — a cPanel „Resource Usage” oldalán például külön látszik, melyik korlátot érted el és hányszor. Erről is külön cikk szól a sorozatban.
5. Hónapok alatt egyre többször és egyre tovább
Ha a lassulás nem egy nap alatt jelent meg, hanem fél év alatt vált elviselhetetlenné, akkor szinte biztosan az adatbázis. A wp_options tábla automatikusan betöltött sorai, a soha le nem járó átmeneti adatok (transient), a tízezres wp_postmeta, a felhalmozott bejegyzés-változatok: ezek mind minden egyes oldalbetöltésnél dolgoznak. Ez a klasszikus „magától lett lassú” eset.
6. Csak bejelentkezve, vagy csak a kosárban és a pénztárnál
Ez nem lassulás, hanem a cache kihagyása. A kosár, a pénztár, a fiókoldal és minden bejelentkezett látogató szándékosan kimarad a gyorsítótárból. Ha ezek az oldalak 5 másodperc alatt jönnek, akkor az oldalad valódi generálási ideje 5 másodperc — a cache csak eltakarta eddig. Ez fontos felismerés: nem a cache-t kell javítani, hanem az alatta lévő lassúságot.
7. Csak bizonyos oldalakon, mindig
Ez nem időszakos, de gyakran annak tűnik, mert ritkán nyitod meg azokat az oldalakat. Tipikus helyek: webshop szűrőoldalak sok terméknél, a keresési találati lap, egy nagy archívum, egy táblázatos bővítmény, egy „kapcsolódó termékek” blokk. Egyetlen lassú lekérdezés is elég. A Query Monitor bővítmény pont ezt mutatja meg: melyik lekérdezés mennyi ideig futott, és melyik bővítmény indította.
8. Teljesen véletlenszerűen, miközben a szerver tétlen
Ha az erőforrás-grafikon lapos, de az oldal mégis beragad néha, akkor külső szolgáltatásra vár. Tipikusan: szállítási díj kalkuláció a futárcég API-ján, árfolyam-lekérés, bankkártyás fizetés háttérhívása, készletszinkron, licencellenőrzés egy bővítménynél, külső betűtípus vagy pixel szerveroldali betöltése. Ha az a szolgáltatás lassú vagy nem válaszol, a te PHP-folyamatod ott áll és vár — akár 30 másodpercig, amíg a timeout le nem jár.
Ennek a felismerése egyszerű: a Query Monitor „HTTP API Calls” fülén látszik minden kimenő hívás és annak ideje. Ha ott van egy 12 másodperces sor, megvan.
Osztott tárhelyen a szomszéd is lehet az ok
Ezt nem szeretik hangoztatni, de létezik: osztott tárhelyen több száz oldal fut egy gépen. Ha valamelyik megvadul, az egész gép lassul. A modern tárhelyek konténerekkel és korlátokkal védenek ez ellen, de nem mindegyik, és nem perfekt.
Hogyan derítsd ki: ha a te erőforrás-használatod lapos, és közben a válaszidő mégis kiugrik, akkor nem nálad van a gond. Ezzel az érvvel érdemes a támogatáshoz fordulni — konkrét időpontokkal, és azzal a kéréssel, hogy nézzék meg a gép (nem a te fiókod) terhelését arra az időre. Ha rendszeres, a megoldás a költözés, nem az optimalizálás.
Ha megtaláltad: mit érdemes tenni
| Megtalált ok | Első lépés | Amit sokan tévesen tesznek |
|---|---|---|
| Ütemezett mentés / vírusellenőrzés | Áthelyezés hajnali 2–4 közé, és a mentés ne a saját tárhelyre menjen | Kikapcsolják a mentést. Ez a legdrágább hiba, amit el lehet követni. |
| WP-Cron | Valódi szerveroldali cron beállítása 5 perces futással, DISABLE_WP_CRON bekapcsolása |
Teljesen letiltják a cront cserejárat nélkül — ettől leállnak az ütemezett bejegyzések és a mentés is. |
| Botforgalom | Tűzfalszabály a kártékony útvonalakra, sebességkorlát, xmlrpc.php blokkolása ha nincs használatban |
Letiltják a Googlebotot is. Ettől kiesik a keresőből az oldal. |
| Erőforráskorlát | Először mérés: melyik korlát, mikor, hányszor. Utána objektumgyorsítótár vagy csomagváltás | Azonnal nagyobb csomagot vesznek, és fél év múlva ugyanitt vannak. |
| Adatbázis | A wp_options automatikusan betöltött sorainak átvizsgálása, lejárt átmeneti adatok törlése |
Egy „adatbázis-optimalizáló” bővítményt engednek rá mentés nélkül. |
| Külső API | Rövid timeout beállítása, és az eredmény gyorsítótárazása | Nem veszik észre, mert a bővítmény nem naplóz semmit. |
Amit ne tegyél, amíg nincs meg az ok
- Ne tegyél fel még egy cache bővítményt. Két gyorsítótárazó bővítmény egymás mellett nemhogy nem gyorsít, hanem kiszámíthatatlan hibákat okoz — ettől lesznek a „miért látom a régi árat” típusú jelenségek.
- Ne kapcsolj ki bővítményeket sorban az éles oldalon munkaidőben. Ha muszáj, tedd próbamásolaton, vagy legalább hajnalban, mentés után.
- Ne vegyél azonnal nagyobb csomagot. Ha napi egy mentés eszi meg az erőforrást, a dupla erőforrás csak annyit változtat, hogy fél óra helyett húsz percig lesz lassú.
- Ne töröld a naplókat. Pont azok a bizonyítékok, amikkel a tárhelyszolgáltató támogatása dolgozni tud.
És egy dolog, amit érdemes megtenni, mielőtt bármihez hozzáérsz: legyen friss, letöltött mentésed. Nem a tárhelyen, hanem nálad. A hibakeresés közben mindig van egy pont, ahol valami kikapcsol és nem kapcsolódik vissza rendesen.
Gyakori kérdések
Honnan tudom, hogy a tárhely a szűk keresztmetszet, és nem a WordPress?
Ha az erőforrás-grafikonod lapos, miközben a válaszidő kiugrik, akkor nem a te fiókod fogyott ki az erőforrásból. Ha viszont a grafikon pont a lassulás idején ütközik a korlátba, akkor a te oldalad eszi el — ami nem azonos azzal, hogy kicsi a csomag: lehet, hogy egy bővítmény viselkedik rosszul.
Elég-e egy UptimeRobot-féle figyelő?
Kiindulásnak igen, mert naplózza a válaszidőt és a kimaradásokat is, visszamenőleg. A felbontása viszont ingyenes csomagon általában 5 perces, ami egy kétperces csúcsot kihagyhat. A percenkénti saját curl-napló pontosabb, és nem kerül semmibe.
Miért nem látszik a lassulás a Google Analyticsben?
Mert a GA4 oldalbetöltési adatai a böngészőből jönnek — onnan, ahol a mérőkód már lefutott. Ha az oldal 20 másodperc után időtúllépéssel elhasal, a látogató nem is kerül bele a mérésbe. Az időszakos szerverhibát a szerver naplójában és a figyelőrendszerben kell keresni, nem az analitikában.
Segít-e a Cloudflare az időszakos lassuláson?
Részben. A botszűrésnél és a statikus tartalomnál sokat, és a terhelés egy részét leveszi a szerverről. Az ütemezett feladatoknál, a lassú adatbázisnál és a külső API-k várakozásánál viszont semmit, mert azok a szerveren, a Cloudflare mögött történnek.
Mennyi idő alatt lehet megtalálni az ilyen hibát?
A mérés beállítása 10 perc, utána 24–48 óra adatgyűjtés. Ha a minta egyértelmű, az ok fél óra alatt kiderül. A nehéz esetek azok, ahol két ok keveredik: például napi mentés és botforgalom. Ott érdemes egyenként kizárni őket, nem egyszerre nyúlni mindenhez.
Nem akarsz naplót elemezni?
Megnézem helyetted. Beállítom a mérést, megkeresem a mintát, és konkrét választ adok arra, hogy mitől lassul az oldalad — nem általános gyorsítási tippeket.
Megnézem, mi lassítja az oldaladat
Beállítom a mérést, megkeresem a mintát, és konkrét választ adok. 24 órán belül visszajelzek.
Kapcsolódó: Hol van a WordPress hibanapló, és hogyan olvasd · 500-as belső szerverhiba · Karbantartás és frissítés
