Core Web Vitals és webshop-sebesség: amit egy motoros valóban mérni tud

Van egy egyszerű teszt, amit bárki elvégezhet: fogd a telefonod, kapcsold ki a wifit, és nyisd meg a saját termékoldaladat mobiladaton. Ha közben van időd elolvasni egy üzenetet, a vevőidnek is van — csak ők nem várnak, hanem visszalépnek a Google találati listájára. A lassú webshop nem „kényelmetlen”. Elveszett rendelés, amit soha nem látsz a statisztikában, mert az a vevő meg sem érkezett a kosárig.

Ez a cikk nem tesz technikai szakértővé, és nem is akar. Azt nézzük meg, mit jelent a három Core Web Vitals mutató emberi nyelven, mit tudsz belőle magad orvosolni egy sablonos motor (Shoprenter, UNAS és társaik) korlátain belül, és mikor éri meg fejlesztőt fizetni.

Miért számít a sebesség a vevőmegtartásban

Tizenöt éve dolgozom webáruházakkal, és a sebességről szóló beszélgetés majdnem mindig ugyanúgy indul: „nálam gyorsan betölt”. Persze — a te gépeden, a te vezetékes interneteden, a böngésződ gyorsítótárából, amiben már bent van az oldal minden képe. A vevő viszont először jár nálad, telefonról, ingázás közben, gyenge térerőn.

A lassú betöltés három ponton üt. Az első benyomásnál: az üres vagy félig betöltött oldal azt üzeni, hogy „ez a bolt nem működik rendesen”. A visszatérő látogatónál: ha egyszer megvárakoztattad, legközelebb inkább a versenytársat nyitja meg. És a keresőben: a Google is figyeli a valós felhasználói élményt — de ezt ne ezért javítsd, hanem azért, mert a vevő nem szeret várni.

A három mutató, magyarul

A Core Web Vitals három dolgot mér. Nem kell a másodperc-küszöböket fejből tudnod; a mérőeszközök zöld–sárga–piros színnel megmondják. A te dolgod az, hogy értsd, mit jelentenek.

• Betöltés (a szakzsargonban LCP): mennyi idő alatt jelenik meg a lényeg — általában a főkép vagy a címsor. Ha ez lassú, a látogató üres oldalt bámul, és nem tudja, jó helyen jár-e.
• Interaktivitás (INP): amikor rákattintasz valamire — menü, szűrő, „kosárba” —, mennyi idő alatt reagál az oldal. Ha késik, a vevő kétszer kattint, összezavarodik, elmegy.
• Vizuális stabilitás (CLS): ugrál-e a tartalom betöltés közben. A klasszikus eset: rá akarsz nyomni egy gombra, de fölé beugrik egy késve betöltő kép, és véletlenül a hírlevél-feliratkozásra kattintasz.

Amit magad is meg tudsz csinálni

A legtöbb sebességprobléma nem kódhiba, hanem felhalmozódott súly. Ezeket fejlesztő nélkül is le tudod faragni:

• Képek. Ez a leggyakoribb bűnös. A 4000 pixel széles, 3 MB-os termékfotó a vásárló telefonján ugyanúgy néz ki, mint egy 200 KB-os, rendesen tömörített változat — csak sokszorosan lassabban tölt. Tömöríts feltöltés előtt (TinyPNG, Squoosh vagy a motor beépített képkezelője), és ne tölts fel nagyobb méretet, mint amekkora helyen a kép megjelenik.
• Felesleges bővítmények és külső szkriptek. Minden „csak beillesztem ezt a kis kódot” — élő chat, három különböző analitika, exit-popup, vélemény-widget, cookie-sáv — lassít. Nézd végig, mi fut az oldaladon, és amit egy éve nem néztél meg és nem hoz pénzt, azt kapcsold ki.
• Főoldali dia-vetítő. A csillogó slider öt nagy képpel szinte mindig többet árt, mint használ. Egy statikus, jól tömörített hero-kép gyorsabb, és általában jobban is konvertál.
• Tárhely. Ha a legolcsóbb megosztott csomagon vagy, és forgalmasabb időszakban belassul minden, a host lehet a szűk keresztmetszet. SaaS-motornál ez adott, de saját üzemeltetésű WooCommerce-nél a csomagváltás néha a legolcsóbb gyorsítás.
• Betűtípusok és háttérvideó. A három egyedi webfont és az automatikusan induló főoldali videó látványos, de másodpercekben fizetsz érte.

Mikor hívj fejlesztőt

Akkor, ha a fentieket végigcsináltad, és a mérés még mindig piros — vagy ha a jelentés olyasmit ír, hogy „szerver válaszideje” vagy „renderelést blokkoló erőforrások”. Ez már kód, nem tartalom.

Amit konkrétan kérj tőle: „a PageSpeed Insights mobil jelentése alapján javítsd a három legnagyobb tételt, és mondd meg, mit nem lehet a jelenlegi sablonnal megoldani.” Kérj előtte-utána mérést, hogy lásd, miért fizettél.

Óvatosan a „sebességoptimalizálás” nevű nagy csomagokkal: sokszor olyat számláznak ki drágán, amit a képtömörítés és két bővítmény kikapcsolása jórészt megoldott volna. Ezért kezdd te.

Hogyan mérd, technikai tudás nélkül

• PageSpeed Insights: írd be az URL-t, nézd a „mobil” fület. A „mezőadatok” (valós látogatóktól) többet érnek, mint a laboradat.
• Google Search Console → Core Web Vitals jelentés: ez a saját látogatóid valós élménye, oldalcsoportokra bontva. Itt látod, hány URL „gyenge”.
• Elég havonta egyszer ránézni. Nagyobb sablonváltás vagy új bővítmény után viszont mindig mérj — előtte és utána is.

Rövid ellenőrzőlista

• Nyisd meg a saját oldalad mobiladaton, idegen szemmel.
• Tömörítsd a főoldal és a top 10 termék képeit.
• Listázd a futó bővítményeket és appokat, kapcsold ki a feleslegeset.
• Cseréld le a főoldali dia-vetítőt statikus képre, és nézd meg, változik-e a konverzió.
• Mérj PageSpeed Insightsszal előtte és utána.

A lassú betöltés az egyik leggyakoribb rejtett súrlódási pont a fizetés előtt — a többiről a konverzióoptimalizálás pillércikkben és a checkout súrlódási pontjairól szóló írásban van szó részletesen.

A sebesség nem külön projekt, hanem karbantartás — mint a raktárrend. Ha viszont azt szeretnéd, hogy valaki végigmenjen az egész webshopodon, és megmutassa, hol veszítesz vevőt — nemcsak a sebességnél, hanem a termékadatnál, a checkoutnál, a szállítási információknál is —, annak szól az AI-alapú webshop-auditom. Priorizált listát kapsz arról, mi hozza a legtöbb eredményt a legkevesebb munkával.