Egy WooCommerce termékoldal általában elfogadhatóan töltődik be. A boltoldal, a kategórialisták és a keresési találatok viszont gyakran nem, és a boltosokat ez rendszeresen meglepi, mert az egyes termékek rendben lévőnek tűnnek. A különbség számtan kérdése. Egy termékoldal egy főképet mutat. Egy huszonnégy terméket megjelenítő kategóriaoldal legalább huszonnégyet, és gyakran a dupláját, ha az egérrámutatásos effekteket és a galéria-előnézeteket is számoljuk.

Ez a szorzás az oka annak, hogy a katalógusoldalak jellemzően a bolt leglassabb részei, és annak is, hogy kereskedelmileg éppen ezek a legfontosabb oldalak. Ott állnak az érkező látogató és a vásárolni valót találó látogató között.

A legtöbb lassú katalógus mögötti minta: a sablon olyan bélyegképméretet kér, amelyet a WordPress soha nem állított elő, így a böngésző letölti a teljes méretű feltöltést, és az oldalon kicsinyíti le. Huszonnégy termék, amelyek mindegyike kétmegabájtos fényképet küld, hogy háromszáz pixelen jelenjen meg, ötvenmegabájtos kategóriaoldalt ad, amely rosszul teljesít, bármennyi gyorsítótárazást is teszel hozzá.

Miért viselkednek másképp a katalógusoldalak

Egy listaoldalon három dolog erősíti egymást, ami a termékoldalon nem.

A mennyiség. A rácsban minden termék legalább egy képkérést ad hozzá. A WooCommerce alapbeállításai gyakran tizenhat vagy huszonnégy terméket mutatnak oldalanként, a nagyobb boltok pedig ezt tovább emelik a lapozás csökkentése érdekében.

Rámutatásos és galériaképek. Sok sablon termékenként előtölt egy második képet a rámutatásos váltáshoz. Ez csendben megduplázza az oldal képszámát, és mivel a második kép interakcióig sosem látható, semmit nem ad az első megjelenítéshez, miközben ugyanannyi sávszélességet fogyaszt.

Elrendezési instabilitás. Azok a rácsok, amelyek nem tartanak fenn helyet a képeknek, elmozdulnak, ahogy mindegyik megérkezik. Termékoldalon egyetlen elmozdulás elviselhető. Huszonnégyes rácson a felhalmozódó mozgás adja a rossz Cumulative Layout Shift értéket, és úgy érződik, mintha az oldal ugrálna, miközben kattintani próbálsz.

Ennek az a következménye, hogy a katalógusoldalak olyan okokból buknak el a Core Web Vitalson, amelyek egy termékoldalon nincsenek meg, és a terméksablon optimalizálása semmit nem tesz értük.

A méreteltérés, ami a legtöbbet okozza

A WordPress feltöltéskor előállít egy sor képméretet. A WooCommerce ezekre saját méreteket regisztrál. A sablonok pedig további méreteket. Hogy a böngésző valójában mit kap, attól függ, ezek közül melyiket kéri a sablon, és hogy az a méret létezik-e.

A hibamód csendes. Ha egy sablon olyan méretet kér, amelyet a termékeid feltöltése után regisztráltak, a WordPress sosem állította elő, így visszaesik a teljes méretű eredetire. Az oldal továbbra is helyesnek látszik, mert a böngésző lekicsinyíti a képet. Csak éppen több megabájtot mozgat egy bélyegkép megjelenítéséhez.

Eszköz nélkül is észreveheted. Nyiss meg egy kategóriaoldalt, nyisd meg a hálózati panelt, és rendezd a képkéréseket méret szerint. Ha az átvitt méretek közel vannak az eredeti feltöltések súlyához ahelyett, hogy annak töredékét adnák, rossz méret megy ki. Hasonlítsd össze egy betöltött kép valódi méreteit azzal a hellyel, amelyet a képernyőn elfoglal. Egy kétezer pixel széles fénykép, amely egy háromszáz pixeles csempét tölt ki, egyetlen megfigyelésben adja az egész problémát.

A javítás vagy a bélyegképek újragenerálása, hogy a kért méretek létezzenek, vagy a helyes méret kiszolgálása, hogy a kérdés fel se merüljön.

A lusta betöltés, és hol romlik el

A WordPress alapból lustán tölti be a képeket, ami a katalógusoldalaknak szinte minden más oldaltípusnál többet segít, mert egy hosszú rács nagy része a hajtás alatt van.

Két hiba viszont lerontja.

Az első sor lusta betöltése. Az érkezéskor látható képeknek azonnal be kell töltődniük. Ha a legnagyobbat lustán töltöd, a böngésző későn fedezi fel, és mivel ez rendszerint a Largest Contentful Paint eleme, a mérés közvetlenül romlik. A legtöbb sablon itt hibázik, mert egységesen minden termékcsempére alkalmazza a lusta betöltést.

Lusta betöltő bővítmények, amelyek a natív megvalósítással harcolnak. Ha olyan bővítményt futtatsz, amely saját lusta betöltést tesz a böngészőé fölé, olyan képeket kapsz, amelyek sosem töltődnek be, kétszer töltődnek be, vagy villognak. Ha van telepített teljesítménybővítményed, nézd meg, nem duplikálja-e azt, amit a böngésző már elvégez.

A kiszolgálás: az a rész, ami skálázódik

A bélyegképek újragenerálása a mai katalógust javítja meg. A jövő hónapit nem, amikor egy új beszállító más képarányú fényképeket küld, vagy amikor sablont váltasz, és a szükséges méretek megint megváltoznak.

A képek kiszolgáláskori átalakítása elkerüli ezt a mókuskereket. Az eredeti úgy marad, ahogy feltöltötted, és a kiszolgált méretet az URL dönti el, nem az, amit hónapokkal ezelőtt generáltak. Változik a rács, változik a paraméter. Nincs újragenerálási futtatás, és nincs kockázat, hogy egy hiányzó méret a teljes eredetire essen vissza.

Ez különösen jól illik a katalógusokhoz, mert ugyanaz a termékfotó jellemzően három méretben jelenik meg: rácscsempeként, termékoldali képként, és nagyított vagy lightbox nézetként. Képenkénti számlázási modellben ez termékenként három tétel. A Cloudflare modelljében három különálló változat, függetlenül attól, hány terméked van, és a hónapon belüli ismételt kérések nem kerülnek semmibe.

A Cloudflare Image Transformations és a WordPress képbővítmények összehasonlításunk a számlázási modellek különbségeit tárgyalja, és azt, melyik illik milyen alakú tárhoz.

Mit változtass, sorrendben

Ezeket sorban vedd végig. Mindegyik önmagában mérhető, és rossz sorrendben nehéz megmondani, mi segített.

Kezdd azzal, kideríted-e, hogy fennáll-e nálad a méreteltérés, mert ha igen, semmi más nem számít, amíg ez nincs javítva. Ellenőrizd a rácsképek átvitt méretét ahhoz a helyhez képest, amelyet elfoglalnak.

Aztán csökkentsd, hány képet kér az oldal. Kapcsold ki a rámutatásos képeket, ha a sablon előtölti őket, és megvagy az effekt nélkül. Gondold végig, huszonnégy termék oldalanként szolgál-e bárkit, vagy tizenhat gyorsabb betöltéssel jobban konvertál.

Aztán javítsd a lusta betöltés határát, hogy az első látható sor azonnal betöltődjön, alatta pedig semmi.

Aztán foglalkozz a kiszolgálással, hogy a kiszolgált méretek megegyezzenek a megjelenítettekkel, és helyesek maradjanak, amikor a katalógus változik.

Csak mindezek után segít érdemben a gyorsítótárazás. Egy lassú oldal gyorsítótárazása egyenletesen lassúvá teszi, nem gyorssá, és ez az a lépés, amihez elsőként nyúlnak, mert ezt a legkönnyebb telepíteni.

A képeken túli tágabb képért a WooCommerce teljesítménye tárgyalja az adatbázis-lekérdezéseket, a bővítményterhelést és a nem gyorsítótárazott töredékeket, amelyek szintén lassítják a boltokat.

Rendes mérés

A boltosok általában tudják, hogy a bolt lassúnak érződik, de nem tudják, a tucatnyi lehetséges ok közül melyik a felelős. A találgatás drága, mert a kézenfekvő javításokat már megpróbálták.

A Mecanik olyan WordPress teljesítményauditokat készít, amelyek kifejezetten a katalógusoldalakat mérik, nem pedig egy kezdőlapot tesztelnek és kész, és WordPress-fejlesztési munka keretében elvégzi a kivitelezést is, ahol a javítás túlmutat a konfiguráción. Ha a kategóriaoldalaid veszítik el a látogatókat, a mérésnek ott kell kezdődnie.

Kapcsolódó bejegyzések: WooCommerce teljesítmény: miért lassú a webáruháza , Weboldal migráció forgalomvesztés nélkül 2026-ban , Cloudflare Image Transformations vs WordPress bővítmények , E-kereskedelmi webfejlesztés: Shopify vs egyedi megoldás ., GEO webáruházaknak: termékadatok az AI válaszaiban

Gyakran ismételt kérdések

Miért lassabbak a WooCommerce kategóriaoldalak a termékoldalaknál? Egy termékoldal egy főképet tölt be. Egy kategóriaoldal termékenként egyet, amit a rámutatásos képek gyakran megdupláznak, így huszonnégy termék akár negyvennyolc képkérést is jelenthet. Ugyanaz a képkezelés, ami termékoldalon rendben van, rácson rosszul halmozódik.

Honnan tudom, hogy a WooCommerce rossz képméretet szolgál ki? Nyiss meg egy kategóriaoldalt és a böngésző hálózati paneljét, majd hasonlítsd össze a rácsképek átvitt méretét az eredeti feltöltésekkel. Ha hasonlóak, nem pedig töredékek, a sablon olyan méretet kér, amelyet a WordPress sosem generált, és a teljes eredetit kicsinyíti le a böngésző.

Bélyegképet generáljak újra, vagy kiszolgáláskor alakítsak át? Az újragenerálás a jelenlegi katalógust javítja, de minden méret- vagy sablonváltáskor meg kell ismételni. A kiszolgáláskori átalakítás az URL-ből dönti el a méretet, így sablonváltás és új feltöltések után is helyes marad, újragenerálás nélkül.

Segít vagy árt a lusta betöltés a WooCommerce katalógusoldalaknak? Segít, mert egy hosszú rács nagy része a hajtás alatt van, de az első látható sornak azonnal be kell töltődnie. A legnagyobb látható kép lusta betöltése közvetlenül késlelteti a Largest Contentful Paint mérését, és ez gyakori sablon-alapbeállítás.

Hány termék oldalanként a legjobb a teljesítménynek? Kevesebb kép gyorsabb oldalt jelent, de több lapozás több kattintást a böngészéshez. A tizenhat és huszonnégy közötti érték jellemző. A szám sokkal kevésbé számít annál, hogy minden kép helyes méretű-e, mert egy jól méretezett huszonnégyes rács veri a túlméretezett tizenkettest.