Bence tíz éve foglalkozik WordPress-oldalak hibakeresésével és gyorsításával, ügynökségeknek és kisvállalkozásoknak egyaránt. Arról kérdeztük, miért lassú olyan sok magyar WordPress-oldal, és mit lehet tenni ellene egy délután alatt.
Mi az első, amit megnézel, amikor valaki azzal keres meg, hogy lassú az oldala?
A TTFB-t, vagyis a time to first byte értéket. Ez megmutatja, mennyi idő telik el a kéréstől az első bájt megérkezéséig. Ha ez két másodperc, akkor a gond a szerveroldalon van: a PHP vagy az adatbázis dolgozik túl sokat, vagy kevés az erőforrás. Ha a TTFB 200 milliszekundum alatt van, az oldal mégis lassan jelenik meg, akkor a böngészőben kell keresni a hibát: képek, scriptek, betűtípusok. A kettőt nagyon fontos külön kezelni, mert teljesen más a megoldásuk.
Melyik a gyakoribb?
Magyar kisvállalkozói oldalaknál szerintem fele-fele. A szerveroldali lassúság mögött szinte mindig a bővítmények állnak. Láttam már oldalt 64 aktív bővítménnyel, amiből három valójában ugyanazt csinálta. Mindegyik futtat valamit minden egyes oldalbetöltéskor.
Hány bővítmény a sok?
Nem a darabszám a lényeg, hanem hogy mit csinálnak. Egy jól megírt bővítmény szinte semmit nem lassít, egy rosszul megírt viszont minden oldalbetöltésnél lekérdezi a teljes adatbázistáblát. Én a Query Monitor nevű ingyenes bővítménnyel szoktam megnézni, melyik bővítmény hány lekérdezést futtat és mennyi ideig. Általában két-három bűnöst találok, a többi ártalmatlan.
A sablonok és oldalépítők mennyit rontanak a helyzeten?
Sokat, ha ész nélkül használják őket. Egy oldalépítővel könnyű olyan főoldalt rakni, ami tizenöt különböző modult tölt be, egy videós háttérrel és három csúszkával. Ez a böngészőnek rengeteg JavaScript és CSS. Nem az oldalépítő az ellenség, hanem a túlzsúfolt oldal.
Mit tud ezzel szemben a tárhely?
Sokat, de nem mindent. Ezt mindig el szoktam mondani az ügyfeleknek. Egy jó tárhely három dolgot ad: erős hardvert, főleg gyors processzort és NVMe-tárolót, többrétegű gyorsítótárat, és naprakész szoftverkörnyezetet. A gyorsítótár itt a kulcs. Ha a szerver a kész HTML-oldalt adja ki, a PHP és az adatbázis szóba sem kerül. Az objektum-gyorsítótár, például a Redis, a dinamikus oldalaknál segít, mert a gyakori lekérdezések eredményét memóriában tartja. Az OPcache pedig azt spórolja meg, hogy a PHP-kódot minden alkalommal újra kelljen értelmezni.
Ha valaki most választ, én olyan WordPress tárhelyre tenném az oldalát, ahol ezek a gyorsítótárak alapból elérhetők, választható a modern PHP-verzió, és van szerveroldali biztonsági védelem. De a rossz bővítményt a világ leggyorsabb szervere sem javítja meg.
Mi a helyzet a PHP-verzióval?
Ez a legolcsóbb gyorsítás, mégis rengetegen kihagyják. Egy 7.4-es PHP-n futó oldal egy 8.3-as vagy újabb verzióra váltva sokszor érezhetően gyorsabb lesz, kódmódosítás nélkül. Persze előtte tesztelni kell, mert a régi bővítmények egy része nem kompatibilis. Erre való a staging környezet.
És a képek?
Ott van a legkönnyebben elérhető nyereség. A mobilon megjelenő első nagy kép, a Largest Contentful Paint, a Google Core Web Vitals mutatói közül talán a leggyakrabban bukó érték. Négy szabály van: WebP vagy AVIF formátum, a megjelenítéshez illő méret, késleltetett betöltés minden képre, ami nem látszik azonnal, és a legfontosabb képnél soha ne legyen késleltetett betöltés. Ezt az utolsót sok bővítmény automatikusan elrontja.
Ha valakinek csak egy délutánja van, mit csináljon?
Négy dolgot, ebben a sorrendben. Egy: mentés. Kettő: PHP-verzió frissítése stagingen tesztelve. Három: Query Monitorral kiszűrni és lecserélni a két-három legrosszabb bővítményt. Négy: gyorsítótár-bővítményt beállítani, és összehangolni a szerveroldali cache-sel. Ez a négy lépés az esetek többségében több mint felére csökkenti a betöltési időt.
Végül: mikor jön el az a pont, amikor tényleg a tárhelyet kell lecserélni?
Ha a fentiek után a TTFB még mindig rendszeresen egy másodperc fölött van, vagy az oldal a forgalmasabb órákban belassul, akkor valószínűleg kinőtte a csomagot. Ilyenkor érdemes nagyobb erőforrású csomagot vagy dedikált környezetet választani. De sorrendben: először az oldal, aztán a szerver. Fordítva drága mulatság.