Lassú WooCommerce sok termékkel: a tárhely, a cache és az adatbázis rendbetétele

Évről évre bővítetted a termékeket, és most már csigalassú lett az áruházad. A kategóriaoldalak több hosszú másodpercig töltődnek, az admin minden mentésnél lefagy, a vásárlók pedig azelőtt lépnek le, hogy elérnék a fizetést. Ez nem a te hibád, és nem is a WordPressé: a WooCommerce képes motor, de több ezer termékkel megfelelően kell etetni.

A jó hír az, hogy a sebességproblémák nagy része három konkrét helyről ered: a tárhelyről, a cache kialakításából és az adatbázis állapotából. Nem kell újraépítened az áruházat. Meg kell értened, mi lassítja le az egyes kéréseket, és az okot kell kezelned, nem a tünetet. Az alábbiakban pontosan megmutatom, hol keresd a bajt és mit javíts, abban a sorrendben, ami számít.

Miért lassul le a WooCommerce, ahogy nő a katalógus

Egy néhány tucat terméket árusító áruház és egy több ezres ugyanazt a kódot futtatja, de nagyon eltérő terhelést ró a szerverre. Minden kategóriaoldal nehéz lekérdezéseket indít: szűrők, tulajdonságok, variációk, készlet, ár. Sok termékkel és variációval ezek a lekérdezések lelassulnak.

A tipikus probléma nem egyetlen ok, hanem egy lánc:

• adatbázis-lekérdezések, amelyek túl sok sort pásztáznak végig
• nincs cache, így minden látogató újra elvégzi ugyanazt a munkát
• megosztott (shared) tárhely, amely pont akkor fogja vissza az erőforrásokat, amikor szükséged van rájuk
• bővítmények, amelyek minden oldalhoz kódot adnak

Mielőtt bármit megvennél vagy új bővítményt telepítenél, mérj. A böngésződ eszközei (a Network fül) és egy olyan bővítmény, mint a Query Monitor, megmutatják, melyik kérés lassú és miért. Mérés nélkül vakon optimalizálsz.

Tárhely: itt dől el minden

Egy nagy katalógusnál a tárhely többet számít bármelyik sablonnál vagy bővítménynél. Az olcsó megosztott tárhely több száz oldalt zsúfol egyetlen szerverre; ha az egyik megterhelődik, mindegyik szenved.

Mire figyelj egy komoly áruháznál:

• friss PHP-verzió (a mostani kiadások érzékelhetően gyorsabbak a régieknél)
• elegendő PHP-memória, hogy a WooCommerce admin ne fulladjon meg
• olyan adatbázis-szerver, amelyet nem terhelnek túl más ügyfelek
• ideális esetben WordPress-orientált tárhely szerverszintű cache-eléssel

Ha megosztott tárhelyen vagy, és az admin minden termékmentésnél akadozik, az egyértelmű jele annak, hogy kinőtted a csomagot. Egy menedzselt VPS vagy dedikált WordPress-tárhely gyakran megoldja a problémák felét anélkül, hogy a kódhoz nyúlnál. Nem a legdrágább csomagra van szükséged, csak egy olyanra, amely nem lopja el az erőforrásaidat csúcsforgalomban.

Rétegelt cache-elés: ez nem egyetlen gomb

Sok tulajdonos telepít egy cache-bővítményt, alapbeállításokon hagyja, és csodálkozik, miért nem változott szinte semmi. A jó cache-elés rétegekben zajlik, mindegyiknek megvan a maga feladata.

• Oldal-cache (page cache): a nyilvános oldalak (kategóriák, termékek, blog) előre elkészítve kerülnek kiszolgálásra, anélkül hogy minden látogatásnál átmennének a PHP-n.
• Objektum-cache (Redis): az ismétlődő lekérdezések eredményei a memóriában tárolódnak. Nagy katalógusú WooCommerce esetén ez óriási különbséget jelent.
• Böngésző-cache: a statikus fájlok (képek, CSS, JS) a látogató oldalán maradnak, így a második oldal repül.
• CDN: a képeket és szkripteket a vásárlóhoz közeli szerverekről szolgálja ki.

Ügyelj arra, mit NE cache-elj: a kosárnak, a fizetésnek és a fióknak dinamikusnak kell maradnia. Egy rosszul beállított cache rossz árakat vagy készletet mutat. Ezeknek az oldalaknak a kizárása kötelező.

Az adatbázis: takarítás, amit azonnal megérzel

Idővel a WooCommerce adatbázisa hordalékot gyűjt össze: termékrevíziók, régi rendelések, elhagyott kosarak, eltávolított bővítmények adatai, lejárt tranziensek. Mindez felduzzasztja a táblákat és lelassítja a lekérdezéseket.

Mit tegyél, sorrendben:

• Először készíts teljes biztonsági mentést. Az alábbiak közül semmi sem nyúl az adatokhoz biztonsági másolat nélkül.
• Töröld a revíziókat és a lejárt tranzienseket.
• Töröld a régi munkameneteket és az elhagyott kosarakat.
• Optimalizáld a táblákat (különösen a nagyokat, mint a wp_options és a WooCommerce táblái).

Két technikai dolog, ami sokat segít: a wp_options táblában vannak „autoload” jelölésű opciók, amelyek MINDEN kérésnél betöltődnek; ha egy bővítmény telezsúfolta, tisztítsd meg. A friss WooCommerce pedig egy dedikált tárolóban (HPOS) tudja tárolni a rendeléseket, ami sokkal gyorsabb a régi struktúránál. Ha az áruházad régi, érdemes megfontolni a HPOS-ra való átállást.

A helyes sorrend, és mikor hívj valakit

Ne csináld egyszerre az egészet, különben nem fogod tudni, mi segített. A gyakorlati sorrend:

1. Mérd fel a jelenlegi állapotot (sebesség, lassú lekérdezések).

2. Ellenőrizd a tárhelyet és a csomagot; ha fojtogat, válts nagyobbra.

3. Takarítsd meg az adatbázist, előbb biztonsági mentéssel.

4. Állítsd be a rétegelt cache-elést, a megfelelő kizárásokkal.

5. Mérj újra és hasonlítsd össze.

Ha ezek után is lassú, a probléma általában mélyebben van: nehéz sablon, rosszul megírt bővítmény, vagy egyedi lekérdezések, amelyek nem használnak indexeket. Itt térül meg egy tapasztalt szempár.

Az MPO Web Studiónál pontosan ilyen auditot végzünk, távolról, országszerte. Őszintén megmondjuk, hogy egy beállításról vagy tárhelyváltásról van-e szó, átlátható árazással és „garantáljuk az első helyet” ígéretek nélkül. Ha szeretnéd, hogy megnézzük az áruházadat, küldj nekünk egy WhatsApp-üzenetet, és együtt átnézzük.