Termékoldal gyorsítása: mit vágj ki és mit tarts meg

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

Ha valaha összehasonlítottad ugyanannak a webshopnak egy szolgáltatás-aloldalát és egy termékoldalát ugyanazzal a mérőeszközzel, valószínűleg meglepődtél a különbségen. Ugyanaz a sablon, ugyanaz a szerver, ugyanaz a tárhely, mégis az egyik három másodperc alatt használható, a másik nyolc alatt sem. A különbség nem véletlen, és nem is a képeken múlik. Az alábbiakban végigmegyünk azon, mi terheli valójában a termékoldalt, milyen sorrendben érdemes hozzányúlni, és hogyan nézz át egy konkrét oldalt úgy, hogy a végén tudd, mit vágsz ki, mit tolsz későbbre, és mit hagysz békén.

Miért lassabb egy termékoldal, mint egy sima aloldal?

Mert a termékoldal nem dokumentum, hanem kis alkalmazás. Egy szolgáltatás-aloldalon szöveg van, néhány kép, pár link. Egy termékoldalon ezzel szemben ott a képgaléria, a méret- és színválasztó, a készletinformáció, a kosárba tevés, az ajánlómodulok, a vélemények, a csevegőablak és a mérőkódok sora. Ezek nagy része JavaScript, a JavaScript pedig a böngésző szempontjából a legdrágább nyersanyag: le kell tölteni, ki kell tömöríteni, elemezni, lefordítani és lefuttatni, ráadásul ugyanazon a szálon, amelyen a felhasználó kattintására is válaszolni kellene.

(Hivatalosan igazolt) A Google Web Vitals dokumentációja szerint a válaszkészséget mérő INP mutatót elsősorban a hosszan futó feladatok rontják el, vagyis azok a szkriptek, amelyek 50 ezredmásodpercnél tovább foglalják a főszálat. Nem az a baj, hogy sok a kód, hanem hogy nagy összefüggő blokkokban fut, és ilyenkor a böngésző egyszerűen nem ér rá reagálni.

Van egy szerveroldali réteg is. Egy termékoldal a legtöbb rendszerben lényegesen több adatbázis-lekérdezést generál, mint egy statikus tartalmú aloldal: változatok, árszabályok, akciók, készletszint, kapcsolódó termékek, kosár-állapot. Ha az oldal-gyorsítótár a kosár vagy a bejelentkezett állapot miatt ki van kapcsolva a termékoldalakon, akkor minden látogató friss futtatást kap, és a szerver válaszideje azonnal megjelenik a betöltési mutatókban is.

Mely elemek terhelik a leginkább a termékoldalt?

A sorrend, amit a gyakorlatban a leggyakrabban látni: külső szkriptek, ajánlómodulok, csevegőablak, vélemények, változatválasztó, végül a képek. Ez a sorrend sokakat meglep, mert a képekről beszélünk a legtöbbet.

• Követő- és marketingkódok. Egy átlagos hazai webshop termékoldalán nem ritka a nyolc-tíz külső szkript: analitika, hirdetési képpontok, remarketing, hőtérkép, A/B tesztelő, sütikezelő, konverziókövető. Ezek java része harmadik fél domainjéről tölt be, vagyis külön DNS-feloldás, külön kapcsolatépítés, és olyan futásidő, amit te nem tudsz befolyásolni.
• Ajánlómodulok a lap alján. A „hasonló termékek”, „mások ezt is megvették”, „legutóbb megtekintett” blokkok gyakran külön lekérdezésekkel, saját JavaScript-csúszkával és tucatnyi további termékképpel érkeznek. A látogató nagy része soha nem görget el odáig, a böngésző mégis kifizeti az árát.
• Csevegőablak. Egyetlen chatbeágyazás simán hozhat több száz kilobájt JavaScriptet, saját betűtípust és időzítőket, amelyek a betöltés után is dolgoznak.
• Vélemények, értékelések. Ha külső szolgáltatótól jönnek, gyakran iframe-ben vagy kliensoldali lekérdezéssel töltődnek be, és a csillagos átlag megjelenése után elmozdítják a lap tartalmát.
• Képgaléria. Nyolc-tíz nagy felbontású kép, mindegyik előre betöltve, plusz egy galéria-könyvtár. Súlyos, de jól kezelhető, mert szabványos eszközök vannak rá.
• Változatválasztó. Önmagában ritkán nehéz, de ha minden színváltásnál szerverhez fordul árért és készletért, akkor nem a betöltést, hanem a használat élményét rontja.

(Saját tapasztalat) Amikor termékoldalakat nézek át, a mérhető javulás nagyobbik része szinte mindig két helyről jön: a lap alján lévő modulok késleltetéséből és a külső szkriptek megritkításából. A képek további tömörítése ehhez képest kisebb tétel, mert a modern képformátumok és a lusta betöltés a legtöbb rendszerben már alapból be van kapcsolva. Ez tapasztalati megfigyelés, nem törvényszerűség: ha valaki tényleg négy megabájtos JPEG-eket tesz ki, ott persze a kép a főbűnös.

Mit mérj először, mielőtt bármihez hozzányúlnál?

Először valós felhasználói adatot nézz, csak utána laborteszte. A labormérés (PageSpeed Insights, Lighthouse) egyetlen szimulált eszközön futtat le egy betöltést, a mezei adat (CrUX, Search Console Core Web Vitals jelentés) viszont azt mutatja, mit élnek meg a tényleges látogatók, mobilon, gyenge hálózaton.

1. Search Console, Web Vitals jelentés. Nézd meg, a termékoldalak URL-csoportja melyik mutatón bukik: LCP (a legnagyobb tartalmi elem megjelenése), INP (válaszkészség) vagy CLS (elmozdulás).
2. PageSpeed Insights, mobil nézet, három tipikus termékoldalra. Egy olcsó, egy drága és egy sok változattal rendelkező termékre, mert ezek eltérően viselkednek.
3. Böngésző, Hálózat fül, gyorsítótár kikapcsolva. Rendezd a listát méret szerint, majd domain szerint. Írd fel, hány külön domainről tölt be valami. Ez a lista lesz a javítási terved gerince.
4. Teljesítmény fül, hosszú feladatok. Vedd fel a betöltést, és keresd az 50 ezredmásodpercnél hosszabb blokkokat. Kattints rájuk: a hívási lánc megmutatja, melyik szkript a felelős.
5. Szerveroldali válaszidő. Ha a HTML első bájtja fél másodpercnél később érkezik, akkor előbb a gyorsítótárral és az adatbázis-lekérdezésekkel van dolgod, nem a frontenddel.

(Szakmai feltételezés) Erős a gyanúm, hogy a legtöbb termékoldal-optimalizálás azért fut zátonyra, mert a mérés a javítás után történik, nem előtte. Kiindulási érték nélkül nem tudod eldönteni, hogy a változás a te munkád eredménye, vagy csak a mérés szórása.

Milyen sorrendben érdemes javítani?

Előbb vedd el, aztán halaszd el, és csak legvégül optimalizáld azt, ami maradt. Ez a három lépés különböző erőfeszítést kíván, és fordított arányban hoz eredményt.

1. Kivágás. Nézd végig a külső szkriptek listáját, és kérdezd meg minden egyes tételről: ki nézte meg az elmúlt fél évben az adatait? A hőtérkép-eszköz, a rég lejárt kampány képpontja, a két párhuzamos analitika közül az egyik, a már nem használt A/B tesztelő, ezek jellemzően csak azért vannak ott, mert senki nem merte kivenni. Az eltávolítás az egyetlen biztosan működő gyorsítás.
2. Késleltetés. Ami maradt, azt ne az első képernyővel egyszerre töltsd be. A lap alján lévő ajánlómodulok, vélemények, hírlevél-doboz, közösségi beágyazások és a csevegőablak mind várhat.
3. Első képernyő rendbetétele. A fő termékkép kapjon fetchpriority="high" jelzést, és semmiképp ne legyen rajta loading="lazy". A többi galériakép viszont igen. Adj a képeknek fix width és height értéket, hogy ne ugráljon a tartalom.
4. Betűtípusok. Legfeljebb két vágat, font-display: swap, és lehetőleg saját domainről kiszolgálva.
5. Szerveroldal. Termékoldal-szintű gyorsítótár, a dinamikus részek (kosár, készlet) külön lekérdezéssel frissítve.
6. Képtömörítés és formátumváltás. Fontos, de a lista végén, mert a legtöbb rendszerben ez már részben megoldott.

Mit tölts be csak interakcióra?

Mindent, ami nem befolyásolja a vásárlási döntés első harminc másodpercét. A gyakorlatban ez a lap alsó kétharmada. Két egyszerű technika visz nagyon messzire.

Az első a natív lusta betöltés a képekre és beágyazásokra: loading="lazy" minden olyan képre, amely nem látszik az első képernyőn, valamint a videó- és térképbeágyazásokra. (Hivatalosan igazolt) Ez ma minden nagy böngészőben támogatott szabvány.

A második a görgetésre indított betöltés. Egy IntersectionObserver figyeli, mikor közelít a felhasználó az ajánlómodulhoz, és csak akkor kéri le az adatot:

const io = new IntersectionObserver((e) => { if (e[0].isIntersecting) { io.disconnect(); betoltAjanlott(); } }, { rootMargin: "400px" });

A 400 képpontos ráhagyás miatt a modul már azelőtt elkezd betöltődni, hogy a látogató odaérne, tehát nem lesz üres folt. Ugyanez a minta működik a véleményeknél és a csevegőablaknál is, azzal a különbséggel, hogy a chatet érdemes inkább egy saját, könnyű gombhoz kötni: a látogató rákattint, és csak akkor érkezik meg az igazi felület.

A CSS oldalán a content-visibility: auto tulajdonság megspórolja a képernyőn kívüli szakaszok elrendezését és rajzolását. Használatakor adj meg contain-intrinsic-size értéket is, különben a görgetősáv ugrálni fog.

A követőkódoknál a defer és az async attribútum a minimum. Ennél többet ér, ha a nem kritikus mérőkódokat a sütikezelő beleegyezése után, vagy az első felhasználói mozdulatra (görgetés, egérmozgás, érintés) indítod. (Szakmai feltételezés) Ez a megközelítés a mérési pontosságból veszít valamennyit, mert a nagyon gyorsan távozó látogatók kimaradhatnak. Cserébe a maradék adat használhatóbb oldalról érkezik. A kettő közötti egyensúlyt üzletileg kell eldönteni, nem technikailag.

Hogyan nézz át egy tipikus termékoldalt, lépésről lépésre?

Vegyünk egy szokásos felépítést: fejléc kereséssel és kosárral, fő termékkép plusz hét galériakép, cím, ár, méretválasztó, kosárgomb, leírás füles elrendezésben, műszaki adatok, tizennyolc vélemény, „hasonló termékek” csúszka tizenkét termékkel, „legutóbb megtekintett” sáv, lábléc, csevegőablak, sütisáv, négy mérőkód.

Az átvizsgálás menete:

• Fejléc. A kereső előrejelző funkciója gyakran külön szkriptet hoz. Ha csak kattintásra nyílik, akkor kattintásra töltsd be.
• Fő kép. Ez az LCP-elem. Kapjon magas prioritást, ne legyen lusta betöltésű, és lehetőleg ne CSS-háttérképként jelenjen meg, mert azt a böngésző később fedezi fel.
• Galéria hét további képe. Mind lusta betöltésű, a galériakönyvtár pedig csak az első kattintásra töltődjön be.
• Ár, készlet, méretválasztó. Maradjon a kiszolgált HTML-ben. Ezt ne késleltesd, ne töltsd be JavaScripttel, mert ez a lap üzleti magja, és a keresők, illetve a válaszmotorok is ezt olvassák ki elsőként.
• Leírás fülek. A tartalom legyen benne a HTML-ben (a rejtett fülek tartalmát a keresők látják), de az elrejtést CSS oldja meg, ne szkript.
• Vélemények. Az első három vélemény és az összesített értékelés jöjjön a szerverről, a többi „továbbiak” gombra. Ha külső szolgáltatót használsz, tarts fenn helyet neki, hogy ne ugorjon a tartalom.
• Hasonló termékek és legutóbb megtekintett. Görgetésre. Itt szokott a legnagyobb egyszeri nyereség lenni.
• Csevegőablak. Saját gomb, kattintásra töltődő felület.
• Mérőkódok. Négy helyett kettő. Ami marad, az halasztva.

Ha ezt végigcsinálod, jellemzően a betöltött JavaScript mennyisége felére-harmadára esik, anélkül hogy egyetlen funkció eltűnne. Az eredmény oldalanként eltér, tehát garancia nincs rá, de a javulás iránya megbízható.

Mi az, amit semmiképp ne vágj ki?

Amit a vásárló és a válaszmotor is a HTML-ből olvas ki. Az ár, a pénznem, a készlet, a szállítási idő, a fő termékkép, a terméknév, a márka, a cikkszám és a strukturált adat. (Hivatalosan igazolt) A Schema.org Product jelölés és a hozzá tartozó Offer, valamint AggregateRating tulajdonságok a Google termék-strukturáltadat dokumentációjában szereplő feltételek, ezek elhagyása a gazdag találati megjelenítés esélyét veszi el.

(Szakmai feltételezés) Az AI-alapú válaszmotorok és az oldalakat önállóan böngésző ügynökök esetében a kiszolgált HTML tartalma vélhetően még nagyobb súlyt kap, mint a hagyományos keresésben, mert ezek a rendszerek nem feltétlenül futtatnak JavaScriptet, vagy nem várják meg a késleltetett betöltést. Ez nem hivatalosan kihirdetett szabály, hanem a megfigyelt viselkedésből következő óvatos következtetés. A gyakorlati tanulság viszont egyértelmű: a késleltetés a díszítést és a mérést érintse, a lényegi termékadatot soha.

Milyen ellenőrzőlistán menj végig?

• Van kiindulási mérésem három tipikus termékoldalról, mobilon?
• Felírtam, hány külső domain tölt be szkriptet, és mindegyikről tudom, ki használja?
• A fő termékkép magas prioritású, nem lusta betöltésű, és nem CSS-háttérkép?
• Minden más kép és beágyazás lusta betöltésű, fix méretaránnyal?
• Az ajánlómodulok görgetésre töltődnek?
• A csevegőablak csak kattintásra jelenik meg?
• A vélemények első adagja a HTML-ben van, a többi gombra?
• A követőkódok halasztva vagy első interakcióra indulnak?
• Legfeljebb két betűvágat tölt be, font-display: swap beállítással?
• Az ár, a készlet és a strukturált adat a kiszolgált HTML-ben van?
• A szerver első bájtja fél másodpercen belül megérkezik?
• Újramértem ugyanazon a három oldalon, és összevetettem a kiindulással?

Ez a lista nem helyettesíti a fejlesztői döntéseket, de kordában tartja a folyamatot. A leggyakoribb hiba nem az, hogy valaki rossz technikát választ, hanem hogy mindent egyszerre nyúl meg, és a végén nem tudja, mi segített. Egy változtatás, egy mérés, egy tanulság: lassabbnak tűnik, valójában gyorsabb.

Források és további olvasnivalók

• Google Search Central: Core Web Vitals és oldalélmény dokumentáció
• web.dev: Optimize Interaction to Next Paint, Optimize Largest Contentful Paint
• Google Search Central: Product strukturált adat dokumentáció
• Schema.org: Product, Offer, AggregateRating típusdefiníciók
• MDN Web Docs: loading attribútum, IntersectionObserver API, content-visibility
• W3C: Web Performance Working Group specifikációk
• Chrome for Developers: Chrome DevTools Performance és Network panel útmutatók