Miért lassú a WooCommerce webshopod — 5 valós technikai ok

Gyakran látok 40–60 aktív pluginnal futó webshopot: külön bővítmény a sliderre, a kívánságlistára, a felugró ablakra, kettő a SEO-ra, három a statisztikára. A gond az, hogy mindegyik minden oldalletöltésnél lefut — akkor is, ha az adott oldalon semmi dolga. A pluginok ráadásul nem tudnak egymásról: mindegyik saját adatbázis-lekérdezéseket (query) futtat, és ezek összeadódnak. Egy oldalletöltés alatt így simán összejön több száz lekérdezés.

Gyakori mellékhatás a háttérben zajló admin-ajax forgalom is: egyes bővítmények rövid időközönként pingelik a szervert, így a látszólag üresjáratban lévő oldal is terhelést termel.

• Írd össze, melyik plugin mit csinál, és mi történne, ha nem lenne. Amit hónapok óta nem használsz, azt ne csak kapcsold ki — töröld.
• Egy funkció = egy megoldás. Két SEO-plugin nem kétszer jobb SEO, hanem kétszer annyi futó kód.
• A kis, egyfunkciós bővítmények egy része kiváltható pár sor saját kóddal — ez a leggyorsabb plugin-fogyókúra.

A WooCommerce dinamikus rendszer: kosár, készlet, árak, bejelentkezett vásárlók. Ezért a klasszikus oldal-gyorsítótár (page cache) épp a legfontosabb oldalakon — kosár, pénztár, fiók — nem segít: ott minden kérést a PHP-nak és az adatbázisnak kell kiszolgálnia. Két dolog számít igazán: a szerver ereje és az objektum-gyorsítótár (object cache).

Az olcsó, megosztott tárhelyen kevés a PHP-worker és lassú a lemez-I/O; amint egyszerre tizenöt-húsz látogató kattint, a kérések könnyen sorban állnak. Az objektum-gyorsítótár — jellemzően Redis vagy Memcached — azt oldja meg, hogy az ismétlődő lekérdezések eredménye memóriából jöjjön vissza, ne kelljen minden kérésnél újraszámolni. WooCommerce alatt ez az egyik legnagyobb hatású, mégis leggyakrabban hiányzó optimalizáció — a legtöbb megosztott tárhelyen egyszerűen nincs is rá lehetőség.

Tapasztalatom szerint egy forgalmasabb shopnál a tárhelyváltás (VPS vagy menedzselt hoszting, Redisszel) önmagában érezhető gyorsulást hoz — mindenféle plugin-varázslás nélkül.

Az Elementor és a hozzá hasonló vizuális szerkesztők jók abban, amire valók: fejlesztő nélkül, gyorsan össze lehet rakni velük egy landinget vagy egy bemutatkozó oldalt. Az ár a kimenetben van: minden szekció köré több réteg wrapper-elem épül, így a DOM (az oldal HTML-fastruktúrája) hatalmasra hízik, és mellé betöltődik a builder saját CSS- és JavaScript-csomagja is — olyan oldalakon is, ahol a funkcióinak a töredékét használod.

Egy terméklistán, ahol 20–40 termékkártya jelenik meg, ez a többletköltség kártyánként sokszorozódik. A PageSpeed jellemzően pontosan ezt jelzi vissza: túl nagy DOM-méret, render-blokkoló erőforrások, gyenge LCP (a fő tartalom megjelenési ideje). A builder tehát nem „rossz” — csak drága, és webshop-méretben ezt az árat betöltési időben a vásárlóid fizetik meg.

A tartós megoldás a sablonszintű kiváltás: a builder-oldalak átépítése karcsú, kézzel írt sablonokra. Ez nagyobb munka, mint bekapcsolni egy cache-plugint, de egyedül ez szünteti meg a gyökérokot — én jellemzően egyedi ACF-sablonokkal csinálom.

Ez a legkevésbé izgalmas ok, mégis ezzel találkozom a leggyakrabban. A galériába feltöltött többmegabájtos termékfotók, a hiányzó WebP-formátum, a lazy loading (késleltetett képbetöltés) nélkül egyszerre betöltődő tucatnyi kép — klasszikus, jól mérhető lassítók, és viszonylag olcsón javíthatók.

• Képek: WebP (vagy AVIF) formátum, méretre szabott változatok, lazy loading a hajtás alatti képekre.
• Oldal-cache a nem bejelentkezett látogatóknak: a főoldal, a kategória- és termékoldalak kiszolgálhatók statikus HTML-ként — csak a kosár és a pénztár marad dinamikus.
• CDN (tartalomszóró hálózat) a statikus fájlokra: a képek, a CSS és a JavaScript a látogatóhoz földrajzilag közeli szerverről töltődik le.

A sorrend viszont fontos: a cache tünetet kezel, nem okot. Ha az első három pont bármelyike fennáll, a cache-plugin csak elfedi a bajt — az első, cache-elés nélküli kérés és minden bejelentkezett vásárló továbbra is a lassú oldalt kapja.

A WordPress adatbázisa idővel szemetelődik, a WooCommerce pedig ezt fel is gyorsítja. A leggyakoribb gócpont a wp_options tábla autoload-mechanizmusa: az autoloadra állított sorokat a WordPress minden egyes kérésnél betölti a memóriába. Ez pár száz kilobájtig rendben van — de régi pluginok maradványaival és felduzzadt beállításokkal több tíz megabájtra is nőhet, és onnantól minden oldalletöltés ezt cipeli.

• Lejárt, de nem törölt tranziensek (átmeneti gyorsítótár-bejegyzések), amelyek autoloadként ragadnak bent.
• Felgyűlt WooCommerce-sessionök és Action Scheduler-naplóbejegyzések.
• Bejegyzés-revíziók ezrei, és a rég törölt pluginok árván hagyott táblái.

Ide tartozik a rendelések tárolása is: a régebbi WooCommerce a rendeléseket a wp_posts/wp_postmeta táblákban tartotta, ami nagy rendelésszámnál nagyon lassú lekérdezéseket szül. Az újabb verziók HPOS-a (High-Performance Order Storage, dedikált rendeléstáblák) ezt kezeli — ha a shopod még a régi struktúrán fut, a migráció megérheti, de csak mérés és teljes mentés után.

A fenti öt ok nagy része két ingyenes eszközzel magadtól is beazonosítható. Az egyik a PageSpeed Insights — mindig a mobil nézetet nézd, mert a Google is azt súlyozza, és ott ütnek ki igazán a gondok. A másik a Query Monitor plugin: bejelentkezve, oldalanként megmutatja, hány lekérdezés fut, melyik plugin mennyi időt visz el, és pontosan mi a lassú.

Szakemberre ott van szükség, ahol a beavatkozás már kockázatos: adatbázis-takarítás éles shopon, tárhely-migráció, builder-kiváltás — vagy amikor a mérés egy konkrét pluginra mutat, de az üzletileg nélkülözhetetlen, és okosabban kell kiváltani. Ha nem akarod ezt magad kibogozni, az ingyenes átvilágítás során pontosan ezeket a méréseket futtatom le a shopodon, és megmondom, melyik ok mennyit nyom nálad.

A lényeg egy mondatban: a lassú WooCommerce mögött szinte mindig ugyanaz az öt gyökérok áll — túltolt plugin-stack, gyenge tárhely object cache nélkül, drága page builder, optimalizálatlan assetek cache és CDN nélkül, valamint elhízott adatbázis. Mindegyik mérhető, mindegyik javítható — de egyik sem oldódik meg attól, hogy feltelepítesz még egy plugint a többi mellé.