A Core Web Vitals a Google három alapvető teljesítmény-metrikájának összefoglaló neve, amik a felhasználói élményt mérik: mennyire gyorsan jelenik meg az oldal fő tartalma, mennyire reagál a kattintásokra, és mennyire stabil a layout. 2021 óta beleszámít a Google Search rangsorolásába is, és bár nem ez a legnagyobb súlyú tényező, vetélkedő találatok között komoly különbséget tud tenni. A három metrika egyébként ennél jóval többre is használható: tisztán fejlesztési szempontból is hasznos visszajelzés arról, hogy a kódod jól dolgozik-e.
Így is ismerheted
Magyarul leggyakrabban alapvető webmutatók-nak vagy fő webes teljesítménymutatók-nak fordítják, de a szakmában gyakorlatilag mindenki a Core Web Vitals nevet vagy a CWV rövidítést használja. A „Web Vitals” tágabb koncepció (több metrika), a Core Web Vitals ennek a kiemelt három metrikája. Kapcsolódó fogalmak: Lighthouse (mérőeszköz), PageSpeed Insights (PSI — Google online tool), CrUX (Chrome User Experience Report, valós user-adat). A 2024 márciusi változással az FID (First Input Delay) metrikát kicserélték INP-re (Interaction to Next Paint) — ez érzékenyebb és jobban tükrözi a valódi élményt.
A három metrika részletesen
LCP — Largest Contentful Paint
Az LCP azt méri, mennyi idő alatt jelenik meg a viewport legnagyobb látható tartalmi eleme — általában a hero-kép, egy nagy heading, vagy a fő poster. Ha 2.5 másodperc alatt megvan, „Good” minősítést kap. 2.5–4 másodperc „Needs improvement”, 4 másodperc fölött „Poor”. A leggyakoribb okok lassú LCP-re: lassú szerver-válasz (TTFB), nehéz főkép, render-blokkoló CSS/JS.
INP — Interaction to Next Paint
Az INP a kattintásra/tap-re adott reakcióidő — pontosabban: mennyi idő telik a click eseménytől a következő frame megjelenéséig. 200 ms alatt „Good”, 200–500 ms „Needs improvement”, 500 ms fölött „Poor”. Tipikus baki: súlyos JavaScript blokkolja a main thread-et (pl. analytics-script egy heavy webhook-kal), és a click „beleragad” — a user kétszer kattint, mert nem érzi a választ.
CLS — Cumulative Layout Shift
A CLS azt mutatja, mennyit „ugrál” a layout a betöltés során. 0.1 alatt „Good”, 0.25 alatt „Needs improvement”, felette „Poor”. Tipikus baki: image-tag-eken nincs width és height, ezért a kép megérkezésekor lökődik el a szöveg; vagy egy header-banner késik, és lefelé csúszik az egész content.
Mit érdemes optimalizálni — gyors win-ek
A legtöbb projekten 3-4 alapvető beavatkozással már 60-os Lighthouse Performance pontszámról 85-90 fölé kerülhetsz. Mi mindig ezzel kezdjük az auditot:
- Képoptimalizálás — WebP/AVIF formátumokban, lazy-loading-gal, explicit width/height-tel. Ez fix LCP + CLS.
- CSS és JS minify + defer — render-blokkoló kódot async-be / defer-be. LiteSpeed Cache, WP Rocket, vagy egyedi build-pipeline.
- CDN bekötése — statikus tartalom globálisan közelebb a látogatóhoz, kevésbé függő a fő-szerver TTFB-jétől.
- 3rd-party script-ek korlátozása — Google Analytics, Facebook Pixel, hotjar mind hozzáadnak 100-500 ms-ot. Csak amire tényleg szükség van.
- Font-optimalizálás —
font-display: swap, lokálisan hosztolva, csak a használt karakterkészlettel.
Mérés — Lighthouse, PSI, CrUX
Háromféleképpen érdemes mérni, mindhárom mást mond:
- Lighthouse / Chrome DevTools — szintetikus mérés a saját gépedről. Gyors, de eltérhet a valódi user-adattól.
- PageSpeed Insights — szintetikus + valós (28 napos CrUX adat). A „Field Data” rész a tényleges felhasználói tapasztalat.
- Search Console — Page Experience — Google saját jelentése arról, mit lát ő a CWV oldalán. 28 napos átlag, ami a rangsorolásba beleszámít.
Egy fontos tapasztalat: a Lighthouse pontszám gyakran jobb, mint a valódi CrUX-adat. Egy projekten, ahol a Lighthouse 95-öt mutatott, a valódi user-adat „Poor”-nak minősült — kiderült, hogy a látogatók 30%-a mobil 3G-n érkezett, ahol minden lassabb. Mindig nézd meg a Field Data-t is, ne csak a Lab Data-t.
Mire figyelj — gyakori CWV-hibák
A leggyakoribb csapdák, amiket projekt-auditokon visszatérően látunk:
- Layout shift hero-képen — a kép megjelenésekor a teljes content lökődik le. Megoldás:
aspect-ratioCSS vagy explicit width/height. - Cookie-banner CLS — a GDPR-banner késve jelenik meg, és lökődik le minden. Megoldás: bottom-fix vagy modal-ban renderelve.
- Heavy hero-video — autoplay video blokkolja az LCP-t. Megoldás: poster-kép, video lazy-loaded.
- 3rd-party widget INP-blokkolás — Intercom, Drift, Tawk.to chat-widget-ek beletehetnek 300-500 ms-ot. Késleltetett betöltés (user-interakcióra).
2026-os trendek — INP és Page Experience
A 2024 márciusi INP-bevezetés óta sok projekten újra kellett gondolni a JS-bundle stratégiát. A „minden React-tel” megközelítés egy bemutatkozó oldalon ma már antipattern — astro.js, server-rendered HTML és progresszív enhancement nyer. A heavy SPA-k INP-szempontból gyengébbek, mert minden interakció megdolgoztatja a main thread-et.
Google jelezte, hogy a Page Experience egyre több jelet vesz figyelembe — várhatóan a 2026-ban már HTTPS, mobile-friendly, és kéretlen interstitial-ok is részletesebben fognak rangsorolni. A Core Web Vitals viszont valószínűleg ez a három metrika marad a következő évekre — Google nagy mérnöki gárdát fektetett a mérési rendszerbe, nem fogja egyhamar lecserélni.
Ha Core Web Vitals optimalizációval, performance-audittal, vagy egy lassú oldal újragondolásával foglalkoznál, lásd az egyedi weboldal-fejlesztés szolgáltatásunkat. Kapcsolódó cikkek: Lighthouse, CDN, Schema.org. A hivatalos doksi az web.dev/vitals-on érhető el.
