Röviden: miért lassú a WooCommerce webshop?
A lassú WooCommerce webshop mögött szinte mindig az áll, hogy a szerver, az adatbázis vagy a böngésző több munkát végez a kelleténél. A leggyakoribb okok: gyenge tárhely, hiányzó vagy megkerült oldal-gyorsítótár, perzisztens objektum-gyorsítótár hiánya, felduzzadt adatbázis és túl sok szkript minden oldalon.
A WooCommerce önmagában nem lassú. Jól felépített, több ezer termékes webáruházak egy másodpercen belül betöltenek. Előbb mérj, nézd meg, az alábbi 12 okból melyik érvényes nálad, és hatás szerinti sorrendben javítsd őket.
Miért lassul egyre jobban egy WooCommerce webáruház?
Egy új, 50 termékes, öt bővítményes webshop szinte bármilyen tárhelyen gyors. A gondok fokozatosan jönnek:
- minden rendelés, vásárlói munkamenet és ütemezett feladat sorokat ad az adatbázishoz;
- minden új bővítmény (futár, számlázó, Árukereső-feed, eMAG.hu) lekérdezéseket, automatikusan betöltött beállításokat és szkripteket hozhat;
- a marketing pixeleket, chatet, értékelő widgeteket tesz az oldalra;
- a Black Friday forgalmi csúcsa előhozza azokat a korlátokat, amik mindig is ott voltak.
A sebesség pénz. A lassú termékoldal rontja a Core Web Vitalst és a Google-helyezést, a lassú pénztár pedig rendeléseket veszít. Ha neked laptopon lassúnak tűnik a webshop, egy átlagos telefonon, mobilneten még lassabb.
Hogyan derítsd ki, miért lassú a webshopod?
Mielőtt bármit átállítasz, nézd meg, hol megy el az idő: a szerveren vagy a böngészőben.
| Tünet | Valószínű terület | Ellenőrző eszköz |
|---|---|---|
| Magas TTFB minden oldalon, a gyorsítótárazottakon is | Tárhely, DNS, nincs cache | PageSpeed Insights, WebPageTest |
| Gyors kategóriák, lassú kosár és pénztár | PHP, objektum-gyorsítótár, bővítmények | Query Monitor |
| Lassú admin, nehézkes rendeléslista | Adatbázis, ütemezett műveletek | Query Monitor, a WooCommerce állapotoldala (Status) |
| Jó TTFB, de gyenge LCP | Képek, betűtípusok, blokkoló szkriptek | PageSpeed Insights, Chrome DevTools |
| Csak csúcsidőben lassú | PHP workerek, CPU, adatbázis-kapcsolatok | Tárhely grafikonjai, naplók |
A web.dev szerint a 0,8 másodperces vagy rövidebb TTFB jó. A Core Web Vitals „jó" határai: LCP legfeljebb 2,5 s, INP legfeljebb 200 ms, CLS legfeljebb 0,1.
Telepítsd a Query Monitor bővítményt stagingre (vagy rövid időre élesre). Oldalanként mutat minden SQL-lekérdezést bővítmény szerint csoportosítva, és jelzi a lassúakat és az ismétlődőket. Nyisd meg a WordPress Eszközök menüjében a webhely állapotát ellenőrző oldalt is (Tools → Site Health): az olyan üzenetekkel, mint a „You should use a persistent object cache" vagy az „Autoloaded options could affect performance", érdemes foglalkozni.
A lassú WooCommerce webshop 12 oka és a megoldásuk
1. Túl kicsi vagy túl zsúfolt tárhely
Az olcsó osztott tárhely több száz oldalt tesz egy szerverre. A nem gyorsítótárazható WooCommerce-oldalaknak (kosár, pénztár, fiók, keresés) valódi CPU és elég PHP worker kell.
Megoldás: VPS vagy menedzselt WooCommerce-tárhely dedikált erőforrással, PHP 8.3 vagy újabb, bekapcsolt OPcache és legalább 256 MB PHP-memória, a WooCommerce hivatalos ajánlása szerint. A 504 Gateway Time-out és az Allowed memory size of 268435456 bytes exhausted hibák tipikus jelek.
2. Nincs oldal-gyorsítótár, vagy mindig megkerülődik
Cache nélkül minden látogatás PHP-t és tucatnyi lekérdezést futtat. Rosszul beállított cache-nél a sütik miatt nem a gyorsítótárból jön az oldal.
Megoldás: szerveroldali gyorsítótár (Nginx FastCGI cache, Varnish, LiteSpeed) vagy egy jó gyorsítótárazó bővítmény. Csak a kosár, a pénztár és a fiókom oldalt zárd ki (a valódi slugjaikkal). Ellenőrizd, hogy a wp_woocommerce_session_ süti ne állítódjon be minden látogatónak minden oldalon.
3. Nincs perzisztens objektum-gyorsítótár
Memóriabeli tároló nélkül a WordPress minden kérésnél megismétli ugyanazokat az adatbázis-lekérdezéseket.
Megoldás: Redis (vagy Memcached) a szerveren, például a Redis Object Cache bővítménnyel bekötve. A kosárnál, a pénztárnál, a fiók oldalon és az adminban látszik a nyereség.
4. Felduzzadt automatikusan betöltött beállítások
Az autoload jelölésű beállítások minden kérésnél betöltődnek. A törölt bővítmények gyakran nagy sorokat hagynak maguk után.
Megoldás: nézd meg az összméretet (igazítsd a tábla előtagját):
SELECT SUM(LENGTH(option_value)) FROM wp_options WHERE autoload IN ('yes','on','auto','auto-on');
Nagyjából 800 KB felett a Site Health már figyelmeztet. Listázd a legnagyobb sorokat, azonosítsd a bővítményt, és kapcsold ki az autoloadot, ahol nem kell minden oldalon.
5. Felgyűlt ütemezett műveletek
A WooCommerce és sok bővítmény, például a számlázó-, feed- vagy piactér-szinkronizálók, az Action Schedulert használja. Ha a WP-Cron csak látogatáskor fut, a feladatok felgyűlnek.
Megoldás: nyisd meg a WooCommerce állapotoldalán az ütemezett műveletek listáját (WooCommerce → Status → Scheduled Actions), és nézd a lejárt (Past-due) és sikertelen (Failed) elemeket. Ha ugyanarra a hookra ezrével vannak sikertelenek, egy bővítmény hibás. Kapcsold ki a WP-Cront a wp-config.php-ben a define('DISABLE_WP_CRON', true); sorral, és futtasd valódi szerveroldali cronból percenként. A 30 napnál régebbi befejezett műveleteket töröld.
6. A rendelések még a bejegyzéstáblában vannak
A régebbi webshopok a wp_posts és wp_postmeta táblákban tárolják a rendeléseket, amik óriásira nőnek. A HPOS (High-Performance Order Storage) saját táblákba teszi a rendeléseket, és a WooCommerce 8.2 óta az új webshopokban alapértelmezett.
Megoldás: a WooCommerce haladó beállításai között, a funkciók oldalon (Settings → Advanced → Features) kapcsold be a kompatibilitási módot, hogy a két tárolás szinkronban legyen, ellenőrizd, hogy a futár- és számlázó bővítmények kompatibilisek, aztán válts HPOS-ra. Előbb stagingen.
7. Mindenhol betöltődő bővítmények
Egy űrlapbővítmény, ami a termékoldalon is betölti a szkriptjeit, vagy egy jelentéskészítő, ami minden admin oldalon nehéz lekérdezéseket futtat, gyorsan összeadódik.
Megoldás: a Query Monitorban rendezd a bővítményeket lekérdezési idő szerint. Töröld, amit nem használsz, cseréld a nehezeket, és csak ott töltsd be a szkripteket, ahol kellenek.
8. Optimalizálatlan képek
A fotóstól egyenesen feltöltött, darabonként 4–8 MB-os termékfotók még mindig gyakoriak, és szinte mindig ezek döntik el az LCP-t.
Megoldás: WebP vagy AVIF, átméretezés a megjelenített méretre, srcset, lusta betöltés a hajtás alatt, de soha ne a fő termékképen. A CDN a szervertől távoli vásárlóknak segít.
9. Nehéz téma vagy oldalépítő
A „mindenre jó" témák és oldalépítők több száz kilobájt CSS-t és JavaScriptet töltenek be minden oldalon, akkor is, ha az oldal nem használja.
Megoldás: mérd meg a felesleges kódot a Chrome DevTools → Coverage fülön. Vagy kiszeded, ami nem kell, vagy könnyű, WooCommerce-re készült témára váltasz. Néha egy egyedi téma olcsóbb, mint hónapokig optimalizálni.
10. Kosárfragmensek minden oldalon
A wc-ajax=get_refreshed_fragments kérés frissíti a mini kosarat, és nem gyorsítótárazható. A WooCommerce 7.8 óta a szkript csak akkor töltődik be, ha a kosár widget megjelenik, de sok téma a fejlécbe kényszeríti.
Megoldás: keresd a kérést a Network fülön olyan oldalakon, ahol a kosár nem változott. Használd a Mini Cart blokkot, vagy csak akkor töltsd a fragmenseket, ha már van valami a kosárban.
11. Lassú szűrés és keresés nagy katalógusnál
A sok attribútumra épülő szűrős navigáció (szín, anyag, méret, márka) több ezer terméknél nagyon drága lekérdezéseket gyárt.
Megoldás: kapcsold be a termékattribútum-keresőtáblát a termékbeállítások haladó részén (WooCommerce → Settings → Products → Advanced), és ha elcsúszik, generáld újra az állapotoldal eszközei között (WooCommerce → Status → Tools). Nagyon nagy katalógusnál vidd a keresést és a szűrést dedikált indexbe (Elasticsearch, OpenSearch, Meilisearch vagy Algolia).
12. Külső szkriptek és élő API-hívások
A chat, a hőtérkép, a több hirdetési pixel és az értékelő widgetek jobban ronthatják az INP-t, mint bármi a saját szervereden. Szerveroldalon a futárszolgálat díjszámításának, az ERP készletének vagy a számlázó programnak az élő hívása oldalbetöltéskor azt jelenti, hogy az oldal más szerverére vár.
Megoldás: tisztítsd meg a Google Tag Manager címkéit, töröld a duplikátumokat, és ahol lehet, mérj szerveroldalon. Termékoldalon és kosárban soha ne hívj szinkron külső API-t: a készletet és az árakat háttérben szinkronizáld, és a saját adatbázisodból olvasd, a számlák és a csomagcímkék pedig sorban, háttérfolyamatként készüljenek.
Gyors diagnosztikai ellenőrzőlista
- TTFB lemérve a főoldalon, kategórián, terméken, kosárban és pénztárban
- PHP 8.3+, OPcache be, legalább 256 MB memória
- Oldal-gyorsítótár aktív, kosár, pénztár és fiók kizárva
- Redis vagy Memcached bekötve
- Automatikusan betöltött beállítások ~800 KB alatt
- Nincs tömegesen lejárt vagy sikertelen ütemezett művelet; valódi cron fut
- HPOS bekapcsolva
- Egyik bővítmény sem lassú vagy ismétlődő a Query Monitorban
- WebP vagy AVIF képek, fő termékkép lusta betöltés nélkül
- Kosárfragmensek csak ha kell
- Attribútum-keresőtábla bekapcsolva a szűrőkhöz
- Külső szkriptek átnézve; nincs élő API-hívás oldalbetöltéskor
Milyen sorrendben javítsd a hibákat?
Ha egyszerre több ok is fennáll, ebben a sorrendben érdemes haladni, mert így látod, melyik lépés mennyit hozott:
- Mérés: TTFB és Core Web Vitals az öt fő oldaltípusra, mobilon. Írd fel a számokat.
- Szerver: PHP-verzió, OPcache, memória, és ha kell, tárhelyváltás. Itt a legnagyobb a nyereség a legkisebb munkával.
- Gyorsítótár: oldal-gyorsítótár és Redis. Mérj újra.
- Adatbázis: autoload, ütemezett műveletek, HPOS. Előbb stagingen.
- Front-end: képek, téma, külső szkriptek. Ez hat leginkább az LCP-re és az INP-re.
- Katalógus: szűrők és keresés, ha több ezer terméked van.
Minden lépés után mérj újra ugyanazokon az oldalakon. Ha egy változtatás nem hozott javulást, vond vissza, ne halmozz bővítményeket.
Mennyibe kerül egy lassú WooCommerce webshop rendbetétele?
Becslések a magyar és közép-európai piacra, ÁFA nélkül; a forintösszegek kb. 365 Ft/€ árfolyammal, kerekítve1:
| Beavatkozás | Jellemző költség | Megjegyzés |
|---|---|---|
| Tárhelyváltás (VPS vagy menedzselt) | 30–300 €/hó (kb. 11–110 ezer Ft) | A legtöbb kis webshopnál ez hozza a legtöbbet |
| Sebességaudit | 300–1000 € (kb. 110–365 ezer Ft) egyszeri | Rangsorolt teendőlista legyen az eredmény, ne egy PageSpeed-képernyőkép |
| Gyorsítótár, Redis, adatbázis-tisztítás, HPOS | 500–2000 € egyszeri | A bővítmények kompatibilitásán múlik |
| Új vagy egyedi téma | 2000–8000 € | Ha a téma a szűk keresztmetszet |
| Keresőindex nagy katalógushoz | 1000–5000 € plusz előfizetés | Ezres termékszám sok szűrővel |
A Raao-nál minden webshop általunk üzemeltetett felhő-, dedikált vagy VPS-szervereken fut, sebességre és biztonságra hangolva. A hosting- és karbantartási csomagok havi 89 €-tól indulnak (ÁFA nélkül). Ha újra kell építeni a webshopot, a Starter 1900 €-tól, a Launch 3900 €-tól indul, és a Launch már CDN-t, gyorsítótárat és képoptimalizálást is tartalmaz; nézd meg az árakat és az e-kereskedelmi szolgáltatást.
Hogyan csináltuk a Kuibánál
A Kuiba 25+ európai márka több mint 10 000 konfigurálható termékét árulja, pont azt a fajta katalógust, ami egy szabványos telepítést térdre kényszerít. Egyedi platformon fut, nem WooCommerce-en, de az elvek ugyanazok:
- Egyedi kirakat, sebességre és SEO-ra optimalizálva.
- Azonnali, többszempontú keresés szinonimákkal és AI-tartalékkal.
- Automatizált beszállítói importok olyan márkáktól, mint a Bonaldo, Calligaris, Nardi és Miele, AI-támogatott kategórialeképezéssel.
- Szerveroldali GA4 és Meta Conversions API, valamint Google Merchant, Meta, TikTok és Pinterest feedek.
Nézd meg a Kuiba esettanulmányt. Ha szeretnéd, hogy ránézzünk a webshopod számaira, foglalj ingyenes 30 perces hívást a kapcsolat oldalon.
Kerekített számítási árfolyam, nem hivatalos MNB-adat; 2026 októberében az euró nagyjából 365–370 Ft körül mozgott. A hivatalos napi árfolyam az MNB oldalán található. Ellenőrizve: 2026. október. ↩