Core Web Vitals értékelés | AI Web teszt Tudástár

Mi az a Core Web Vitals?

A Core Web Vitals (röviden: CWV) a Google által 2020-ban bevezetett, három alapvető teljesítménymetrikából álló készlet, amely a weboldalak valós felhasználói élményének méréséhez nyújt egységesített keretrendszert. Ezek a mérőszámok nem csupán technikai indikátorok: közvetlenül befolyásolják, hogyan rangsorolja a Google keresője az oldalakat, és milyen élményt nyújtasz a látogatóidnak. A három metrika - LCP, INP és CLS - együtt fedi le a betöltési sebesség, az interaktivitás és a vizuális stabilitás három kritikus dimenziójat.

A Google a Core Web Vitals adatokat a Chrome User Experience Report (CrUX) adatbázisból gyűjti, amely valóban a Chrome böngészőből származó, anonim felhasználói adatokra épül. Ez a megközelítés azt jelenti, hogy nem laborkörnyezeti (szintetikus) tesztekről van szó, hanem valós látogatók által tapasztalt teljesítménymutatók összesítéséről. Így a CWV eredményed közvetlenül tükrözi, mit tapasztalnak a felhasználóid - legyen szó lassabb mobilhálózatról, régebbi típusú készülékekről vagy gyors asztali kapcsolatról.

Miért számít mindez? 2021 júniusa óta a Core Web Vitals hivatalosan is rangsorolási tényező a Google-ben. Ez azt jelenti, hogy két egyébként hasonló tartalmú és relevanciájú oldal közül az nyer jobb pozíciót, amelyik jobb CWV mutatókkal rendelkezik. Emellett a Google a keresési találatok között vizuálisan is jelöli a jó teljesítményű oldalakat, ami magasabb áttérési arányt (CTR) eredményez. Az AI Web teszt audit emiatt allokált 25 pontot - a maximális 100-ból - ennek a pillérnek: mert a teljesítmény közvetlenül hatással van mind a rangsorolásra, mind az üzleti eredményekre.

LCP (Largest Contentful Paint) - Betöltési teljesítmény

Az LCP azt méri, mennyi idő telik el az oldal betöltésétől addig, amíg a legnagyobb vizuálisan látható elem (általában a hero kép, címsor blokk, vagy egy nagy szöveges terület) teljesen megjelenik a képernyőn. Ez a metrika közvetlenül a felhasználó első benyomását ragadja meg: mennyire tűnik gyorsnak az oldal?

Jó: 2,5 másodperc alatt
Javításra szorul: 2,5 - 4 másodperc között
Gyenge: 4 másodperc felett

A tipikus LCP elemek közé tartozik a hero kép, egy nagy háttérkép, egy videó poszter képkocka, vagy egy nagy szöveges blokk (pl. <h1> tag). Ha az oldalad legfontosabb vizuális eleme lassan töltődik be, a felhasználók hajlamosak elnavigálni - a Google adatai szerint a 2,5 másodperc feletti LCP esetén 24%-kal nő a visszapattanási arány.

INP (Interaction to Next Paint) - Reakcióképesség

Az INP (Interaction to Next Paint) 2024 márciusában váltotta fel a korábbi FID (First Input Delay) metrikát. Amíg a FID csak az első interakciót mérte, az INP az oldal teljes életciklusa során történő összes felhasználói interakciót figyeli - kattintásokat, görgetést, billentyűleütéseket -, és a legrosszabb várakozási időt jelenti.

Jó: 200 ezredmásodperc (ms) alatt
Javításra szorul: 200 - 500 ms között
Gyenge: 500 ms felett

Az INP azt méri, mennyi idő telik el a felhasználó cselekvése (pl. egy gombra kattintás) és az ennek hatására bekövetkező vizuális változás között. Ha egy gombra kattintva 800 ms-ig nem történik semmi látható, a felhasználó bizonytalanná válik, és esetleg újra kattint - ami duplázott eseményekhez és rossz élményhez vezet.

CLS (Cumulative Layout Shift) - Vizuális stabilitás

A CLS (Cumulative Layout Shift) a vizuális stabilitás mérőszáma. Azt figyeli, mennyire mozdulnak el váratlanul az oldal elemei betöltés közben. Ha valaha is elkezdtél olvasni egy cikket, és hirtelen az egész szöveg lecsúszott, mert betöltődött egy hirdetés felette - azt mérte a CLS.

Jó: 0,1 alatt
Javításra szorul: 0,1 - 0,25 között
Gyenge: 0,25 felett

A CLS értéket úgy számítja a Google, hogy az elmozduló elem méretének és az elmozdulás távolságának a szorzatát összesíti az oldal betöltése során. Az eredmény egy egység nélküli szám - minél kisebb, annál jobb. A leggyakoribb CLS okozók: képek méretmegadás nélkül, dinamikusan betöltődő hirdetések, és webfontok cseréjekor bekövetkező szövegszélesség-változás.

Labor adat vs. valódi adat - miért számít mindkettő?

Fontos megérteni a különbséget a labor (szintetikus) adatok és a valódi felhasználói adatok (field data) között. A Lighthouse eszköz labor adatokat generál: egy kontrollált környezetben, meghatározott eszköz- és hálózati beállításokkal szimulál betöltést. Ez kiválóan alkalmas a fejlesztési fázisban a problémafeltárásra és a javítások ellenőrzésére.

Ezzel szemben a CrUX (Chrome User Experience Report) valódi felhasználóktól gyűjt adatokat. A CrUX a 75. percentilisen értékel, ami azt jelenti, hogy a látogatóid 75%-ának kell az adott küszöbérték alatti élményt kapnia ahhoz, hogy az oldal "jó" minősítésű legyen. Ez szigorúbb, de reálisabb mérték.

Az AI Web teszt audit mindkettőt figyelembe veszi: a Lighthouse pontszám gyors, azonnali eredményt ad, míg a CrUX adatok (ha elegendő forgalom áll rendelkezésre) a valóságot tükrözik. A legjobb stratégia: javíts a Lighthouse alapján, validáld a CrUX adatokkal.

Az audit mérési pontjai

Az AI Web teszt Core Web Vitals pillérje nem csupán egyetlen számra hagyatkozik. A 25 pont előállításához az audit többrétegű mérést végez, amely a következő területekre terjed ki:

Lighthouse Performance pontszám (mobil + asztali átlag): Az audit lefuttatja a Google Lighthouse-t mobil és asztali üzemmódban is. A mobil tesztet szigorúbban súlyozza, mert a Google a mobil-első indexelést (mobile-first indexing) alkalmazza - tehát az oldal mobil verziója a meghatározó a rangsorolásban.
TTFB (Time to First Byte): A szerver válaszideje - mennyi idő telik el, amíg a szerver az első bájt adatot visszaküldi a böngészőre kérés után. Az ideális TTFB 200 ms alatt van. A lassú TTFB általában szerver oldali problémára (lassú adatbázis, nincs cache, rossz tárhelyválasztás) utal.
Tömörítési ellenőrzés (Brotli vs. Gzip): Az audit vizsgálja, hogy a szerver Brotli vagy Gzip tömörítéssel szállítja-e a statikus fájlokat (HTML, CSS, JS). A Brotli általában 15-20%-kal kisebb fájlméretet eredményez, mint a Gzip, ami gyorsabb betöltést jelent.
Accessibility (Akadálymentesség) pontszám: Bár nem közvetlenül CWV metrika, a Lighthouse akadálymentességi pontszáma szorosan kapcsolódik a felhasználói élményhez. A jól hozzáférhető weboldal jobb interakciót, alacsonyabb visszapattanást és magasabb felhasználói elégedettséget eredményez.
CrUX valós felhasználói percentilisek: Ha az adott domain elegendő forgalommal rendelkezik (a CrUX adatbázisban megjelenik), az audit lekérdi a valós LCP, INP és CLS értékeket a 75. percentilisen. Ez a legmegbízhatóbb jelzése annak, mit tapasztalnak a látogatók.

Gyakorlati példák

A számok önmagukban gyakran elvontak. Lássunk konkrét példákat arra, mit jelent a gyakorlatban egy jó és egy rossz Core Web Vitals érték:

LCP példa: E-kereskedelmi webshop

Rossz példa - LCP: 4,5 másodperc

Egy magyar webshop hero képe egy 2,8 MB méretű PNG fájl volt, optimalizálás nélkül. A szerver nem használt CDN-t, és a kép nem rendelkezett preload hinttel. A mobil látogatók 60%-a elhagyta az oldalt, mielőtt az egyáltalán betöltődött volna.

Jó példa - LCP: 1,2 másodperc

Ugyanez a webshop a kép WebP formátumra konvertálása, <link rel="preload"> alkalmazása, és egy CDN (Cloudflare) beiktatása után 1,2 másodperces LCP-t ért el. A visszapattanási arány 35%-kal csökkent, a konverziók 18%-kal nőttek.

CLS példa: Hírblog

Rossz példa - CLS: 0,35

Egy népszerű magyar hírblog dinamikusan töltötte be a hirdetéseket a cikk szövege között, anélkül, hogy előre lefoglalta volna a hirdetések helyét. Minden egyes hirdetés betöltésekor az egész szöveg leugrott, ami rendkívül frusztráló olvasási élményt eredményezett.

Jó példa - CLS: 0,02

A blogon fix mérettel (min-height) előre lefoglaltak helyet minden hirdetési slotnak, a képekhez hozzáadtak explicit width és height attribútumokat, és a webfontok font-display: swap beállítást kaptak. A CLS érték 0,35-ről 0,02-re csökkent.

INP példa: Üzleti szolgáltató oldal

Rossz példa - INP: 800 ms

Egy szolgáltató céges oldal nehéz JavaScript keretrendszert (nagyméretű React bundle-t) töltött be, egész oldalra kiterjedő eseménykezelőkkel. Minden gombkattintás és form-interakció 800 ms-os késleltetésű volt, mert a fő szál (main thread) el volt foglalva a szkriptek feldolgozásával.

Jó példa - INP: 120 ms

A JS bundle-t code-splitting-gel darabolták, a nem kritikus szkripteket defer attribútummal lettek betöltve, és a nehéz számításokat Web Worker-be mozgatták. Az eseménykezelők optimalizálása (debouncing, requestAnimationFrame használata) után az INP 120 ms-ra javult.

Legjobb gyakorlatok

Az alábbi javaslatok alkalmazásával jelentősen javíthatod a Core Web Vitals eredményedet. Ezeket a technikákat a világszinten legjobban teljesítő weboldalak általánosan használják:

Lazy loading a hajtásvonal alatti képeknek: Az loading="lazy" attribútum használata azoknál a képeknél, amelyek nem láthatóak az oldal betöltésekor. Ezzel csökkented az initial load súlyt, és az LCP javul, mert a böngésző a kritikus képekre koncentrál.
Preconnect a kritikus originekhez: Használj <link rel="preconnect"> taget azoknál a külső domaineknél, ahonnan fontos erőforrásokat (fontok, API-k, CDN) töltesz be. Ez megspórolt másodperceket jelent a DNS + TCP + TLS handshake idejéből.
font-display: swap a webfontoknál: A font-display: swap CSS tulajdonság biztosítja, hogy a szöveg azonnal megjelenjen a rendszerfonttal, és a webfont betöltődése után cserélje azt le. Ez megelőzi a FOIT-ot (Flash of Invisible Text) és javítja az LCP-t.
Kritikus CSS inline beszúrása: Az above-the-fold (hajtásvonal feletti) megjelenítéshez szükséges CSS-t közvetlenül a <style> tagbe ágyazva az HTML-be elkerülöd a külön CSS fájl betöltésére való várakozást, ami render-blocking jellegzetesség.
Képek srcset használata reszponzív méretekhez: Az <img srcset="..."> attribútummal különböző méretű képeket kínálhatsz különböző képernyőméretekhez. Mobilon így 300px széles képet töltesz be a 1920px széles desktopkép helyett.
Brotli tömörítést a szerveren: A Brotli tömörítést (~15-20% jobb kompresszió, mint Gzip) állítsd be az Nginx vagy Apache konfigurációban. A legtöbb modern böngésző támogatja, és a statikus fájlok méretét drasztikusan csökkenti.
CDN használata statikus tartalomhoz: Egy CDN (Content Delivery Network, pl. Cloudflare, BunnyCDN) a statikus fájlokat a felhasználóhoz legközelebbi szerverről szolgálja ki, csökkentve a TTFB-t és az LCP-t. Különösen magyar weboldalaknál, ahol a szerver gyakran nyugat-európai adatközpontban van.
Reszponzív képformátumok (WebP/AVIF): A modern képformátumok - különösen az AVIF és a WebP - 30-50%-kal kisebb fájlméretet eredményeznek a JPEG/PNG-hez képest, látható minőségbeli különbség nélkül. Használd a <picture> elemet fallbackkel.

Gyakori hibák

A Core Web Vitals optimalizálás során az alábbi hibákat követik el a leggyakrabban a weboldal-tulajdonosok és a fejlesztők:

Render-blocking CSS/JS a <head>-ben: A böngésző nem tud semmit megjeleníteni addig, amíg a <head> szekcióban lévő összes CSS és szinkron JavaScript fájl be nem töltődött. Ez drasztikusan lassítja az LCP-t. Megoldás: a nem kritikus CSS-t és JS-t defer vagy async attribútummal töltsd be.
Optimalizálatlan hero képek (PNG a WebP helyett): Egy 3 MB-os PNG hero kép mobil hálózaton akár 5-8 másodpercig is töltődhet. WebP-re konvertálással és helyes méretezéssel ez 150-300 KB-ra csökkenthető, ami drasztikus LCP javulást hoz.
Nincs explicit szélesség/magasság a képeken (CLS okozó): Ha a <img> tageknek nincs width és height attribútumuk, a böngésző nem tudja előre lefoglalni a helyet a képnek. Amikor a kép betöltődik, az alatta lévő tartalom hirtelen lecsúszik - ez a CLS fő okozója.
Túl sok harmadik feles szkript: Analytics, chatbot, hirdetés-kezelő, marketing pixel, hotjar, stb. - minden egyes ilyen szkript növeli a fő szál terhelését, lassítja az INP-t és az LCP-t. Auditáld a harmadik feles szkriptjeidet, és töltsd be őket aszinkron módon, requestIdleCallback segítségével.
Nem tesztelnek valós mobil eszközökön: A fejlesztői laptopon a Lighthouse 100-as pontszámot ad, de a felhasználók egy régi Android telefonról 3G-n kérik le az oldalt. Mindig tesztelj throttled hálózattal és valós eszköz-emulációval.
A TTFB figyelmen kívül hagyása: Sokan csak a frontend optimalizálásra koncentrálnak, míg a szerver 1,5 másodperc alatt válaszol. A TTFB a teljes betöltési lánc alapja amíg ez lassú, a többi optimalizálás hatékonysága korlátolt. Ellenőrizd a szerver konfigurációdat, az adatbázis teljesítményt, és fontold meg a szerver oldali cache használatát.

Pontozási módszer

Az AI Web teszt audit a Core Web Vitals pillérben összesen 25 pontot oszt ki. Az alábbi táblázat mutatja, hogyan oszlik meg ez a 25 pont a különböző mérési területek között:

Lighthouse Performance (mobil)

Szintetikus mobilteljesítmény-mérték

8 pont

Lighthouse Performance (asztali)

Asztali gép szintetikus mérték

5 pont

TTFB (Time to First Byte)

Szerver válaszidő

3 pont

Tömörítés (Brotli/Gzip)

Fájl tömörítés vizsgálat

2 pont

Accessibility pontszám

Akadálymentességi értékelés

4 pont

CrUX valós felhasználói adat

Valós látogatói teljesítmény elérhető

1 pont

INP (Interaction to Next Paint)

Valós interaktivitás a CrUX adatok alapján

2 pont

Összesen

25 pont

A mobil teljesítmény nagyobb súlyt kap (8 pont vs. 5 pont asztali), mert a Google mobile-first indexelést alkalmaz. Ez azt jelenti, hogy elsődlegesen a weboldal mobil verziója alapján rangsorol. A CrUX adatokból összesen 3 pontot szerezhetsz: 1 pont a CrUX elérhetőségéért, és további 2 pont a jó INP értékért (200ms alatt). Ha az INP 200-500ms között van, 1 pontot kapsz; 500ms felett 0-t.

INP mérés: miért kell hozzá elegendő látogató?

Az INP (Interaction to Next Paint) egy úgynevezett field metrika — ez azt jelenti, hogy kizárólag valós felhasználói adatokból származik, nem szintetikus (labor) tesztből. A Google a Chrome User Experience Report (CrUX) adatbázisában gyűjti az INP adatokat a Chrome böngészőt használó látogatóktól. Ha a weboldaladnak nincs elegendő forgalma ahhoz, hogy a CrUX adatbázisba bekerüljön, az INP értéked egyszerűen nem áll rendelkezésre — és az audit sem tudja értékelni.

Mikor jelenik meg CrUX adat?

A Google nem közöl pontos forgalmi küszöböt a CrUX bekerüléshez. A tapasztalatok alapján havi néhány ezer Chrome-alapú látogatás szükséges ahhoz, hogy egy domain (origin szinten) megjelenjen az adatbázisban. Kisebb, lokális weboldalak — például egy magyar kisvállalkozás bemutatkozó oldala — gyakran nem érik el ezt a küszöböt, és ezért nincs CrUX adatuk.

Mi történik, ha nincs CrUX adat?

Ha a weboldaladnak nincs CrUX adata, az audit nem büntet érte — egyszerűen nem osztja ki az INP-hez rendelt pontokat. A CWV pillér maximálisan elérhető 25 pontjából ebben az esetben legfeljebb 22 pont érhető el (a CrUX elérhetőségi bónusz 1 pont és az INP 2 pont nélkül). Ez igazságos megközelítés: a rendszer nem jutalmaz és nem büntet olyasmit, amit nem tud mérni.

Hogyan méri az audit az INP-t?

Az audit három forrásból próbálja lekérni az INP értéket, prioritási sorrendben:

PSI mobil field data — a PageSpeed Insights API-ból származó valós felhasználói adatok (mobil), a INTERACTION_TO_NEXT_PAINT metrikából. Ez a legfontosabb forrás, mert a Google mobile-first indexelést alkalmaz.
CrUX origin adat — a Chrome UX Report API-ból származó origin-szintű valós adat, az interaction_to_next_paint 75. percentilis értéke.
PSI asztali field data — utolsó fallback az asztali felhasználói adatokból.

INP pontozás

INP ≤ 200ms

Gyors reakcióidő — kiváló felhasználói élmény

+2 pont

INP 200–500ms

Érezhető késés — javításra szorul

+1 pont

INP > 500ms

Lassú interaktivitás — rossz felhasználói élmény

+0 pont

Nincs CrUX adat

Nem mérhető — nem értékelhető

+0 pont

Tipp: Hogyan szerezz CrUX adatot?

Ha a weboldalad még nem jelenik meg a CrUX adatbázisban, a legfontosabb teendő a forgalom növelése. Oszd meg a tartalmaidat közösségi médiában, építs organikus keresőforgalmat, és biztosítsd, hogy a látogatóid Chrome böngészőt használjanak (ami Magyarországon a piac ~65%-a). A CrUX adatok jellemzően a 28 napos gördülő ablakra épülnek — tehát az új forgalom hatása nem azonnal, hanem néhány hét múlva jelenik meg.

Labor alternatíva: Total Blocking Time (TBT)

Amíg az INP valós felhasználói adat, addig a TBT (Total Blocking Time) a Lighthouse szintetikus tesztből származik, és az INP egyik legjobb labor-korrelátumaként ismert. A Lighthouse Performance pontszámban a TBT jelentős súlyt kap — tehát ha nincs CrUX adatod, a Lighthouse Performance pontszámon keresztül közvetve mégis mérhető az interaktivitás. Az audit ezt a Performance pontszámon (15 pontos komponens) keresztül már figyelembe veszi.

Hogyan javítsd? - Lépésről lépésre

Következzen egy gyakorlatias, lépésről lépésre követhető útmutató, amellyel szisztematikusan javíthatod a Core Web Vitals pontszámodat:

Futtasd a PageSpeed Insights auditot. Látogass el a pagespeed.web.dev oldalra, add meg a weboldalad URL-jét, és futtass elemzést. Az eredmények közvetlenül megmutatják az LCP, INP és CLS értékeidet, és konkrét javaslatokat adnak. Különösen figyelj a "Diagnostics" és "Opportunities" szekciókra.
Optimalizáld a képeket. Konvertáld az összes képet WebP vagy AVIF formátumra (pl. a Squoosh eszközzel). Állíts be helyes méretezést: ne tölts be 3000px széles képet egy 600px széles mobilképernyőre. Használj srcset és sizes attribútumokat.
Valósítsd meg a lazy loading-ot. Adj loading="lazy" attribútumot minden olyan képhez és iframe-hez, amely a hajtásvonal alatt (a képernyőn nem látható területen) található. A hero képet viszont ne lazy-loadold - azt inkább preload-old.
Minimalizáld a render-blocking erőforrásokat. A kritikus CSS-t helyezd inline a <head>-be. A többi CSS-t és az összes JavaScript fájlt defer vagy async attribútummal töltsd be. Szüntesd meg a fontosság nélküli harmadik feles szkripteket.
Állítsd be a Brotli tömörítést a szerveren. Nginx esetén add hozzá a brotli on; direktívát a konfigurációhoz. Apache esetén engedélyezd a mod_brotli modult. Ellenőrizd a tömörítést a böngésző Fejlesztői eszközök Hálózat fülén, a Content-Encoding fejléc értékének br-nek kell lennie.
Használj CDN-t a statikus tartalmakhoz. Egy CDN (pl. Cloudflare, BunnyCDN, AWS CloudFront) a statikus fájlokat a felhasználóhoz legközelebbi edge szerverre cache-elve szolgálja ki. Ez különösen a TTFB-t javítja, de az LCP-re is pozitív hatással van.
Monitorozd a CrUX dashboarddal. Látogass el a CrUX Dashboard oldalra, és állítsd be a weboldalad monitorozását. A dashboard havonta frissül, és megalapozza, hogyan értékeli a Google a weboldalad teljesítményét az idő során. Figyelj a trendekre: egy javuló CWV trend pozitív jelzés a keresőmotor felé.

Hasznos külső források

Az alábbi hivatalos források részletes technikai útmutatást nyújtanak a Core Web Vitals optimalizálásához:

web.dev/vitals - A Core Web Vitals hivatalos áttekintése a Google-tól
PageSpeed Insights - Ingyenes oldalsebesség-elemző eszköz
CrUX Dashboard - Valós felhasználói adatok monitorozása
web.dev/lcp - Részletes útmutató a Largest Contentful Paint-hoz
web.dev/inp - Részletes útmutató az Interaction to Next Paint-hoz
web.dev/cls - Részletes útmutató a Cumulative Layout Shift-hez

Core Web Vitals: A weboldal teljesítmény alapjai