A lassú WordPress weboldal okát úgy találod meg, ha külön vizsgálod a szerver válaszát, a tartalom megjelenését és a kattintásokra adott reakciót. Egyetlen PageSpeed-pontszám nem mondja meg, melyik bővítményt kell lecserélni. Először a problémás oldalt és helyzetet azonosítsd, majd ugyanabban a mérési környezetben ellenőrizd a változtatás hatását.
Más feladat, ha reggel az adminisztráció akadozik, mint ha mobilon későn jelenik meg a főoldali kép. Az ajánlatkérő űrlap hosszú küldési ideje pedig akkor is zavaró lehet, ha maga az oldal gyorsan betöltődött. A hibakeresés kiindulópontja ezért egy konkrét megfigyelés legyen: melyik címen, milyen eszközön, melyik műveletnél kell várni?
Mit mérj egy lassú WordPress weboldalon?
A laboratóriumi mérés előre meghatározott körülmények között vizsgálja az oldalt. Jól használható egy lehetséges hiba feltárására és összehasonlítható próbákra. A valós felhasználói adatok azt mutatják meg, milyen élményt kaptak a látogatók saját eszközeiken és hálózataikon. A PageSpeed Insights dokumentációja külön kezeli ezt a két adatforrást; a jelentés olvasásakor ezt a különbséget is őrizd meg.
A három Core Web Vitals mutató eltérő problémára utal. Az LCP a fő tartalom megjelenésének idejét, az INP az interakciók utáni vizuális válasz késését, a CLS a váratlan elmozdulásokat jellemzi. A Google mutatókat bemutató útmutatója alapján ezeket együtt érdemes értelmezni. Egy hamar megjelenő oldal is lehet nehezen kezelhető, ha a menü megnyitása után hosszasan nem történik semmi.
Írd fel, hogy az eszköz URL-szintű vagy a teljes webhelyhez tartozó adatot mutat-e. Ha nincs elegendő valós felhasználói minta, abból nem következik, hogy az oldal gyors vagy lassú. Ilyenkor a laborpróbák, a saját megfigyelések és szükség esetén külön felhasználói mérés segíthetnek. A javítás után se várd, hogy egy korábbi időszakot összegző mutató azonnal kizárólag az új állapotot tükrözze.
A szerver és a gyorsítótár vizsgálatát válaszd külön a képektől
Ha a böngésző sokáig vár az első válaszra, érdemes a kiszolgálási oldalon keresni a szűk keresztmetszetet. Vizsgálandó a tárhely terhelése, a PHP-folyamatok rendelkezésre állása, a lassú adatbázis-lekérdezés és a külső szolgáltatásra várakozás. Az első bájtig eltelt idő, vagyis TTFB hasznos jelzés, de önmagában nem nevezi meg az okot.
A teljes oldal gyorsítótára egy korábban előállított választ adhat vissza, ezért csökkentheti az ismételt feldolgozást. Az objektumgyorsítótár más rétegen működik: bizonyos feldolgozási eredmények és adatok újbóli előállítását kerülheti el. A WordPress teljesítményútmutatója mindkettőt tárgyalja. A megfelelő megoldás a tárhely lehetőségeitől és az oldal működésétől függ; egy új cache-bővítmény telepítése még nem igazolja, hogy a lassulás oka megszűnt.
Mérd meg a kijelentkezett látogató és a belépett felhasználó útját is, ha mindkettő fontos. A nyilvános bemutatkozó oldal gyorsítótárból gyors lehet, miközben az adminisztráció vagy egy személyre szabott felület változatlanul lassú. Személyes adatok, kosártartalom és felhasználóhoz kötött eredmények közös gyorsítótárba kerülése hibás működést okozhat. A sebesség mellett ezért a helyes tartalmat is ellenőrizni kell.
Az adatbázis kézi takarítása előtt legyen visszaállítható mentés és ismert cél. Egy nagynak látszó tábla még nem bizonyított probléma, egy ismeretlen mező pedig lehet működéshez szükséges adat. Előbb lekérdezési és terhelési bizonyítékot kérj, csak utána törlést vagy szerkezetmódosítást.
Képek, sablon és külső szkriptek: azt javítsd, ami valóban terhel
Egy túlméretezett nyitókép késleltetheti a fő tartalom megjelenését. Ellenőrizd a ténylegesen letöltött képfájl méretét, a megjelenített mérethez való illeszkedését és a mobilváltozatot. Nem elég a médiatárban egy kisebb képet látni, ha a sablon továbbra is az eredeti nagy fájlt tölti le. A tömörítés eredményét vizuálisan is nézd meg: olvashatatlan képernyőkép vagy foltos termékfotó mellett a kisebb fájl nem jó végeredmény.
A késleltetett képbetöltést sem érdemes minden képre azonosan alkalmazni. A rögtön látható fő kép és az oldal alján lévő galéria eltérő szerepet kap. A javítás célja, hogy a szükséges tartalom megfelelő időben megérkezzen, ne pusztán kevesebb hálózati kérés szerepeljen egy jelentésben.
A bővítmények számából nem lehet pontos terhelést számolni. Egyetlen rosszul időzített külső lekérés többet árthat, mint több kis bővítmény. Különítsd el, mi fut minden oldalon, és mi csak egy adott funkciónál. A böngésző hálózati és teljesítményvizsgálata megmutathatja a hosszú letöltéseket, a várakozó kéréseket és a felületet foglaló munkát.
A chat, videó, térkép, betűkészlet és mérőkód üzleti funkciót is szolgálhat, ezért ne töröld őket automatikusan. Először vizsgáld meg, betölthetők-e csak ott és akkor, ahol szükségesek. Ha az ajánlatkérő oldalon a külső térkép akadályozza a kapcsolatfelvételt, a megjelenítés módja változhat anélkül, hogy a címadat eltűnne. A céges weboldal ajánlatkérési útvonaláról szóló cikkünk segít meghatározni, mely műveletek védelme a legfontosabb.
Így legyen összehasonlítható az előtte és utána mérés
Válassz néhány jellemző oldalt: főoldalt, fontos szolgáltatásoldalt, hosszabb cikket és kapcsolatfelvételi felületet. Ugyanazzal az eszközbeállítással, hasonló hálózati feltételek mellett végezz több próbát. Rögzítsd a dátumot, az URL-t, a belépési állapotot és a gyorsítótár állapotát. Egyetlen szokatlanul jó vagy rossz futás helyett a több mérésből kirajzolódó mintát értékeld.
- Írd le a hibát és a javítás feltételezett okát: például a szolgáltatásoldali fő kép túl nagy fájlból érkezik.
- Mentsd el a kiinduló eredményeket és a képernyőképet, továbbá a lényeges hálózati adatokat.
- Egy elkülönített környezetben változtass meg egy jól körülhatárolható tényezőt.
- Ismételd meg a mérést, majd ellenőrizd a megjelenést és az érintett funkciókat mobilon is.
- Csak igazolt javulás és működési ellenőrzés után vezesd be a változtatást, dokumentált visszaállítási lehetőséggel.
Szemléltető példa: mobilon későn látszik a szolgáltatásoldal nyitóképe, de a szerver válasza és a többi tartalom hamar megérkezik. Ilyenkor indokolt lehet a kép méretváltozatának és betöltési sorrendjének vizsgálata. Ha ehelyett minden dinamikus kérés hosszú várakozással indul, a kizárólagos képtömörítés valószínűleg nem a fő problémát kezeli. Ez vizsgálati logika, nem egy elvégzett ügyfélmérés eredménye.
Ne kapcsold ki egyszerre a sablont, az összes bővítményt és az összes külső kódot az éles oldalon. Így könnyen eltűnhet az űrlap vagy megváltozhat az oldal, miközben az ok továbbra sem különíthető el. A WordPress-karbantartás ellenőrzési menetében leírt mentési, próba- és visszaállítási szempontok a gyorsításnál is alkalmazhatók.
Mikor kérj célzott teljesítményvizsgálatot?
Akkor érdemes mélyebbre menni, ha a lassulás időszakos, bejelentkezéshez kötött, terhelés alatt jelentkezik, vagy üzletileg fontos műveletet érint. Kérj olyan eredményt, amely a problémás URL-eket, a reprodukálás módját, a feltárt okot és a javasolt beavatkozást összekapcsolja. A „telepítettünk egy optimalizálót” kevés információ az átadáshoz.
Az is fontos döntés, hogy javítható-e a meglévő szerkezet, vagy a sablon és a felépítés átalakítása indokolt. A weboldal megújításának és újraépítésének szempontjai ehhez adnak tágabb keretet. Egy lassú oldal miatt nem kell automatikusan új weboldalt rendelni.
A KovaBuild weboldalkészítési és továbbfejlesztési munkáinál a működő ajánlatkérési útvonal és a fenntartható technikai megoldás együtt számít. Ha célzott vizsgálatra van szükséged, küldd el nekünk a lassú oldal címét, az érintett műveletet és egy jellemző előfordulási időpontot. Ebből lehet mérhető feladatot meghatározni, garantált pontszám ígérete nélkül.