Miért lassú a WordPress oldalad? 9 ok, ami a weboldal sebességét visszafogja
Egyik nap megnézed az oldaladat és azt látod, hogy csigalassan tölt be. Törlöd a cache-t, frissítesz egy plugint, pár percig javul a helyzet, aztán újra lassú lesz. Ha ez ismerős, a weboldal sebességét nem érdemes kizárólag a sablon vagy a képek felől vizsgálni.
A látogató szempontjából a szerver, a PHP, az adatbázis, a háttérfolyamatok és a cache is beleszól abba, milyen gyorsnak érződik az oldal. Ebben a cikkben kilenc olyan okot nézünk meg, amelyet részben vagy egészben tárhelyszinten is kezelhetsz, konkrét mérésekkel, nem találomra telepített gyorsítópluginekkel.
Hogyan mérd meg a weboldal sebességét, mielőtt javítasz rajta?
Először rögzítsd az alapállapotot. Válassz ki egy konkrét URL-t – a főoldalt, egy webshop termékoldalát vagy a pénztárat –, majd mérd le legalább háromszor PageSpeed Insightsban vagy GTmetrixben. Futtass külön mobil- és asztali tesztet, és jegyezd fel, hogy a mérés előtt üres volt-e a cache.
A pontszám önmagában kevés. Nézd meg a TTFB-t (Time To First Byte) is, ez azt mutatja meg, mennyi idő telik el a kérés elküldése és az első szerverválasz között. Képzeld el úgy, mintha étteremben várnál: a TTFB azt mutatja, mennyi idő alatt kezdi el a konyha elkészíteni a rendelésedet. Ha ez az idő következetesen magas, az oldalon végzett finomhangolás nem oldja meg a szerveroldali várakozást.
A waterfall nézetben válaszd szét a rétegeket: mennyi időt vesz igénybe a szerverválasz, a képek, a JavaScript-fájlok és a külső szolgáltatások betöltése. Így kiderül, hogy a WordPress lassú feldolgozása, egy túl nagy kép vagy egy marketinges script fogja-e vissza az oldalt. Ezután egyszerre csak egy tényezőn változtass, majd ugyanazzal a módszerrel mérj újra.
Miért lassú a WordPress oldalad? 9 tárhelyszintű ok
1. Túlterhelt az osztott szerver
Ha az oldal terhelés nélkül is lassú, a TTFB napszakonként változik, kampányforgalomnál pedig egyszerre romlik több URL teljesítménye, akkor vizsgáld meg a szerver erőforrásait. Osztott tárhelyen több weboldal használja ugyanannak a szervernek a CPU-, memória- és lemezerőforrásait. Ha az egyik „szomszéd” nagy terhelést generál, abból nálad is várakozás lehet.
Nézd meg a CPU-, RAM- és I/O-limiteket, és ellenőrizd, hogy a lassulás több oldalon is jelentkezik-e. Ha a csomag rendszeresen eléri a korlátait, a megoldás egy megfelelőbb erőforrású vagy teljesítményre optimalizált környezet, mint a LiteSpeed webszerver. Ha a szerver éri el a limitet, egy újabb cache-plugin nem ad több CPU-t.
2. Hiányzik a perzisztens objektum-cache
A publikus, gyorsítótárazott oldal lehet rendben, miközben a keresés, a kosár vagy a belépve használt adminfelület lassú. Ilyenkor a WordPress sokszor minden kérésnél újra lefuttatja ugyanazokat az adatbázis-lekérdezéseket – mintha a raktáros minden alkalommal a teljes raktárat átkutatja, hogy megtalálja ugyanazt a terméket.
A Site Healthben és a cache-rendszer beállításaiban nézd meg, aktív-e a persistent object cache. A Redis vagy más támogatott megoldás csak helyes konfigurációval segít. Egy átlátható cache-réteg többet ér, mint több, egymásra halmozott plugin.
3. Lassú vagy túlterhelt az adatbázis
A „lassú wordpress” probléma gyakran az adminban, a termékkeresésnél, a szűrőknél vagy a WooCommerce pénztárában látszik először, miközben egy egyszerű statikus oldal gyors marad. Oka lehet a túl sok autoloadolt beállítás, felhalmozott revízió és transient, nagy naplótábla, hibás plugin vagy kevés adatbázis-erőforrás.
Ha főleg a keresés, a szűrés vagy a pénztár lassú, érdemes megnézni, melyik bővítmény vagy funkció terheli túl az adatbázist. Mindig készíts friss mentést, aztán kezdd a legegyszerűbbel: töröld a fölösleges bővítményeket, ritkítsd a revíziókat, és kérj segítséget a szolgáltatótól vagy fejlesztőtől, ha egy konkrét plugin körül látszik a gond. A tárhely stabil MySQL- vagy MariaDB-környezetet ad, de a lassulást okozó bővítményt vagy kódot külön kell rendbe tenni.
Ha a tárhelyed LiteSpeed webszerveren fut, a LiteSpeed Cache bővítmény képes az adatbázisban kitakarítani a felgyűlt revíziókat és transienteket, az Object fülön pedig bekapcsolható Redis vagy Memcached objektum-cache, ami az adminra, a kosárra és a pénztárra is hat.
4. Az optimalizálatlan képek túl sok adatot töltenek le
Ha a waterfall nézetben a hero-kép és a termékfotók foglalják el a legtöbb időt, először a képfájlokat vizsgáld meg. Használj a megjelenési mérethez illeszkedő képet, WebP- vagy AVIF-formátumot, tömörítést és lazy loadingot. Add meg előre a képek szélességét és magasságát is, hogy ne ugráljon a layout.
A gyors szerver nem tudja eltüntetni a több megabájtos fájlokat. A LiteSpeed Cache és a CDN gyorsabban szolgálhatja ki őket, de az alapanyag méretét neked kell ésszerűre szabni. Az előtte–utána mérésben ne csak pontszámot, hanem az oldal teljes adatméretét és az LCP (Largest Contentful Paint) értékének változását is vizsgáld meg.
5. Külső scriptek várakoztatják az oldalt
Előfordul, hogy a saját szervered gyorsan válaszol, mégis lassú az első megjelenés. A Google Analytics, a Meta Pixel, a chat, a reklámrendszer vagy egy külső betűkészlet-szolgáltató külön kéréseket indít, amelyek késhetnek vagy blokkolhatják a renderelést.
A waterfallban azonosítsd a harmadik féltől érkező kéréseket. Csak a szükséges scriptek maradjanak, a többi töltődjön
defer vagy async módban, illetve csak akkor induljon el, amikor valóban szükséges. Ezt a tárhely önmagában nem javítja meg, de a mérés megakadályozza, hogy egy külső szolgáltatás hibáját a szerverre fogd.6. Az admin-ajax.php túl sok kérést kap
A WooCommerce-kosárfrissítések, pluginok vagy a WordPress Heartbeat sok háttérkérést indíthatnak. Tünet, ha a frontend és az admin egyszerre lassul, vagy a böngésző Network panelje folyamatos
admin-ajax.php-hívásokat mutat.Query Monitorral, a Network panellel és szerverloggal keresd meg, melyik plugin és milyen gyakorisággal küldi a kéréseket. Csökkentsd a háttérben futó, ismétlődő szerverkéréseket — a WordPress ezeket Heartbeat néven küldi —, a kosarat és a bejelentkezett felhasználók oldalait pedig vedd ki a gyorsítótárazásból. A tárhely naplózást és erőforrást ad a kivizsgáláshoz, a felesleges hívást viszont az okozó kódnál kell megszüntetni.
7. A wp-cron látogatók érkezésekor fut le
A WordPress alapértelmezett ál-cron rendszere oldalbetöltéshez kötheti a háttérfeladatokat. Egy nagyobb webshopnál importok, feedek, e-mailek vagy biztonsági műveletek indulhatnak el éppen a látogató kérésére, ezért időnként megugrik a válaszidő.
A tárhelyen állíts be valódi szerveroldali cronfeladatot, a WordPress ál-cronját pedig kapcsold ki. Ellenőrizd a futási naplót és a gyakoriságot: egy termékimport más ütemezést igényel, mint egy óránkénti karbantartás. Így a háttérmunka tervezhető időben, nem a látogató várakozásából vesz el.
Nem tudod, hogyan vidd át a wp-cron-t a tárhely cron feladatai közé? Az alábbi útmutatónk alapján könnyen meg tudod ezt tenni, így növelve a WordPress weboldal sebességét: admin-ajax.php és wp-cron.php erőforrás használatának csökkentése
8. Régi PHP-verzió fut a tárhelyen
Régi PHP-verzió mellett lassabb lehet a feldolgozás, és a friss bővítmények kompatibilitási hibákat jelezhetnek. Válts a tárhelyen elérhető támogatott verzióra, de a váltást mindig friss mentés és lehetőleg stagingteszt előzze meg.
A teszt során járd végig a főoldalt, a termékoldalt, a kosarat, a pénztárt, az űrlapokat és az admin kritikus részeit. Ha nem szeretnél rendszergazdává válni, olyan szolgáltatót válassz, ahol a PHP-váltás, a visszaállítás és a hibakeresés dokumentált, kezelhető folyamat.
9. Nincs CDN a távoli látogatóknak
Magyarországról elfogadható lehet a betöltés, miközben külföldről vagy mobilhálózatról már érezhetően lassú. A CDN a képeket, CSS- és JavaScript-fájlokat a látogatóhoz közelebbi pontról szolgálja ki, így csökkenti a hálózati távolságot.
A CDN nem javítja meg a lassú adatbázist és nem gyorsítja fel automatikusan a dinamikus WordPress-lekérdezéseket. Állítsd be a statikus fájlokra, ellenőrizd a cache-headereket, a tömörítést, a pénztárat, a bejelentkezést és a purge-folyamatot. A szerveroldali cache, a CDN és az optimalizált PHP együtt ad stabil eredményt.
Így haladj végig a WordPress weboldal gyorsításán
Nem kell mind a kilenc területhez egyszerre hozzányúlnod. Haladj abban a sorrendben, amelyik a leggyorsabban megmutatja, hol fogy el a teljesítmény és mi miatt romlik a weboldal sebessége:
- Készíts alapmérést, és rögzítsd a TTFB-, LCP-, összadat- és kérésértékeket.
- Nézd meg, a szerver oldalán van-e szűk keresztmetszet: ellenőrizd a CPU-, RAM- és I/O-limitjeit több napszakban.
- Ellenőrizd a gyorsítótárazást: nézd meg a page cache és az objektum-cache állapotát, külön a publikus oldalaknál és a belépés után használt részeknél.
- Ezután keresd meg, mi terheli az adatbázist és az admin-ajax.php hívásokat: gyakran egy plugin, szűrő vagy háttérfolyamat lesz a valódi ok.
- Ha ezek rendben vannak, válts támogatott PHP-verzióra, és állíts be valódi cronfeladatot stagingteszt után.
- Ezután optimalizáld a képeket, a külső scripteket és a CDN-t.
- Végül mérj újra ugyanazon az URL-en, ugyanazzal az eszközprofillal, hogy pontosan lásd, mi javult.
Ha már az első mérésnél magas a TTFB és elfogy a szervererőforrás, előbb a tárhely felől keress megoldást. Ha a szerver válasza gyors, de a waterfallban a képek, scriptek vagy külső szolgáltatások húzzák el a betöltést, akkor a front-end oldalon érdemes továbbmenni. Ha ezt nem akarod egyedül végigvinni, a Sybell Hosting karbantartási és tárhelyszolgáltatási környezete leveszi rólad az infrastruktúra egy részének kezelését.
Hogyan bizonyítsd, hogy tényleg gyorsult az oldal?
Az előtte–utána összehasonlítást ugyanazon az URL-en, hasonló napszakban és azonos mobil- vagy asztali profillal futtasd. A riportban szerepeljen a TTFB, az LCP, a teljes letöltött adat, a kérések száma és a két eszköztípus eredménye.
Készíts két screenshotot: az első mutassa a kiinduló állapotot és a feltárt okot, a második pedig a beavatkozás utáni értékeket. A cél nem minden projektnél a maximális pontszám, hanem a stabil, ismételhető javulás a főoldalon, a termékoldalakon és a pénztárban.
Mikor érdemes tárhelyet váltani?
A váltást akkor érdemes megfontolni, ha több mérésben magas TTFB-t látsz, a csomag rendszeresen eléri az erőforrás-limitet, nem érhető el objektum-cache vagy modern PHP, nincs valódi cron-kezelés, illetve a szolgáltató nem ad értelmezhető hibakeresési adatot.
A kívánt állapot egy olyan infrastruktúra, ahol a cache, a PHP, az adatbázis, a cron és a CDN együtt kezelhető. Nem kell azonnal költöztetési projektet indítanod: mérd le ugyanazt az oldalt, egyeztesd a TTFB-t és az erőforrás-használatot, majd kérj tárhelypróbát vagy fokozatos migrációt.
Ha a mérések a szerverrétegre mutatnak, a Sybell Hosting LiteSpeed szerverein futó tárhelycsomagjaival a WordPress weboldal sebességének javításához szükséges több fontos elemét egy helyen kezelheted. Így nem külön-külön próbálod megoldani a cache, a PHP és az erőforrások problémáját.
Összegzés: a weboldal sebesség javítása méréssel kezdődik
A lassú WordPress oldal mögött gyakran nem egyetlen plugin áll, hanem a szerver, a cache, az adatbázis és a háttérfolyamatok együttese. Mérd le háromszor ugyanazt az oldalt, nézd meg a TTFB-t és a tárhely-erőforrásokat, majd mindig a legnagyobb késleltetést okozó rétegen változtass.
Ha azt látod, hogy a lassulás főleg a tárhelyrétegnél dől el, érdemes olyan környezetre váltani, ahol a gyorsítás alapból része a szolgáltatásnak.
A Sybell Hosting webtárhelyei LiteSpeed webszerveren futnak, így használhatod velük a LiteSpeed Cache bővítményt, amivel még nagyobb gyorsaságot érhetsz el. A tárhelyet kérheted ingyenes költöztetéssel, előretelepített WordPressel vagy Prémium hardverrel. Így nemcsak gyorsabb környezetbe költözöl át, hanem a beállítások és a költöztetés terhét is levesszük a válladról. A weboldal sebesség így már nem kérdés többé.