Miért lassú a WordPress-oldalam? Hibakeresés lépésről lépésre

A WordPress gyorsítása útmutató azt mutatja meg, mit érdemes beállítani. Ez az írás előbb jön: azt segít kideríteni, mi lassítja az Ön konkrét oldalát. A két lépés különbsége fontos, mert a rossz helyen végzett optimalizálás időt visz és semmit nem hoz.

1. Mérje meg, hol vész el az idő#

Egy oldal betöltése három szakaszra bontható:

1. A szerver válaszol (a böngésző kér, a szerver összerakja és elküldi az első adatot). Ennek az időnek a mérőszáma a TTFB (time to first byte).
2. A böngésző letölti a képeket, stíluslapokat és szkripteket.
3. A böngésző megjeleníti az oldalt, és lefuttatja a szkripteket.

A böngésző fejlesztői eszközével ez néhány kattintással megnézhető: nyomja meg az F12 gombot, nyissa meg a Network (Hálózat) fület, töltse újra az oldalt, és kattintson a lista első sorára (az oldal saját címére). A Timing részben a Waiting for server response az az idő, amíg a szerver az első adatot elkészítette.

A web.dev (a Google fejlesztői oldala) szerint a legtöbb oldalnak a TTFB-t érdemes körülbelül 0,8 másodperc alatt tartania. Ez útmutató, nem szigorú határ, de jó kiindulás: ha az első kérés ennél lényegesen tovább tart, a szerveroldalon keresse a hibát; ha gyors, de az oldal mégis lassan áll össze, a második és a harmadik szakaszt vizsgálja.

2. Ha a szerver válasza lassú#

Itt a leggyakoribb okok a következők.

Nincs oldal-gyorsítótár. Gyorsítótár nélkül a WordPress minden látogatónál lefuttatja a PHP-kódot és lekérdezi az adatbázist. Egy oldal-gyorsítótár (page cache) bővítmény ezt kiváltja a kész oldal kiszolgálásával. Részletek: WordPress gyorsítása.

Egy lassú bővítmény. Egy rosszul megírt bővítmény minden oldalletöltést lassíthat. A Query Monitor bővítmény megmutatja, melyik bővítmény vagy sablon mennyi adatbázis-lekérdezést és időt használ. A Health Check & Troubleshooting bővítmény hibakeresési módja pedig csak az Ön munkamenetére kapcsolja ki a bővítményeket és vált alapértelmezett sablonra, így a látogatók nem látnak semmit. Ha így gyors az oldal, a bővítményeket egyenként visszakapcsolva megtalálhatja a tettest.

Nagy, felpuffadt adatbázis. A WordPress minden oldalletöltéskor betölti az adatbázis autoload jelölésű beállításait. Ha egy bővítmény sok adatot hagy ott ezek között (a bővítmény eltávolítása után is), minden kérés lassul. Újabb WordPress-verziók a Site Health (Eszközök → Webhely állapota) oldalon jelzik, ha az autoload adatok mérete túl nagy. Az adatbázis tisztítása előtt mindig legyen mentése.

Régi PHP-verzió. Az újabb PHP-verziók általában gyorsabbak, és csak a támogatott verziók kapnak biztonsági javítást. Lásd: Melyik PHP-verziót válasszam?

Az ütemezett feladatok (wp-cron). A WordPress a belső ütemezőjét a látogatók kéréseihez kapcsolja, így egy nehéz ütemezett feladat (például egy nagy mentés vagy egy webshop-szinkron) lassíthat egy kérést. Ha a lassulások időzítve jelentkeznek, ez is gyanús.

A szerver erőforrásai. Ha a fentiek rendben vannak, és az oldal terhelés alatt lassul, szóba jöhet a tárhely korlátja. Erről az 5. szakaszban írunk.

3. Ha a szerver gyors, de az oldal lassan áll össze#

Nézze meg a Network fülön, mi tölt le a legtöbbet és a legtovább (rendezheti méret és idő szerint).

• Nagy képek. Ha egy kép több száz kilobájtnál nagyobb, vagy sokkal nagyobb a méretezett megjelenésénél, ez a leggyakoribb ok. Lásd a méretezés, tömörítés és modern formátumok leírását a WordPress gyorsítása útmutatóban.
• Sok külső kérés. Betűtípusok, térkép, közösségi média beágyazás, csevegőablak, mérőkód: mindegyik külön kapcsolatot nyit, és a külső szolgáltatás lassúsága az Ön oldalát is lassítja. Ráadásul adatvédelmi következménye is lehet (GDPR a kisvállalkozói weboldalon).
• Nehéz sablon vagy oldalépítő. Ha minden oldalon több száz kilobájt JavaScript és CSS töltődik be, még a gyors szerver sem segít. A könnyebb sablon vagy a blokkszerkesztő használata sokat számíthat.
• Renderelést blokkoló elemek. A PageSpeed Insights jelentése név szerint felsorolja ezeket.

4. A gyanúsítottak szűkítése, kockázat nélkül#

1. Készítsen mentést (fájlok és adatbázis).
2. Ha tud, dolgozzon másolaton vagy tesztkörnyezetben; ha nincs ilyen, válasszon kis forgalmú időpontot.
3. Változtasson egy dolgot, és mérjen újra.
4. Ha egy változtatás nem segít, állítsa vissza.
5. Jegyezze fel, mi mennyit hozott.

A sorrend: gyorsítótár, képek, a gyanús bővítmények, PHP-verzió, adatbázis. Az utóbbiak kockázatosabbak, ezért kerüljenek a végére.

5. Mikor lehet a tárhely a ludas?#

A tárhelycsomagok jellemzően megosztott környezetben futnak, és a szolgáltató korlátokat szabhat (futási idő, memória, egyidejű folyamatok). Ha az oldal csak terhelés alatt lassul vagy ad hibát (például 503-at), és a fenti lépések után sem javul, érdemes a szolgáltatót is megkérdezni, mit lát a szerveren.

Webshopnál különösen számít a tárhely és az adatbázis mérete: webtárhely webshopnak. Őszintén a hostio-ról: a csomagjaink leírása a tárhelyet, a forgalmat, a weboldalak, postafiókok és adatbázisok számát rögzíti. Teljesítményt (válaszidőt, processzor- vagy memóriahasználatot) és rendelkezésre állást nem vállalunk, ezért a mérésre és a fenti lépésekre építsen. Ha biztos benne, hogy az oldala erőforrás-igénye meghaladja a csomagját, nagyobb csomagra váltás vagy más megoldás jöhet szóba; ezt mindig mérés alapján döntse el.

Gyors ellenőrzőlista#

1. Mértem a TTFB-t és az oldal méretét (Network fül).
2. Van oldal-gyorsítótár, és működik.
3. A képek méretezettek és tömörítettek.
4. A bővítmények között nincs felesleges, és a gyanúsakat kipróbáltam.
5. A PHP-verzió támogatott.
6. A külső szolgáltatások száma minimális.

Gyakori kérdések#

Miért lassú a wp-admin, miközben a nyilvános oldal gyors?#

A nyilvános oldalt a gyorsítótár kiszolgálja, a szerkesztőfelületet viszont mindig élőben kell összeállítani. Ezért a bővítmények, a külső hívások és a nagy adatbázis az adminban jobban érződnek. A Query Monitor itt is megmutatja a lassú részeket.

Segít, ha nagyobb csomagra váltok?#

Csak akkor, ha a mérés erőforráshiányra utal. Ha az oldal a képek vagy egy lassú bővítmény miatt lassú, a nagyobb csomag ugyanazt a lassú oldalt futtatja. Előbb a fenti lépéseket végezze el.

Hány bővítmény a „sok”?#

Nem a darabszám számít, hanem az, hogy mit csinálnak. Húsz kicsi, jól megírt bővítmény kevesebbet lassít, mint egy nehéz oldalépítő. Mérje meg, ne találgasson.

Mi az az autoload, és én is tisztíthatom?#

Az autoload az adatbázis wp_options táblájának azon beállításai, amelyeket a WordPress minden kéréskor betölt. A tisztítás kockázatos, mert egy rossz sor törlése elronthat egy bővítményt. Csak mentés után, és lehetőleg a bővítmény készítőjének leírása alapján nyúljon hozzá.

Források#

• web.dev: Time to First Byte (TTFB)
• WordPress.org: Optimization (cache, adatbázis, PHP)
• Query Monitor és Health Check & Troubleshooting a WordPress.org bővítménytárában