Kategóriaoldal gyorsítása sok termékképpel és szűrővel

Scheo · 2026-11-04 · olvasási idő ~10 perc · Szerző: Schmidt Péter

A kategóriaoldal más terhelést visel, mint a termékoldal. Egy termékoldalon jellemzően egy nagy kép, egy ár és egy kosár gomb van. A terméklistán ugyanakkor 24-48 bélyegkép, ugyanennyi ár, akciós címke, készletjelzés és egy szűrőpanel, ami minden kattintásra újrarajzolja a rácsot. Ezért a termékoldalon bevált gyorsítási lépések itt csak részben működnek. Ez a cikk a kategóriaoldal saját szűk keresztmetszeteit veszi sorra, mérési sorrenddel és konkrét beállításokkal.

A szövegben háromféle jelölést használunk. Hivatalosan igazolt az, ami a Google Search Central, a web.dev vagy a WordPress és WooCommerce dokumentációjában szerepel. Saját tapasztalat az, amit webshopok mérésénél rendszeresen látunk, de nem általános szabály. Szakmai feltételezés az, ami logikusan következik a működésből, de mérés nélkül nem állítjuk biztosra.

Miben más egy kategóriaoldal sebességproblémája, mint a termékoldalé?

A kategóriaoldalon a sok kis elem összege lassít, a termékoldalon inkább egy-két nagy elem. A rács minden terméke külön képkérést, külön árszámítást és gyakran külön adatbázis-lekérdezést jelent, a szűrő pedig az oldal betöltése után, interakció közben is terhel.

Négy forrást érdemes külön kezelni.

• Bélyegképek. Ha a téma a teljes méretű termékfotót tölti be, és CSS-sel kicsinyíti, egy 48 termékes oldal képsúlya könnyen többszöröse lesz a szükségesnek.
• Oldalankénti terméklimit. A termékszámmal nagyjából arányosan nő a HTML mérete, a DOM-elemek száma, a képkérések száma és a szerveroldali lekérdezések ideje.
• AJAX-szűrő. Minden szűrőkattintás egy hálózati kérés és egy DOM-csere. Ha a szűrő minden értékhez találatszámot is mutat, azt a szervernek futásidőben ki kell számolnia.
• Árkalkuláció betöltéskor. Változó termékek ártartománya, mennyiségi kedvezmény bővítmények, devizaváltás, viszonteladói árak. Ezek a generálási időt növelik, és ha az ár felhasználónként eltér, az oldal-gyorsítótárat is kikapcsolhatják.

Milyen sorrendben érdemes mérni egy terméklistát?

Előbb a valós felhasználói adatot nézd, utána a laborméréseket, és csak a végén a szerveroldalt. Így nem olyan problémát javítasz, ami a valódi látogatóknál nem is jelentkezik.

1. Search Console, Alapvető webes vitals jelentés. A jelentés hasonló URL-eket csoportosít, így kiderül, hogy a kategóriaoldalak csoportja melyik mutatón bukik (hivatalosan igazolt). A határértékek a 75. percentilisre vonatkoznak, az LCP jó, ha legfeljebb 2,5 másodperc, az INP jó, ha legfeljebb 200 ms, a CLS jó, ha legfeljebb 0,1 (hivatalosan igazolt, web.dev).
2. PageSpeed Insights. Egy jellemző kategória URL-jén nézd meg a mezőadatot, aztán a laborrészben az LCP-elemet. A diagnosztika megmutatja, pontosan melyik HTML-elem az LCP.
3. Chrome DevTools Performance panel. Mobil processzor- és hálózatlassítással rögzíts egy betöltést. Az LCP-t négy szakaszra bontva látod (szerverválasz, betöltési késleltetés, betöltési idő, renderelési késleltetés), és ebből kiderül, hol vész el az idő.
4. Elmozdulások. Ugyanebben a felvételben a Layout shifts sávon látszik, melyik elem ugrik a rács betöltésekor.
5. Szűrőkattintás. Rögzíts egy kattintást egy szűrőn, és nézd meg az interakció teljes hosszát, a hálózati kérés idejét és a DOM-csere idejét.
6. Szerveroldal. WordPressben a Query Monitor bővítménnyel mérd a kategóriaoldal generálási idejét és lekérdezéseit, szűrővel és anélkül, bejelentkezve és kijelentkezve is.

Melyik elem az LCP egy terméklistán?

Leggyakrabban az első sor egyik termékképe, vagy ha van, a kategória fejlécképe. Mobilon, ha a képek lusta betöltésűek, időnként a kategórialeírás szövegblokkja vagy a H1 lesz az LCP, ami azt jelzi, hogy a képek túl későn jelennek meg.

Hivatalosan igazolt. Az LCP-elem lehet img, SVG-n belüli kép, videó poszterképe, CSS-sel url() háttérként betöltött kép és szöveget tartalmazó blokkelem. A web.dev szerint a hajtás feletti képek lusta betöltése rontja az LCP-t. WordPress 6.3 óta a mag automatikusan fetchpriority="high" attribútumot tesz az első nagy tartalomképre, és az első néhány képről elhagyja a loading="lazy" attribútumot. Ennek számát a wp_omit_loading_attr_threshold szűrő állítja, alapértéke 3.

Saját tapasztalat. Sok téma és slider a kategória-bannert CSS háttérképként tölti be, amit a böngésző csak a stíluslap feldolgozása után fedez fel. Ilyenkor az LCP betöltési késleltetése nagy. Mobilon kétoszlopos rácsnál általában 2-4 termékkép látszik betöltéskor, asztali gépen négyoszlopos rácsnál akár 8 is.

A teendők sorrendje így alakul.

• Az első sor képei (mobilon legalább 2, asztali gépen 4) ne kapjanak lusta betöltést.
• Az LCP-képen legyen fetchpriority="high", háttérképes banner esetén előtöltés (rel="preload"), vagy cseréld a bannert valódi img elemre.
• A bélyegkép srcset és sizes attribútuma a rács tényleges oszlopszélességéhez igazodjon.
• Ha a mezőadatban a szerverválasz a nagy tétel, az LCP-képpel hiába foglalkozol, előbb a generálási időt kell lerövidíteni.

Mi okoz CLS-t, amikor a termékrács betöltődik?

A rács elmozdulását leggyakrabban a méret nélküli képek, az utólag beszúrt elemek (akciós címke, ár, értékelő csillagok, kosár gomb), a betűtípus-csere és az AJAX-szűrő által a rács fölé beszúrt sávok okozzák.

Hivatalosan igazolt. A képeknél a width és height attribútum vagy a CSS aspect-ratio előre lefoglalja a helyet. A felhasználói interakció utáni 500 ms-on belüli elmozdulás nem számít bele a CLS-be. Ha viszont a szűrő válasza ennél lassabban érkezik, a rács cseréje már beleszámít.

Saját tapasztalat. Gyakori ok a vegyes képarányú termékfotó, amikor egyes termékek álló, mások fekvő képet kapnak, és a kártyák magassága eltér. Ugyanígy a JavaScripttel utólag rárakott akciós címke és a lap tetején később megjelenő értesítő sáv.

Egy egyszerű CSS-alap, ami a legtöbb rácsnál segít.

.products li.product img { aspect-ratio: 1 / 1; width: 100%; height: auto; object-fit: contain; }

.products li.product .price { min-height: 1.5em; }

A szűrő eredménysávjának (aktív szűrők, találatszám) is foglalj fix helyet, akkor is, ha még üres.

Mennyit lassít a szűrőpanel, és hogyan mérd?

Általános szám nincs, a szűrőpanelt két ponton kell mérni. Betöltéskor a panel HTML-je, a találatszámlálók és a szkriptje terhel, kattintáskor pedig az INP és a szerver válaszideje.

A betöltési hatást úgy mérheted a legtisztábban, hogy egy tesztkörnyezetben ugyanazt a kategóriaoldalt szűrővel és szűrő nélkül is lefuttatod, és összeveted a generálási időt meg a szkript-végrehajtás idejét. A kattintásnál a Performance panelen nézd meg, mennyi a hálózati várakozás és mennyi a böngésző oldali feldolgozás.

Saját tapasztalat. A sok attribútumos szűrő találatszámlálója szokott lenni a leglassabb rész, mert minden értékhez külön lekérdezés fut. Gyakori az is, hogy az AJAX-szűrő a teljes oldal HTML-jét kéri vissza, és ebből csak a rácsot cseréli ki, így a szerver ugyanannyit dolgozik, mint egy teljes újratöltésnél.

Javítási lehetőségek.

• Mobilon a szűrő egy „Alkalmaz” gombbal fusson le, ne minden jelölőnégyzet-kattintásra.
• Csúszkánál és keresőmezőnél késleltesd a kérést (debounce), hogy ne menjen ki minden mozdulatra.
• A találatszámlálókat tárold gyorsítótárban, vagy kapcsold ki ott, ahol nincs rájuk szükség.
• A szűrő csak a rács HTML-jét vagy adatát kérje vissza.

Hivatalosan igazolt, keresőoldalról. A Google faceted navigation útmutatója szerint a szűrő-URL-ek nagy része felesleges bejárást okozhat. Ha egy szűrőkombinációnak nincs keresési értéke, robots.txt-vel tilthatod a bejárását, vagy kezelheted URL-töredékkel.

Hogyan lassít a betöltéskor futó árkalkuláció?

Ha a lista minden termékénél futásidőben számolódik az ár, az a szerver generálási idejét a termékszámmal arányosan növeli. Ha pedig az ár felhasználói csoportonként eltér, a teljes oldal-gyorsítótár sokszor nem használható.

Hivatalosan igazolt. A WooCommerce a változó termékek változatárait tranziensben tárolja, hogy ne kelljen minden betöltésnél újraszámolni az ártartományt.

Saját tapasztalat. A kedvezményszabályokat futtató bővítmények egy 48 termékes kategóriaoldalon gyakran a Query Monitor legnagyobb tételei közé kerülnek. Ha a sablon az árat AJAX-szal utólag tölti be, az CLS-t is okoz, és egy plusz kérést is jelent.

Mit tehetsz?

• Egyszerűsítsd a kedvezményszabályokat, a listanézetben elég lehet a végső ár megjelenítése a teljes kalkuláció nélkül.
• Ha a bővítmény tudja, számolja elő az árat termékmentéskor.
• Felhasználói csoportonként eltérő árnál a gyorsítótár csoportonként külön változatot tároljon, a vendég látogatók oldala így cache-ből mehet.

Milyen beállításokkal gyorsítható a kategóriaoldal WooCommerce-ben?

A legtöbbet a bélyegképméret, a termékszám, az attribútum-keresőtábla és a gyorsítótárazás adja, ebben a sorrendben érdemes végigmenni.

• Bélyegképméret. Megjelenés › Testreszabás › WooCommerce › Termékképek alatt állítsd a bélyegkép szélességét a rács tényleges oszlopszélességéhez, és válassz egységes vágást. Módosítás után a WooCommerce a háttérben újragenerálja a képeket (hivatalosan igazolt).
• Termékszám. Ugyanitt, a Termékkatalógus résznél a sorok és oszlopok számával, ha a téma ezt támogatja. Ha nem, a loop_shop_per_page szűrővel.
• Attribútum-keresőtábla. WooCommerce › Beállítások › Termékek › Haladó alatt kapcsold be a termékattribútum-keresőtábla használatát a katalógusszűréshez. A WooCommerce 6.1-ben került be a szűrés gyorsítására (hivatalosan igazolt).
• Kosár-töredékek. Újabb WooCommerce-verziókban a kosár-töredék szkript alapból már nem fut minden oldalon, de egyes témák és mini kosár modulok visszahozzák (hivatalosan igazolt a változás, a témafüggés saját tapasztalat). A kategóriaoldalon ellenőrizd a hálózati fülön, hogy fut-e get_refreshed_fragments kérés.
• Gyorsítótár. Teljes oldal-cache a kategóriaoldalakra, és objektum-gyorsítótár (például Redis) a lekérdezésekhez. Paraméteres szűrő-URL-eknél figyelj, hogy a cache ne teljen meg több ezer ritkán látogatott kombinációval.

Egy minimális kódrészlet a téma functions.php fájljába vagy egy saját bővítménybe.

add_filter( 'loop_shop_per_page', function () { return 24; }, 20 );

add_filter( 'wp_omit_loading_attr_threshold', function () { return 4; } );

Az első sor a kategóriaoldalakon 24 terméket mutat, a második azt kéri, hogy az első négy kép ne kapjon lusta betöltést. Négyoszlopos asztali rácsnál ez az első sort fedi le.

Mit állíts egy általános webshopmotorban?

Hosztolt rendszereknél a legtöbb lehetőség a sablonban van, ezért ugyanazokat a pontokat a sablonkódban keresd, mint WooCommerce-ben.

• A képkiszolgáló URL-jében sok rendszer méretparamétert fogad, ezt a rács oszlopszélességéhez igazítsd.
• Az oldalankénti termékszám általában az adminban vagy a sablon beállításai között található.
• Nézd meg, hogy a szűrő AJAX-szal vagy teljes újratöltéssel működik, és hogy a szűrt URL-ek bejárhatók-e.
• Ha a sablon engedi, az első sor képeiről vedd le a lusta betöltést.

Szakmai feltételezés. Zárt rendszerben a szerveroldali generálási időre kevés a ráhatásod, így ott a kép, a szkript és az elmozdulás javítása hozza a mérhető különbséget.

Mikor érdemes csökkenteni az oldalankénti termékszámot?

Akkor, ha a mérés szerint a szervergenerálás vagy a DOM mérete a szűk keresztmetszet, és a termékszám növelésével arányosan romlik. Ha az LCP-t egy rosszul betöltött első kép okozza, a termékszám csökkentése alig segít, mert az LCP-elem ugyanaz marad.

A legtisztább teszt az, ha egy tesztkörnyezetben ugyanazt a kategóriát 48 és 24 termékkel is lemérd, és összeveted a generálási időt, a DOM-elemek számát és a laborbeli LCP-t. Ha a különbség kicsi, a termékszám maradhat, és máshol érdemes keresni a lassulás okát.

Milyen SEO-mellékhatása lehet a kisebb termékszámnak?

Kevesebb termék oldalanként több lapozott oldalt jelent, a termékek mélyebbre kerülnek, és az első oldalról kevesebb belső link mutat rájuk.

Hivatalosan igazolt. A Google 2019 óta nem használja a rel="prev" és rel="next" jelölést indexelési jelként. A lapozott oldalak mindegyike kapjon saját, önmagára mutató kanonikus URL-t, és ne az első oldalra kanonikusítsd őket. A lapozó linkek legyenek sima a href linkek. „Továbbiak betöltése” gombnál és végtelen görgetésnél is legyen minden részhez bejárható URL.

Saját tapasztalat. A második és további lapozott oldalakon lévő termékeket a Googlebot jellemzően ritkábban járja be, mint az első oldalon lévőket.

Szakmai feltételezés. A meglévő termékek helyezésére a hatás valószínűleg kicsi, az új termékeknél viszont lassabb lehet a felfedezés. Ezt ellensúlyozhatja néhány lépés.

• Bonts alkategóriákra, így kevesebb a lapozás.
• Az alapértelmezett rendezés a népszerű vagy új termékeket tegye előre.
• Minden termék szerepeljen az XML-oldaltérképben.
• A termékoldalak egymásra is linkeljenek (kapcsolódó termékek).

Mit nézz át, mielőtt élesíted a változtatást?

A változtatás után ugyanazzal a módszerrel mérj újra, mint előtte, különben az eredmények nem összevethetők.

• Az LCP-elem az első sor képe, és nincs rajta lusta betöltés.
• Az LCP-képen van fetchpriority="high", vagy a háttérképes banner előtöltést kapott.
• Minden termékképnek van mérete vagy képaránya.
• Az ár, a címke és a kosár gomb helye le van foglalva.
• A szűrőkattintás interakciója 200 ms körül vagy alatta marad a laborban, mobil lassítással.
• A szűrő-URL-ek bejárása szándékosan van kezelve.
• A lapozott oldalak saját kanonikus URL-t és sima linkeket kaptak.
• A mezőadatot 28 nap múlva újra megnézed a Search Console-ban, mert a CrUX gördülő 28 napos adatot mutat.

Egyik lépés sem garantál jobb helyezést. A gyorsabb kategóriaoldal a látogatónak jó eséllyel kényelmesebb, és a bejárást is segítheti, de a hatást mindig a saját mérésedből ítéld meg.

Források és további olvasnivalók

• Google Search Central, Pagination, incremental page loading, and their impact on Google Search
• Google Search Central, Managing crawling of faceted navigation URLs
• Google Search Console súgó, Alapvető webes vitals jelentés
• web.dev, Largest Contentful Paint (LCP) és Optimize LCP
• web.dev, Cumulative Layout Shift (CLS)
• web.dev, Interaction to Next Paint (INP)
• Chrome DevTools dokumentáció, Performance panel
• WordPress Developer Resources, wp_omit_loading_attr_threshold és fetchpriority
• WooCommerce dokumentáció, Product attributes lookup table és Product Images beállítások