Szinte minden WooCommerce teljesítmény vizsgálat ugyanúgy kezdődik. A boltvezető már átköltözött egy gyorsabb tárhelyre, telepített egy gyorsítótárazó bővítményt, vásárolt egy képoptimalizálót, a webáruház pedig továbbra is lassú. Ebből azt a következtetést vonja le, hogy a WooCommerce egyszerűen nehézkes, és feladja a küzdelmet.

A WooCommerce valóban nehezebb, mint egy egyszerű bemutatkozó oldal, és ez elkerülhetetlen akkor, amikor minden oldalnak kosarat kell tudnia vinni. Csakhogy egy webáruház, amely hat másodperc alatt tölt be, nem ettől az alapterheléstől szenved. Valami konkréttól szenved, és a tapasztalatom szerint ez majdnem mindig négy dolog egyike.

Röviden: a webáruházak azért lassúak, mert a kosár és a pénztár oldalait nem lehet teljes oldalas gyorsítótárból kiszolgálni, mert az options tábla óriásira nőtt az automatikusan betöltött szeméttől, mert a termékekre irányuló lekérdezések egy indexeletlen metaadat-táblát pásztáznak, és mert harminc bővítmény mindegyike a saját szkriptjeit teszi rá minden oldalra. A tárhely az utolsó dolog, amit érdemes megváltoztatni, nem az első.

Miért más egy webáruház, mint egy blog

Egyetlen különbség magyarázza a WooCommerce teljesítményével kapcsolatos viselkedés nagy részét.

Egy blogbejegyzés minden látogató számára ugyanaz, tehát egyszer legenerálható, és onnantól mindenki a gyorsítótárból kapja meg. Ezért gyorsak a bemutatkozó oldalak szinte függetlenül attól, hogyan készültek. Egy webáruház ezt nem teheti meg minden oldalán, mert a kosár személyes. Abban a pillanatban, amikor a látogató beletesz egy terméket, az oldalnak az ő saját állapotát kell tükröznie, nem egy mindenkivel közös másolatot.

Ennek az a következménye, hogy a kosár, a pénztár és a fiók oldalai teljesen megkerülik az oldalgyorsítótárat, és minden egyes kérésnél lefuttatják a PHP kódot és az adatbázis-lekérdezéseket. Ezek egyben azok az oldalak is, ahol a lassúság közvetlenül pénzbe kerül. Egy lassú kategórialap a nézelődőket veszíti el, egy lassú pénztár a vásárlókat.

A hasznos kérdés tehát soha nem az, hogy gyors-e az oldalam. Hanem az, hogy milyen gyors az oldalam egy bejelentkezett látogatónak, akinek van valami a kosarában. Kifejezetten ezt az állapotot tesztelje, mert ettől függ a bevétele, és éppen ezt hagyja ki minden szintetikus sebességmérés.

A négy dolog, ami valójában el van rontva

A túlterhelt options tábla. A WordPress minden egyes kérésnél betölt egy adag beállítást, a bővítmények pedig szabadon írnak bele. Az eltávolított bővítmények rendszerint ott hagyják a soraikat. Régebbi webáruházakban ez a tábla több tíz megabájtnyi automatikusan betöltött adatra hízik, amelyet minden oldalletöltésnél beolvas a rendszer, a pénztár oldalán is. Ez láthatatlan, évek alatt halmozódik fel, és a legjobb megtérülésű javítások közé tartozik. Először az automatikusan betöltött beállítások összméretét nézze meg; ha ezt megabájtban és nem kilobájtban mérik, akkor valódi időt talált.

Indexeletlen metaadatokon futó terméklekérdezések. A WooCommerce történetileg egy általános, mindennel közösen használt metaadat-táblában tárolta a terméktulajdonságokat, az árakat és a készletet. Egy nagy katalógus szűrése vagy rendezése azt jelenti, hogy ezt a táblát újra és újra össze kell kapcsolni. Néhány száz terméknél ezt senki nem veszi észre. Több tízezernél a kategória- és szűrőoldalak vánszorogni kezdenek. Az újabb WooCommerce verziók éppen ezért helyezték át a rendelési adatokat saját táblákba, és ennek a tárolásnak a bekapcsolása egy hosszú rendelési előzménnyel rendelkező boltban rendszerint önmagában is megéri.

Bővítmények és külső hívások

Bővítmények elburjánzása a kritikus útvonalon. A gond ritkán maga a darabszám; sokkal inkább az, hogy a legtöbb bővítmény minden oldalra beteszi a saját CSS és JavaScript fájljait ahelyett, hogy csak ott tenné, ahol szükség van rájuk. Egy foglalási bővítmény, amelyet egyetlen oldalon használ, a pénztár oldalára is betölti az állományait. A megoldás nem látványos: nézze át, mit tölt be az egyes bővítmény, vegye ki a betöltést a saját oldalain kívül, és távolítson el mindent, aminek nem tudja megnevezni a funkcióját.

Gyorsítótárazás nélküli külső hívások. Az élő szállítási díjak, az adószámítás, a valutaváltás és a külső rendszerből történő készletellenőrzés mind egy hálózati kérést helyeznek az oldalbetöltés közepébe. Ha az adott szolgáltató lassú, a pénztára is lassú, ha pedig kiesik, a pénztára is kiesik. Minden külső hívásnak, amely benne van a kérés útvonalában, kell egy időkorlát, egy gyorsítótár és egy tartalék megoldás arra az esetre, ha a másik fél nem válaszol. A külső API-k integrálásáról szóló útmutatónk bemutatja, hogyan kell ezt megépíteni.

Ami valóban segít, ebben a sorrendben

Haladjon végig ezeken sorban, mert mindegyik megváltoztatja azt, amit a következő mérés mutat majd.

Objektum-gyorsítótár, nem csak oldalgyorsítótár. Az oldalgyorsítótár teljes HTML oldalakat szolgál ki, és a kosáron vagy a pénztáron nem tud segíteni. Egy tartós objektum-gyorsítótár az adatbázis-lekérdezések eredményét tartja a memóriában, és pontosan azokat az oldalakat gyorsítja, amelyekhez az oldalgyorsítótár hozzá sem ér. Egy webáruház esetében rendszerint ez az egyetlen legnagyobb elérhető javulás, és egyben ez az a lépés, amelyet a leggyakrabban kihagynak, mert a már telepített gyorsítótárazó bővítmény azt a benyomást keltette, hogy a munka kész.

Adatbázis-karbantartás. Törölje a lejárt tranziens bejegyzéseket, távolítsa el a törölt termékek és rendelések árva metaadatait, és ritkítsa a bejegyzésváltozatokat. Egy évek óta működő boltban ez rutinszerűen az adatbázis jelentős részét takarítja el. Ezt ütemezze rendszeres feladatként, ne egyszeri nagytakarításként végezze el.

Utána a tárhely. Ha a gyorsítótárazás és az adatbázis rendben van, a tárhely valóban számít: a PHP verziója, a rendelkezésre álló memória, az, hogy az adatbázis ugyanazon a gépen fut-e, és hogy osztott tárhelyen versenyez-e más bérlőkkel. A fentiek javítása előtt költözni azonban csak áthelyezi a problémát egy drágább címre.

A statikus fájlok a végén. A képformátumok, a késleltetett betöltés és a szkriptek halasztása megéri, és a legtöbb útmutató éppen ezekkel kezd. Ezek olyan oldalak betöltési élményét javítják, amelyeket a rendszer amúgy is elfogadható tempóban szolgált ki. Egy pénztár oldalon, amely négy másodpercet tölt PHP-ban, mielőtt az első bájtot elküldené, nagyon keveset érnek.

A WooCommerce teljesítmény helyes mérése

A szintetikus pontszámok a boltvezetőket vezetik félre a leginkább, ezért mérjen tudatosan.

Tesztelje a bejelentkezett, megtöltött kosaras állapotot. A legtöbb eszköz egy névtelen látogatót tesztel a főoldalon, vagyis a lehető leggyorsabb útvonalat az oldalán, és ez szinte semmit nem árul el a pénztárról.

Válassza szét a szerveridőt és a böngészőoldali időt. Ha a szervernek három másodperc kell a HTML előállításához, semmilyen képoptimalizálás nem menti meg az oldalt. Az első bájtig eltelt idő megmutatja, a probléma melyik feléről van szó, és ezzel azt is, hogy a fenti javítások közül melyik érvényes.

Ahol lehet, terepadatokat használjon laboratóriumi adatok helyett. A valódi látogatók valódi kapcsolaton és valódi telefonon egészen más képet adnak, mint egy adatközpontban futtatott teszt, és a Core Web Vitals értékelése az előbbin alapul. A WordPress teljesítményauditról szóló útmutatónk elmagyarázza, hogyan kell helyesen olvasni ezeket a mutatókat, a Core Web Vitals 2026-ban pedig azt, hogy a küszöbértékek valójában mit követelnek meg.

Végül figyelje közvetlenül az adatbázist egy lassú kérés közben. Egy lekérdezési napló, amelyen ugyanaz a lekérdezés kétszázszor fut le egyetlen oldalbetöltés alatt, azonnal megnevezi a bűnöst, és ez a minta rendkívül gyakori azokban a boltokban, amelyek több olyan bővítményt futtatnak, amelyek mindegyike külön kéri le a termékadatokat.

Mennyibe kerül ez a munka

Az alábbi árak egy közepes méretű webáruházra vonatkozó szokásos brit ügynökségi díjakat tükrözik.

Egy teljesítményaudit, amely azonosítja a konkrét okokat, priorizált javítási listát ad, és mérésekkel szolgál előtte és utána is, jellemzően 900 és 2500 font között mozog. Ez diagnosztikai munka, és érdemes külön megvásárolni, mert megmondja, hogy a hátralévő munka egy hét vagy egy hónap.

A szokásos javítások elvégzése, vagyis az objektum-gyorsítótár, az adatbázis takarítása, a bővítmények által betöltött fájlok átvizsgálása és a külső hívások gyorsítótárazása, általában 2000 és 6000 font közé esik attól függően, mennyi minden halmozódott fel.

A mélyebb munka többe kerül, mert ez már valódi fejlesztés. Egy nagy katalógus átköltöztetése indexelt tárolásra, egy metaadatokat pásztázó szűrőrendszer újraépítése vagy egy lassú bővítmény célzott egyedi megoldásra cserélése jellemzően 6000 és 20 000 font közé esik.

Minden ezeknél fontosabb szám az, hogy mennyibe kerül önnek a lassúság. A vásárlás megszakításának aránya mérhetően nő a betöltési idővel, így egy érdemi forgalmat bonyolító webáruház az auditot rendszerint már önmagában a pénztár oldalával is igazolni tudja.

A boltot javítsa meg, ne a pontszámot

A Mecanik a WooCommerce teljesítménnyel kapcsolatos munkát a WordPress fejlesztési szolgáltatásunk részeként végzi, és azzal kezdjük, hogy a bejelentkezett pénztár útvonalat mérjük, nem a főoldalt, mert a boltok valójában ott veszítenek pénzt.

Megnézzük az automatikusan betöltött beállításokat, a rendelések tárolását, a lekérdezési mintákat és a külső hívásokat, mielőtt tárhelyváltást javasolnánk, és odaadjuk a méréseket előtte és utána is, hogy a javulás ellenőrizhető legyen, ne csak állítás. Ha a webáruháza azért lassú, mert kinőtte a platformot, és nem azért, mert rosszul van beállítva, ezt is megmondjuk: a Shopify és az egyedi e-kereskedelem összehasonlítása pontosan megmutatja, hol húzódik ez a határ.

Küldje el nekünk a webcímet, és nagyjából azt, hogy hány terméket és rendelést tart a bolt, mi pedig megmondjuk, a fenti négy ok közül melyikkel áll szemben a legnagyobb valószínűséggel.

Kapcsolódó bejegyzések: WordPress feltörve: kártevő eltávolítása és mentés , E-kereskedelmi üzlet skalázása az Egyesült Királyságban: 2026 , Drupal fejlesztő felvétele: díjak, készségek, szűrés , Mennyibe kerül egy weboldal az Egyesült Királyságban .

Gyakran ismételt kérdések

Miért lassú a WooCommerce oldalam, pedig van gyorsítótárazó bővítményem? Az oldalgyorsítótárazás nem alkalmazható a kosár, a pénztár és a fiók oldalaira, mert ezeknek minden látogató saját állapotát kell tükrözniük. Ezek az oldalak minden kérésnél lefuttatják a PHP kódot és az adatbázis-lekérdezéseket, ezért a gyorsításukhoz objektum-gyorsítótárra és adatbázis-munkára van szükség, nem oldalgyorsítótárra.

Megoldja a jobb tárhely a WooCommerce teljesítmény gondjait? Csak részben, és nem ez legyen az első lépés. Ha az options tábla felpuffadt, a lekérdezések indexeletlenek, és a bővítmények mindenhová betöltik a fájljaikat, a jobb tárhely ugyanezeket a bajokat teszi valamivel gyorsabbá, magasabb áron. Előbb a gyorsítótárazást és az adatbázist hozza rendbe, utána értékelje újra a tárhelyet.

Hány bővítmény már túl sok egy WooCommerce boltban? A darabszám kevésbé számít, mint az, hogy mit tölt be az egyes bővítmény. Húsz jól nevelt bővítmény, amely csak a saját oldalain tölt be fájlokat, kevesebb kárt okoz, mint nyolc, amely az egész oldalon szórja a szkriptjeit. Nézze át, mit ad hozzá mindegyik a pénztárhoz, és távolítsa el azt, aminek a célját senki nem tudja megfogalmazni.

Mennyibe kerül a WooCommerce sebességoptimalizálása? Egy diagnosztikai audit priorizált javítási listával jellemzően 900 és 2500 font közé esik. A szokásos javítások, például az objektum-gyorsítótár, az adatbázis takarítása és a betöltött fájlok átvizsgálása általában 2000 és 6000 font között van, míg a katalógus vagy a szűrők átépítése elérheti a 6000 és 20 000 font közötti sávot.

Hogyan teszteljem helyesen a WooCommerce teljesítményt? Bejelentkezett látogatóként tesztelje, kosárban lévő termékekkel, ne névtelen főoldal-látogatásként. Válassza szét a szerver válaszidejét a böngészőoldali megjelenítéstől, hogy lássa, melyik fele lassú. Ezenkívül valódi látogatóktól származó terepadatokra támaszkodjon, ne csak a laboratóriumi pontszámokra.