Egy webshopnál a sebesség és a konverzió ugyanannak az éremnek a két oldala. Ha a terméklista lomhán rajzolódik ki, a látogató visszalép a keresőbe, mielőtt egyetlen terméket megnézne. Ha viszont villámgyors az oldal, de a pénztárban tizenkét kötelező mező várja, az addigi munka nagy része elvész. A WooCommerce optimalizálás ezért nem egyetlen bővítmény telepítése, hanem négy réteg rendbetétele: katalógus, képek, gyorsítótár és pénztár, plusz egy mérési rend, ami megmutatja, mi történt valójában.
Az alábbi sorrend nem véletlen. Érdemes a szerveroldali válaszidővel kezdeni, mert hiába gyors a böngészőben megjelenő rész, ha a szerver másodpercekig gondolkodik. Utána jönnek a képek, végül a felhasználói folyamat.
Miért lassabb egy WooCommerce webshop, mint egy hasonló méretű WordPress oldal?
Rövid válasz: mert a webshop oldalainak jelentős része személyre szabott, ezért nehezebben gyorsítótárazható, és mert a termékadatok sok kis lekérdezésre bomlanak szét.
Tovább a témában: Webshop készítés Győr · Webshop készítés Veszprém
Hivatalos információ a WooCommerce fejlesztői dokumentációjából: a rendszer külön munkamenet-táblát használ, a kosár tartalmát pedig alapértelmezetten AJAX-hívással frissíti minden oldalbetöltéskor (ez a wc-cart-fragments szkript). Ez a hívás nem gyorsítótárazható, tehát minden látogatónál elindít egy teljes PHP futást.
Saját tapasztalat: az elhanyagolt webshopokban három dolog tér vissza szinte mindig. Az első az elszabadult wp_options tábla, tele lejárt átmeneti értékekkel és automatikusan betöltődő beállításokkal. Ezt így nézheted meg:
SELECT SUM(LENGTH(option_value)) AS meret FROM wp_options WHERE autoload = 'yes';
Ha ez az érték megabájtos nagyságrendű, az minden egyes oldalbetöltésnél terhet jelent. A takarítás WP-CLI-vel kezdhető: wp transient delete --expired, majd a maradék nagy elemek egyenkénti átnézése. A második visszatérő gond a bővítmény-halmozás: húsz aktív kiegészítő közül jellemzően négy-öt fut minden oldalon, pedig csak a pénztárban lenne dolga. A harmadik a régi PHP-verzió és a hiányzó OPcache.
Hogyan tedd gyorssá a katalógust és a terméklistát?
Rövid válasz: csökkentsd az egy oldalon betöltött termékek és variációk számát, és hagyd, hogy a WooCommerce a saját kereső-tábláit használja a lassú meta-lekérdezések helyett.
A kategóriaoldal a webshop legdrágább lapja, mert egyszerre sok terméket kell összeállítania. Néhány konkrét lépés:
- Oldalanként 12 vagy 24 termék, lapozással. A végtelen görgetés látványos, de a szerveren ugyanazt a terhet többször generálja.
- A WooCommerce állapotoldalán (Állapot, Eszközök) futtasd le a termék-kereső táblák újragenerálását, vagy WP-CLI-ből:
wp wc tool run regenerate_product_attributes_lookup_table --user=1. Ez teszi lehetővé, hogy a tulajdonság szerinti szűrés indexelt táblából dolgozzon. - A variálható termékeknél tiltsd le a listaoldali variáció-előtöltést. Egy húsz variációs póló a kategóriaoldalon százas nagyságrendű felesleges lekérdezést tud okozni.
- A kapcsolódó termékek blokkja gyakran véletlenszerű rendezéssel dolgozik, ami nagy katalógusnál lassú. Vagy kapcsold ki, vagy cseréld fix, kézzel válogatott listára.
- Az oldalsávban futó élő szűrők (készlet, tulajdonság, értékelés) minden kattintásra új lekérdezést indítanak. Nagy katalógusnál érdemes szűrő-bővítmény helyett a beépített, indexelt megoldást használni.
Szakmai feltételezés, nem mért tény: a legtöbb kis és közepes webshopnál a kategóriaoldal szerveroldali válaszideje a legnagyobb egyedi javítási lehetőség, mert innen indul a látogatók többsége.
Mit kezdj a képekkel egy webshopban?
Rövid válasz: a feltöltött eredeti fájlok legyenek ésszerű méretűek, modern formátumban, fix szélesség és magasság megadásával, és csak a fő termékkép töltődjön azonnal.
A gyakorlati sorrend: először a forrásfájlok. Egy telefonnal készült, négy-öt megabájtos fotó feltöltése után hiába generál a WordPress kisebb változatokat, az eredeti ott marad a szerveren, és néhány sablon pont azt tölti be. Hosszabbik oldalon 1600 és 2000 képpont közötti méret a legtöbb termékfotónál elég a nagyításhoz is.
Utána a formátum: WebP vagy AVIF, visszaesési lehetőséggel. Ezt bővítmény vagy a tárhely képoptimalizáló rétege is el tudja végezni. Fontos, hogy a méretváltás után újragenerált bélyegképek konzisztensek legyenek, különben a listaoldal elmosódott képeket mutat.
A layout-ugrálás (CLS) ellen minden képnél add meg a méretet, a fő termékképnél pedig érdemes elsőbbséget kérni és kikapcsolni a késleltetett betöltést:
<img src='termek.webp' width='800' height='800' fetchpriority='high' decoding='async'>
A többi képnél maradjon a loading='lazy'. Saját tapasztalat: sok sablon a galéria összes képét azonnal betölti, ez önmagában megduplázhatja a termékoldal induló letöltési méretét. Végül kapcsold ki a nem használt képméreteket, mert minden feltöltésnél feleslegesen készülnek el, és a tárhelyet is terhelik.
Hogyan gyorsítótárazz úgy, hogy ne törj el semmit?
Rövid válasz: teljes oldal gyorsítótár a nyilvános lapokra, kizárva a kosarat, a pénztárt és a fiókot, mellette objektum-gyorsítótár az ismétlődő adatbázis-lekérdezésekre.
Hivatalos információ: a WooCommerce dokumentációja kifejezetten kéri, hogy a /kosar/, /penztar/ és /fiok/ útvonalak maradjanak ki a statikus gyorsítótárból. Ugyanígy figyelni kell a munkamenet-sütikre, jellemzően a woocommerce_items_in_cart, a woocommerce_cart_hash és a wp_woocommerce_session_ előtagúakra: ha ezek jelen vannak, a látogató friss oldalt kapjon. Ennek elmulasztása a legkellemetlenebb hiba, amit webshopon látni: valaki más kosártartalma jelenik meg egy idegen látogatónál.
Az objektum-gyorsítótár (jellemzően Redis) a másik fele a képnek. A termékadatok, taxonómiák és beállítások ismétlődő lekérdezéseit tartja memóriában, ami pont a dinamikus, nem gyorsítótárazható oldalakon segít.
A kosár-töredékek kérése a kezdőlapon és a blogbejegyzéseken általában felesleges. Ez a részlet kikapcsolja őket ott, ahol nincs rájuk szükség:
add_action('wp_enqueue_scripts', function () { if (is_front_page() || is_singular('post')) { wp_dequeue_script('wc-cart-fragments'); } }, 99);
Figyelmeztetés: ahol kikapcsolod, ott a fejlécben lévő élő kosárszámláló nem frissül azonnal. Teszteld a tényleges sablonoddal, mielőtt élesíted.
Hol keletkezik a legtöbb súrlódás a pénztárban?
Rövid válasz: a felesleges mezőkben, a kötelező regisztrációban, a későn kiderülő szállítási feltételekben és a hibaüzenetek utáni újratöltésben.
Menj végig a saját pénztáradon telefonon, idegen hálózaton, és számold meg, hány koppintás a rendelés leadása. A tipikus javítások:
- Vendégként történő rendelés engedélyezése, a fiók létrehozása legyen felajánlás a folyamat végén, ne feltétel az elején.
- A nem használt mezők eltávolítása. Ha nem küldesz számlát cégnévre, a cégmező csak akadály:
add_filter('woocommerce_checkout_fields', function ($fields) { unset($fields['billing']['billing_company']); return $fields; });
- Helyes beviteli típusok és automatikus kitöltés mobilon: az irányítószámnál numerikus billentyűzet, az e-mail mezőnél
autocomplete='email', a címnélautocomplete='street-address'. - A szállítási lehetőségek és feltételek jelenjenek meg már a kosárban, ne csak az utolsó lépésben. A késői meglepetés a kosárelhagyás egyik leggyakoribb oka.
- Mezőszintű, azonnali visszajelzés a hibákra, teljes oldalújratöltés nélkül. Ha a látogatónak háromszor kell újra beírnia mindent, nagy eséllyel elmegy.
- Bizalmi elemek a pénztár közelében: elállási és visszaküldési tudnivalók, elérhető telefonszám, a fizetési mód logója.
- Egyetlen elsődleges gomb az oldalon. A kuponmező, a hírlevél-feliratkozás és a keresztértékesítés mind elviszi a figyelmet a befejezésről.
Szakmai feltételezés: a blokkos és a klasszikus pénztár közötti választásnál a mérendő különbség jellemzően nem a technológia, hanem az, hogy melyik változatban maradnak benne a felesleges lépések.
Hogyan mérd, hogy a WooCommerce optimalizálás tényleg hatott?
Rövid válasz: valós felhasználói (mező-) adatból nézd a Core Web Vitals mutatókat, mellette a szerveroldali válaszidőt és a rendelési tölcsér lépéseit, mindig azonos időszakokat összehasonlítva.
Hivatalos információ: a Google a mezőadatot tekinti irányadónak, a küszöbök LCP 2,5 másodperc, INP 200 ezredmásodperc, CLS 0,1 alatt, a mérés a látogatások 75. percentilisén történik. Ezt a Search Console Core Web Vitals jelentésében és a PageSpeed Insights mezőadat-blokkjában látod. A laborteszt (Lighthouse) hasznos a hibakereséshez, de a rangsorolás szempontjából nem az a bemenet.
Amit mellé érdemes figyelni:
- Szerveroldali válaszidő (TTFB) sablononként: kezdőlap, kategória, termék, kosár. Query Monitor bővítménnyel megnézed, hány lekérdezés fut és melyik lassú.
- Tölcsérlépések analitikában: terméknézet, kosárba tétel, pénztár indítása, rendelés. Ha csak az összesített konverziót nézed, nem tudod, melyik lépésen szivárog el a forgalom.
- Eszközbontás. Mobilon és asztali gépen külön nézd, mert a javítás gyakran csak az egyiken látszik.
- Belső keresés adatai: ha sokan keresnek olyasmire, ami nincs a menüben, az navigációs, nem sebességi probléma.
A mérés menete legyen fegyelmezett: egy héttel a beavatkozás előtti és utáni azonos hosszúságú időszak, a szezonális hatások figyelembevételével. Egy nagyobb kampány vagy egy hosszú hétvége teljesen félrevihet egy összehasonlítást. A gyorsítás segítheti a konverziót, de önmagában nem eredményez több rendelést, ha a kínálat vagy a bizalmi elemek gyengék.
Milyen ellenőrzőlistával kezdj neki?
Ez a sorrend a legtöbb webshopnál működik, felülről lefelé haladva:
- PHP verzió frissítése, OPcache bekapcsolása, adatbázis-verzió ellenőrzése.
- Lejárt átmeneti értékek törlése, az automatikusan betöltődő beállítások méretének ellenőrzése.
- Nem használt bővítmények eltávolítása (deaktiválás helyett), a maradék szkriptek szűkítése azokra az oldalakra, ahol tényleg kellenek.
- Termék-kereső táblák újragenerálása, oldalankénti terméklimit beállítása.
- Teljes oldal gyorsítótár bekapcsolása, kosár, pénztár, fiók kizárásával és süti-alapú kivételekkel.
- Objektum-gyorsítótár bekapcsolása, ha a tárhely támogatja.
- Eredeti képfájlok méretének rendezése, modern formátum, bélyegképek újragenerálása.
- Fő termékkép elsőbbséggel, a többi késleltetve, minden képnél megadott mérettel.
- Pénztári mezők átnézése, vendégrendelés engedélyezése, szállítási feltételek előrehozása a kosárba.
- Mobilos végigpróbálás valós eszközön, a koppintások megszámolásával.
- Mérés beállítása: Search Console jelentés, tölcséresemények, sablononkénti válaszidő alapállapot rögzítése.
- Két hét múlva újramérés, és csak azután a következő beavatkozás.
Egy dolgot érdemes fejben tartani: a beavatkozásokat egyesével vezesd be, és jegyezd fel a dátumot. Ha egyszerre öt dolgot állítasz át, utólag nem fogod tudni, melyik hatott, és melyik okozott hibát.
Források és további olvasnivalók
- Google Search Central dokumentáció (oldalélmény és Core Web Vitals útmutatók)
- web.dev, Core Web Vitals mérőszámok leírása (LCP, INP, CLS)
- Chrome UX Report (CrUX) hivatalos dokumentáció
- WooCommerce Developer Documentation (gyorsítótárazás, hookok, kereső-táblák)
- WordPress Developer Handbook és WP-CLI kézikönyv
- Schema.org, Product típus specifikáció
- W3C Web Content Accessibility Guidelines (WCAG)
- PHP hivatalos dokumentáció, OPcache fejezet
- A webshop lassúságának többsége nem a sablonban, hanem a dinamikus lekérdezésekben, a felhalmozódott adatbázis-szemétben és a túl nagy képekben keletkezik.
- A teljes oldal gyorsítótárat mindig ki kell zárni a kosár, a pénztár és a fiók oldalakra, különben idegen munkamenet kerülhet a látogató elé.
- A termékoldal fő képe legyen az egyetlen kép, ami nem késleltetve töltődik, fix méretekkel és modern formátumban.
- A pénztári súrlódás legnagyobb része felesleges mezőkből, kötelező regisztrációból és későn kiderülő szállítási feltételekből áll.
- Mérés nélkül nincs optimalizálás: mezőadat, szerveroldali válaszidő és tölcsérlépések együtt mutatják meg, mi változott.
Gyakori kérdések
Melyik gyorsítótár-bővítmény való WooCommerce-hez?
Nincs egyetlen helyes válasz, mert a tárhely szerveroldali beállításai döntenek. A lényeg, hogy a megoldás tudjon teljes oldal gyorsítótárat süti-alapú kivételekkel, ismerje fel a WooCommerce munkamenet-sütiket, és zárja ki a kosár, a pénztár és a fiók oldalakat. Ha a tárhely kínál Redis objektum-gyorsítótárat, azt is érdemes bekapcsolni.
Elrontja-e a kosarat, ha kikapcsolom a cart fragments szkriptet?
Ott igen, ahol az élő kosárszámlálóra szükség van. Ezért érdemes csak azokon az oldaltípusokon kikapcsolni, ahol nincs kosárművelet, tipikusan a kezdőlapon és a blogbejegyzéseknél. Élesítés előtt teszteld a saját sablonoddal, mert a fejléc viselkedése sablononként eltér.
Hány terméket tegyek egy kategóriaoldalra?
A 12 és 24 közötti érték a legtöbb webshopnál jó kiindulás. Ennél többnél a szerveroldali összeállítás és a képek együtt lassítanak, kevesebbnél viszont túl sok lapozás lesz. Nagy katalógusnál a szűrés és a belső keresés minősége fontosabb, mint az egy oldalon megjelenő termékek száma.
Segít-e a sebesség a keresőben és az AI-válaszokban?
A Google hivatalosan is használja az oldalélmény-jeleket, köztük a Core Web Vitals mutatókat, de ezek a tartalom relevanciájánál kisebb súlyt kapnak. A gyorsaság önmagában nem eredményez jobb helyezést. A jól strukturált, gyorsan elérhető termékoldal viszont segítheti azt, hogy a keresőmotorok és az AI-asszisztensek megbízhatóan feldolgozzák az adatokat.
Mennyi idő alatt látszik a javítás hatása?
A laborteszt azonnal mutat különbséget, a valós felhasználói adat viszont 28 napos csúszóablakban gyűlik, tehát a Search Console jelentésében hetek múlva stabilizálódik a kép. A tölcsérlépéseknél a forgalomtól függ: kisebb webshopnál több hétnyi adat kell ahhoz, hogy a különbség ne csak zaj legyen.
Érdemes a klasszikus pénztárról a blokkos változatra váltani?
Csak megfontoltan, tesztkörnyezetben. A blokkos pénztár modernebb alapot ad, de nem minden fizetési és szállítási kiegészítő támogatja teljesen. Ha a jelenlegi pénztár működik, gyakran nagyobb hatása van a mezők számának csökkentésének és a vendégrendelés engedélyezésének, mint magának a váltásnak.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.