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

Gyakran látok negyven-hatvan 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, hanem 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, és 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, méghozzá olyan oldalakon is, ahol a funkcióinak a töredékét használod.

Egy terméklistán, ahol húsz-negyven 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é.