Röviden: mit jelent a Core Web Vitals egy webshopnak
A Core Web Vitals webshop esetén három számot jelent, amit a vásárlóid valódi telefonján mérnek: az LCP (milyen gyorsan jelenik meg a fő termékkép) legyen legfeljebb 2,5 másodperc, az INP (milyen gyorsan reagál az oldal a „Kosárba" gombra vagy egy szűrőre) legfeljebb 200 ms, a CLS (mennyit ugrál az elrendezés betöltés közben) pedig legfeljebb 0,1. Minden oldaltípus más miatt bukik el: a termékoldal általában LCP-n, a kategóriaoldal INP-n és CLS-en, a pénztár INP-n. Sablononként javítsd, ne oldalanként.
Miért számít a webshop sebessége jobban, mint gondolnád
A Google a Core Web Vitals értékeket a valós Chrome-látogatások 75. percentilisén méri, 28 napos gördülő ablakban, mobilon és asztali gépen külön. Ha minden negyedik mobilos vásárló 4 másodperc után látja a termékképet, az egész URL-csoport gyengének számít. 2024 márciusa óta az INP váltotta a First Input Delayt, és az INP-n sokkal nehezebb átmenni egy JavaScripttel teli webáruháznak.
A magyar webshopok forgalmának nagy része ma mobilról jön, gyakran mobilnetről. Ezért egy webshop, ami az irodai laptopon „gyors", a valós adatokban mégis elbukhat. Egy webáruháznak három olyan gondja van, ami egy bemutatkozó oldalnak nincs:
- Nagy képek a hajtás felett. A termékfotó szinte mindig az LCP-elem, és sokszor egy 2000 pixeles JPEG egy sliderben.
- Sok interakció. Színválasztó, szűrők, minikosár, mennyiségválasztó: mind beleszámít az INP-be.
- Külső szkriptek. GA4, Meta Pixel, TikTok, értékelés-widget, chat, hírlevél-popup, sütibanner, Árukereső-jelvény.
A költség nem csak SEO. A lassú oldal drágítja a Google- és Meta-hirdetéseket, mert a kattintások egy része még betöltés előtt elmegy.
Hogyan méred az LCP-t, INP-t és CLS-t termék-, kategória- és pénztároldalon
Minden eszköznek megvan a szerepe:
| Eszköz | Adattípus | Mire való |
|---|---|---|
| Search Console, Core Web Vitals jelentés (az Experience szakaszban) | Valós (CrUX), csoportosított URL-ek | Melyik sablon bukik el, mobilon vagy asztalin |
| PageSpeed Insights | Valós + labor | Egy URL: fent a valós adatok, lent a diagnosztika |
| Chrome DevTools → Performance panel | Labor, a saját gépeden | A pontos elem, szkript vagy kattintás megtalálása |
| web-vitals könyvtár vagy GA4-események | Valós, saját adat | Sablononkénti figyelés, a pénztárt is beleértve (ehhez ritkán van elég CrUX-forgalom) |
A Search Console-ban olyan problémákat látsz majd, mint az „LCP issue: longer than 2.5s (mobile)", „INP issue: longer than 200ms (mobile)" vagy „CLS issue: more than 0.1 (mobile)" (magyar felületen lefordítva, de ugyanazokkal a küszöbökkel). Kattints rá, és a Google példa-URL-eket mutat. Ha mind /termek/..., a termékoldal sablonja a hibás.
A hivatalos küszöböket a web.dev Core Web Vitals oldala és a Search Console jelentés súgója írja le.
Melyik webshop-oldal melyik mutatón bukik el
| Sablon | Jellemzően rossz mutató | Tipikus ok |
|---|---|---|
| Főoldal | LCP | Bannerslider, automatikusan induló videó, szöveget blokkoló betűtípusok |
| Kategóriaoldal | INP, CLS | Az egész rácsot újrarajzoló AJAX-szűrők, méret nélküli képek, tartalmat lenyomó „Továbbiak betöltése" |
| Termékoldal | LCP | Lusta betöltésű vagy JS-galériában ülő főkép, optimalizálatlan fotók, renderelést blokkoló CSS |
| Kosár | INP | Végösszeg újraszámolása minden mennyiségváltásnál, cart fragments, kuponmező-szkriptek |
| Pénztár | INP, CLS | Címkiegészítés, későn betöltő fizetési iframe, betöltés után megjelenő szállítási módok |
Elég egy gyorsító bővítmény, vagy jobb tárhely, esetleg új sablon kell?
Mielőtt bármit megveszel, nézd meg, hol a szűk keresztmetszet. Három szintű megoldás van, és mindegyik mást old meg.
| Megoldás | Mit javít | Mit nem javít | Mikor elég |
|---|---|---|---|
| Gyorsítótár/optimalizáló bővítmény (WP Rocket, LiteSpeed Cache, Perfmatters) | TTFB a gyorsítótárazott oldalakon, CSS/JS késleltetés, lusta betöltés | Gyorsítótár nélküli oldalak (kosár, pénztár, belépett B2B-vevők), a sablon nehéz JS-e | Letisztult sablon, kb. 30 bővítmény alatt, főleg vendégforgalom |
| Jobb tárhely (menedzselt VPS, Redis, CDN) | TTFB mindenhol, Black Friday-csúcsok, lassú admin | Elrendezés-ugrás, nehéz szkriptek, túl nagy képek | 800 ms feletti TTFB gyorsítótárral is |
| Új sablon vagy egyedi webshop | LCP-szerkezet, oldalépítőből és sliderből jövő INP, CLS már a tervezésnél | Rossz címkekezelési szokások | Oldalépítő sok kiegészítővel, vagy minden javítás elront valami mást |
Gyakori csapda: két optimalizáló bővítmény, amelyek ugyanazokat a fájlokat minifikálják és fűzik össze. Az eredmény elromlott JavaScript, egy pénztár, ami Uncaught TypeError hibát dob a konzolban, és rosszabb INP, mint korábban. Egy eszközt használj, és a kosarat meg a pénztárat zárd ki a szkriptkésleltetésből.
Az is számít, hol van a szerver. Egy olcsó tengerentúli tárhely magyar vásárlóknak minden kérésnél több száz ezredmásodpercet ad hozzá; egy EU-s szerver CDN-nel ezt megoldja.
Egy harmadik csapda a csak főoldalra optimalizálás. A Google Shoppingból és a hirdetésekből érkező vásárlók többnyire termékoldalon landolnak, az organikus forgalom pedig kategóriaoldalon. Általában ez a két sablon dönti el, mit mutat a Search Console-jelentésed. Ha Árukeresőről vagy Compariról jön sok forgalmad, az is közvetlenül a termékoldalra érkezik, tehát ott számít leginkább minden ezredmásodperc.
Lépésről lépésre: LCP javítása a termékoldalon
- Keresd meg az LCP-elemet. A PageSpeed Insightsban nézd meg a „Largest Contentful Paint element" diagnosztikát. Termékoldalon szinte mindig a galéria első képe.
- Ne töltsd lustán. Vedd le a
loading="lazy"attribútumot az első termékképről, és tedd rá afetchpriority="high"attribútumot. Sok galéria-bővítmény minden képet lustán tölt, az elsőt is. - A megfelelő méretet szolgáld ki. Egy 400 pixeles mobil helyre nem kell 2400 pixeles kép. Készíts rendes
srcsetméreteket, és használj WebP-t vagy AVIF-et. A mobilos főkép legyen 150 KB alatt. - Csökkentsd a szerver válaszidejét. 800 ms feletti TTFB mellett szinte lehetetlen a 2,5 s-os LCP. Teljes oldalas gyorsítótár kell a termék- és kategóriaoldalakra, objektum-gyorsítótár (Redis) a WooCommerce-lekérdezésekhez és CDN.
- Szüntesd meg a renderelést blokkoló CSS-t és JS-t. A kritikus CSS menjen inline, a nem létfontosságú szkriptek késleltetve, a slider-könyvtár pedig mehet, ha a galéria lehet sima HTML CSS scroll snappel.
- Betűtípusok: legfeljebb két fájl,
font-display: swapbeállítással, hogy a szöveg azonnal megjelenjen.
Lépésről lépésre: INP javítása kategóriában, kosárban és pénztárban
Az INP a látogatás leglassabb tipikus interakcióját méri. Webshopokban a hosszú JavaScript-feladatok a bűnösök.
- Szűrők: ne töltsd újra az egész rácsot minden pipánál; használj szerveren renderelt szűrő-URL-eket vagy gyors keresőindexet. Az árcsúszkára tegyél debounce-t.
- Termékváltozatok: kerüld azokat a bővítményeket, amelyek minden kattintásnál JavaScriptben építik újra a teljes változattáblát. A változatadatokat készítsd elő a szerveren.
- WooCommerce cart fragments: a
?wc-ajax=get_refreshed_fragmentskérés sok oldalon lefut a minikosár frissítéséhez. Csak akkor töltsd be, ha a kosár nem üres, vagy cseréld egy kis saját végpontra. - Marketingszkriptek: minden Google Tag Manager-címke munkát ad a fő szálnak. Amit lehet, vigyél szerveroldalra (szerveroldali GA4, Meta Conversions API), a chatet és az értékelés-widgetet késleltesd az első interakcióig, és töröld a címkéket, amiket már senki nem néz.
- Pénztár: csak fizetés, cím és mérés. Se slider, se popup, se upsell.
A Chrome DevToolsban rögzíts egy Performance-felvételt, miközben bepipálsz egy szűrőt. Minden 50 ms-nál hosszabb feladat sarka piros, az „Interactions" sáv pedig megmutatja, melyik kattintás vitte 200 ms fölé az INP-t.
Lépésről lépésre: CLS javítása (ugráló oldal)
A CLS-t általában a legkönnyebb javítani, és ez bosszantja legjobban a vásárlót, főleg ha a „Kosárba" gomb elugrik az ujja alól.
- Minden termékképnek van
widthésheightattribútuma vagy CSSaspect-ratioértéke. - A sütibanner az oldal fölé úszik, nem tolja le.
- Az akciós sávnak („Ingyenes szállítás 20 000 Ft felett") előre foglalt helye van.
- Az értékelés-csillagok, az ár és a „Már csak 3 db" jelzés szerveren renderelődik, nem utólag szúródik be.
- A betűtípusok
font-display: swapbeállítást és hasonló méretű tartalék betűt kapnak. - A pénztár fizetési és cím-iframe-jeinek fix minimális magassága van.
- A „Továbbiak betöltése" a képernyő alá illeszt be, nem fölé.
Core Web Vitals webshop ellenőrzőlista
- Search Console Core Web Vitals jelentés átnézve mobilra és asztalira
- LCP-elem azonosítva a főoldalon, kategória- és termékoldalon
- Az első termékkép nem lusta betöltésű,
fetchpriority="high"beállítással - Képek átméretezve, WebP/AVIF formátumban,
srcsetértékkel - TTFB 800 ms alatt a gyorsítótárazott oldalakon, Magyarországról mérve
- Teljes oldalas gyorsítótár, objektum-gyorsítótár és CDN bekapcsolva
- Felesleges bővítmények és oldalépítő-modulok törölve
- Tag Manager-audit: minden címkének van gazdája és célja
- Cart fragments korlátozva vagy lecserélve
- A pénztár csak a szükséges szkripteket tölti be
- Valós felhasználói mérés sablononként
- Újraellenőrzés 28 nap után, majd a javítás ellenőrzésének elindítása
Mennyibe kerül a Core Web Vitals javítása egy webshopon
Ezek tipikus projektekből vett becslések, nem fix árak. A sáv főleg attól függ, mennyi maradhat a jelenlegi sablonból és bővítményekből. A forintösszegek kb. 365 Ft/€ árfolyammal, kerekítve készültek.1
| Feladat | Tipikus ráfordítás | Becsült költség (EUR, ÁFA nélkül) |
|---|---|---|
| Audit: valós adatok, sablononkénti diagnózis, prioritási lista | 1–3 nap | 400–1200 € (kb. 150 000–440 000 Ft) |
| Gyors javítások: képek, gyorsítótár, lusta betöltés, címketakarítás | 3–8 nap | 1000–3500 € (kb. 365 000–1 280 000 Ft) |
| Új sablon ugyanazon a WooCommerce-adatbázison | 3–8 hét | 4000–12 000 € |
| Jobb tárhely (menedzselt VPS gyorsítótárral és CDN-nel) | havonta | 30–150 € havonta |
Ha nehéz oldalépítőd és 40-nél több bővítményed van, két év alatt gyakran olcsóbb egy új sablon, mint az ismételt foltozgatás. A Raaónál a sebesség az alap: a Starter csomag (1900 €-tól) és a Launch csomag (3900 €-tól) is gyors betöltést tartalmaz, a Launch pedig alapból CDN-t, gyorsítótárat és képoptimalizálást. Az általunk üzemeltetett szervereken a hosting és karbantartás havi 89 €-tól indul (ÁFA nélkül). A részletek a webshop-fejlesztés és az árak oldalon vannak.
Ha szeretnél egy második véleményt a Search Console-jelentésedről, az ingyenes 30 perces hívás jó kezdet: írj nekünk.
Hogyan csináltuk a Kuibánál
A Kuiba prémium bútort és világítást árul, több mint 10 000 konfigurálható termékkel, 25-nél több európai márkától. A sebességnek ekkora katalógust és rengeteg marketingszkriptet kellett kibírnia.
- Egyedi, sebességre és SEO-ra épített webshop, nem oldalépítős rétegekkel teli sablon.
- Azonnali szűrős keresés szinonimákkal és AI-tartalékkal, hogy a nagy katalógus szűrése is gyors maradjon.
- Szerveroldali GA4 és Meta Conversions API, hogy a mérés pontos legyen anélkül, hogy minden pixel a vásárló böngészőjében töltődne.
- Google Merchant-, Meta-, TikTok- és Pinterest-feedek a teljes katalógusból.
- Termékkonfigurátor ármátrixszal, felületekkel és méretekkel, amely online is helyesen áraz.
Kerekített számítási árfolyam, nem hivatalos MNB-adat; 2026 októberében az euró nagyjából 365–370 Ft körül mozgott. A hivatalos napi árfolyam az MNB oldalán található. Ellenőrizve: 2026. október. ↩