„Lassú a WordPress oldalam, fel lehetne gyorsítani?” — ezzel a mondattal keresnek meg minket a leggyakrabban. A kérés érthető, a válasz viszont szinte soha nem az, amire számítanak: a legritkább esetben van szükség nagyobb tárhelycsomagra vagy egy újabb gyorsítótár-bővítményre.
Az évek alatt kialakult egy fix sorrend, amin ilyenkor végigmegyünk. A sorrend legalább annyira fontos, mint maguk a lépések: előbb mérünk, és csak a legvégén költünk.
Miért éri meg? A keresők és a vásárlók is a gyors oldalt szeretik
A sebesség nem esztétikai kérdés, hanem üzleti. Ha lassú az oldalad, két helyen fizetsz érte: a keresőben és a kasszánál.
A keresőknél a lassúság kettős hátrány. A Google évek óta rangsorolási tényezőként kezeli az oldalélményt — a betöltést mérő Core Web Vitals mutatókkal együtt —, így két hasonlóan releváns találat közül a gyorsabb kerül előrébb. Ennél is fontosabb viszont, hogy a lassú kiszolgálás a feltérképezésre is hat: ha a robot lassan kapja meg a válaszokat, ritkábban jön vissza és kevesebb oldalt jár be. Egy nagy webshopnál ez konkrétan azt jelenti, hogy az új termékek és az árváltozások később kerülnek be az indexbe — vagy egy ideig egyáltalán nem.
A vásárlóknál pedig azonnal látszik az eredmény. Minden extra másodperc a betöltésben látogatókat visz el, méghozzá a legrosszabb helyeken: a termékoldalon és a pénztárban. A Google és a Deloitte közös, kiskereskedelmi oldalakon végzett mérése szerint már 0,1 másodpercnyi gyorsulás is nagyjából 8%-os konverziónövekedést hozott — és a hatás mobilon a legerősebb, ahol a türelem a legkevesebb.
Ezért nem öncélú az alábbi lista. Nem a mérőszám kedvéért optimalizálunk, hanem azért, hogy a látogató ne kattintson vissza, a keresőrobot pedig végig tudja járni az oldalt.
1. Query Monitor: előbb mérünk, aztán javítunk
A leggyakoribb hiba, hogy a tulajdonos találgat. Kikapcsol pár bővítményt, vesz egy nagyobb csomagot, telepít egy cache plugint — és a végén sem tudja, min múlt. Mi ezért mindig a Query Monitorral kezdünk: ez a fejlesztői bővítmény minden oldalbetöltésnél megmutatja, hány adatbázis-lekérdezés futott le, mennyi ideig, és — ami a legfontosabb — melyik bővítmény vagy sablon indította őket.
A lassú lekérdezések ritkán oszlanak el egyenletesen. Jellemzően van egy-két bővítmény, amelyik minden egyes oldalletöltésnél tucatnyi felesleges kérdést tesz fel az adatbázisnak. Ha ez megvan, három út áll előttünk: kiváltjuk a bővítményt egy jobbal, kiváltjuk pár sor egyedi kóddal, vagy — ha muszáj megtartani — kordában tartjuk azzal, hogy csak ott töltjük be, ahol tényleg kell.
A Query Monitor emellett kilistázza a lefutó hookokat, a külső HTTP-hívásokat és a PHP-hibákat is. Utóbbi kettő önmagában is gyakori bűnös: egy külső API, amely minden betöltésnél válaszra várat, néha többet visz el, mint az összes lekérdezés együtt.
2. Autoloaded options: a láthatatlan súly
A WordPress minden egyes kéréskor betölti az „autoload” jelzésű beállításokat a wp_options táblából — a főoldalon, egy termékoldalon és egy AJAX-híváskor egyaránt. Ez normális esetben pár száz kilobájt. Elhanyagolt oldalakon viszont többször láttunk már többmegabájtos autoload-tartalmat, ami minden egyes kérésre plusz terhelést jelent.
A felhízás oka szinte mindig ugyanaz: régen törölt bővítmények maguk után hagyott beállításai, lejárt, de soha ki nem takarított tranziensek, és olyan naplók, amelyeket valaki jó ötletnek gondolt az options táblába menteni. A takarítás nem kockázatmentes — ezért mindig mentéssel kezdjük, és soronként nézzük meg, mi micsoda —, viszont látványos: ez az a lépés, ahol a legkevesebb munkából a legtöbb ezredmásodperc jön vissza.
3. Indexek: ha sok a termék és a meta mező
A WordPress adatbázis-szerkezete általános célra készült, nem egy több tízezer termékes webáruházra. A wp_postmeta tábla — ahol a termékek adatai, az egyedi mezők és a bővítmények adatai laknak — pont ott nem elég erős, ahol a legnagyobb szükség lenne rá: az összetett szűréseknél és rendezéseknél.
Ilyenkor jönnek képbe az index-bővítmények, amelyek a MySQL-táblákra optimalizált indexeket tesznek fel. Nem varázslat, egyszerű adatbázis-karbantartás — de egy nagy katalógusnál egy admin listaoldal betöltése tíz másodpercről egy alá is mehet tőle. Kis oldalon viszont nem érdemes vele bajlódni: ott az index inkább csak plusz karbantartási teher.
4. WooCommerce HPOS: rendelések a saját táblájukban
A WooCommerce évekig a WordPress bejegyzéstábláiban tárolta a rendeléseket — vagyis ugyanott, ahol a blogbejegyzések. Ez sok ezer rendelésnél komoly fékké válik. A HPOS (High-Performance Order Storage) ezt oldja meg: a rendelések külön, direkt erre a célra tervezett táblákba kerülnek.
Ha egy régebbi webshopon ez még nincs bekapcsolva, az szinte mindig megéri. Két dolgot viszont muszáj előtte megnézni: minden bővítmény kompatibilis-e vele, és van-e friss mentés. A váltást érdemes a szinkronizált üzemmóddal kezdeni, hogy legyen visszaút.
5. Bővítmények: frissítés, majd fogyókúra
Nem a bővítmények száma a probléma, hanem az, hogy mit csinálnak minden egyes betöltéskor. Húsz jól megírt bővítmény kevesebbet árt, mint három rossz. Ettől függetlenül igaz, hogy minden bővítmény kód, minden kód karbantartás, és minden elavult bővítmény egyszerre lassulás és biztonsági kockázat is.
Itt már nem lehet általánosságban dolgozni. Ez az a pont, ahol bele kell mélyedni abba, hogy az ügyfélnek pontosan mire van szüksége — mert a kiváltás jellemzően azt jelenti, hogy egy több ezer soros, mindent tudó bővítmény helyett megírjuk azt a néhány tucat sort, amit ténylegesen használ. Ez több munka, mint egy kapcsolót átbillenteni, viszont ez hoz tartós eredményt.
6. Gyorsítótár: hasznos, de nem gyógyszer
A gyorsítótár nem gyorsítja meg az oldalt — csak elrejti a lassúságát. Egy jól optimalizált rendszernél a page cache és az object cache tényleg látványos: a kiszolgálás a felére-negyedére eshet. Egy alapjaiban lassú, összevissza oldalon viszont ritkán segít érdemben, sőt: a hibákat is kitakarja, így nehezebb lesz megtalálni a valódi okot.
Ráadásul a webshopoknál a cache-nek megvannak a maga csapdái. A kosár, a pénztár és a fiók oldalait ki kell zárni belőle, különben a látogatók egymás kosarát látják — ez nem elméleti veszély, hanem a rosszul beállított gyorsítótárak klasszikus hibája. Ezért kerül ez a lépés az ötödik hely után, és nem az elsőre.
7. Szerver cron nagy látogatottságnál
A WordPress ütemezett feladatai alapból nem futnak maguktól: a WP-Cron akkor indul el, amikor épp jön egy látogató. Kis oldalon ez tökéletesen elég. Nagy forgalomnál viszont azt jelenti, hogy a látogatóid fizetik meg — a saját oldalbetöltésük idejével — a hírlevélküldést, a feedgenerálást és a többi háttérfeladatot.
A megoldás egyszerű: a WP-Cron kikapcsolása és helyette valódi szerveroldali cron beállítása pár percenként. Ettől a háttérfeladatok kiszámítható időben futnak, a látogató pedig nem vár rájuk. Ugyanez véd a másik véglettől is: az alacsony forgalmú oldalakon a WP-Cron néha egyáltalán nem fut le, és az ütemezett bejegyzés vagy a mentés csendben elmarad.
8. Crawl botok: kit szolgálsz ki valójában?
Mielőtt bárki nagyobb szerverre költene, érdemes megnézni, kire megy el a kapacitás. A szerver access logja erre pontos választ ad, és gyakran kiderül belőle, hogy a forgalom jelentős része nem is ember. Vannak közöttük hasznos keresőrobotok, vannak AI-tréninghez gyűjtő crawlerek, és vannak olyan szkriptek, amelyek másodpercenként tucatnyi kérést tolnak be minden mértéktartás nélkül.
A legdrágább minta a szűrőkombinációk végigjárása. Egy webshopban a szűrőparaméterek kombinációiból gyakorlatilag végtelen számú különböző URL keletkezik, és ezek egyike sem szolgálható ki gyorsítótárból — mindegyik teljes PHP- és adatbázis-futást jelent. Egy ilyen crawl önmagában térdre tudja kényszeríteni azt az oldalt, amely valódi látogatókkal simán elbírna.
A megoldás a logból indul: megnézzük, mely user agentek és IP-tartományok viszik el a kéréseket, majd a feleslegeseket kizárjuk — lehetőleg szerverszinten, még azelőtt, hogy a WordPress egyáltalán elindulna. Ez a részlet fontosabb, mint amilyennek hangzik: ha a kitiltott bot hibaüzenet helyett mégis egy teljes, WordPress által legenerált oldalt kap vissza, akkor a terhelés nagy részét megtartottuk. A hasznos keresőrobotokat közben nem bántjuk — a cél nem a láthatatlanság, hanem hogy a kapacitás az emberekre menjen.
9. És csak a legvégén: a tárhely
Ha az összes fenti lépés megvan, és az oldal még mindig lassú, akkor jön a szolgáltató. Ilyenkor nem nagyobb csomagot kérünk, hanem egy konkrét kérdést teszünk fel: melyik erőforrás fogy el? A PHP-folyamatok száma, a processzoridő, a memória vagy a lemez I/O? A válasz alapján derül ki, hogy tényleg bővítés kell-e, vagy csak egy limit áll rosszul.
Ez a sorrend utolsó lépése, és jó okkal. Egy nagyobb csomag megvásárlása mérés nélkül nem megoldja a problémát, csak megfizeti: a lassú lekérdezés drágább szerveren is lassú lekérdezés marad.
A lista egyben
| Lépés | Mit derít ki vagy old meg | Mikor hoz sokat |
|---|---|---|
| 1. Query Monitor | Melyik bővítmény és melyik lekérdezés viszi az időt | ✔ Mindig ezzel kezdünk |
| 2. Autoloaded options | Minden kérésnél betöltött felesleges adat | ✔ Régi, sokat bővítgetett oldalon |
| 3. SQL indexek | Lassú szűrés és rendezés nagy katalóguson | ◐ Sok termék vagy meta mező esetén |
| 4. WooCommerce HPOS | Rendelések külön, gyors táblákban | ✔ Sok rendelésnél, ha még nincs bekapcsolva |
| 5. Bővítmények | Elavult és felesleges kód kiváltása | ◐ Igényfelmérés után, egyedi kóddal |
| 6. Gyorsítótár | A kiszolgálás gyorsítása — nem a hibák javítása | ✖ Önmagában, rendrakás előtt nem |
| 7. Szerver cron | Háttérfeladatok leválasztása a látogatóról | ◐ Nagy forgalomnál |
| 8. Crawl botok | A nem emberi forgalom kiszűrése az access log alapján | ✔ Ha a terhelés nem áll arányban a látogatókkal |
| 9. Tárhely | Melyik erőforrás fogyott el valójában | ✖ Csak legvégső esetben |
A tapasztalatunk az, hogy a kilencből ritkán kell mind a kilenc. A legtöbb „lassú a WordPress oldalam” eset az első három lépésben megoldódik — és ehhez egy fillérrel sem kell többet költeni tárhelyre. Ami viszont mindig kell: valaki, aki előbb megméri, mi történik, és csak utána nyúl hozzá.
Lassú a weboldalad, és nem tudod, hol kezdj hozzá? Vagy már mindent kipróbáltál, és nem mozdult semmi? Mondd el nekünk, és végigmegyünk rajta helyetted.