Core Web Vitals érthetően: mit jelent az LCP, INP és CLS?

Rákattintasz egy weboldalra. A képernyőn még semmi, aztán végre felbukkan a fő kép. Megnyomod az „Időpontot foglalok” gombot, de nem reagál. Amikor újra próbálod, az egész oldal egyet ugrik, és véletlenül a másik gombot találod el. Ismerős? Ez három különböző probléma - és a Google három mutatóval segít megérteni őket.

Az LCP, INP és CLS együtt a Core Web Vitals (alapvető webes vitális mutatók) hármasa. A neveik technikainak hangzanak, de amit mérnek, azt a látogató a saját bőrén érzi. Nem kell fejlesztőnek lenned ahhoz, hogy megértsd, mikor kell velük foglalkozni.

Röviden: az LCP azt mutatja, mikor válik láthatóvá a fő tartalom; az INP azt, mennyire gyorsan reagál az oldal; a CLS pedig azt, mennyire maradnak a helyükön az elemek.

Mi az a Core Web Vitals, és miért számít neked?

Képzelj el egy autószervizt. Az ügyfél nem arra kíváncsi, hogy a szerelő hányféle villáskulcsot tart a fiókban. Arra kíváncsi, hogy gyorsan bejut-e, felveszik-e a munkát, és nem esik-e rá a polcról egy féktárcsa. A weboldal látogatója is hasonlóan gondolkodik: látni akarja az információt, használni akarja az oldalt, és nem szeretne mellékattintani.

A Google a Core Web Vitals segítségével ezt a három élményt értékeli. Nem a weboldalad szépségét vagy szakmai tartalmának minőségét pontozza, és nem helyettesíti a teljes sebességvizsgálatot. A jó értékek segítik a használhatóságot, de önmagukban nem garantálnak jobb Google-helyezést. A keresésben a tartalom relevanciája és sok más szempont is számít. Erről a Google Search Central hivatalos útmutatója is beszél.

A három mutató egyetlen táblázatban

A táblázat a Google/web.dev hivatalos, 2026. november 10-én ellenőrzött küszöbértékeit tartalmazza; ezek nem a Weboldal Bérlés saját mérései. A három mérőszámot általában a látogatói mérések 75. percentilisén (p75) érdemes megítélni. Forrás: web.dev – Core Web Vitals küszöbértékek.

LCP: mikor látja végre a látogató, amiért érkezett?

Az LCP az angol Largest Contentful Paint rövidítése. Azt jelzi, hogy a betöltés során mikor jelenik meg a nézőtéren a legnagyobb releváns szöveg- vagy képelem. Sok vállalkozói weboldalon ez a főoldal nagy nyitóképe vagy címe.

Példa: egy építész portfóliója. A tervek látványosak, a főoldalon egy gyönyörű épületfotó fogad. Csakhogy a kép eredetileg akkora, hogy akár egy plakátnyomdának is megfelelne. Mobilon a látogató addig vár, amíg a látvány megérkezik. Az LCP ilyenkor romolhat – még akkor is, ha a kép tényleg szép.

A hivatalos jó LCP-határ 2,5 másodperc a p75 értéknél. Ez nem azt jelenti, hogy minden egyes telefonon pontosan ennyi idő alatt kell megjelennie mindennek. Azt jelenti, hogy az összegzett látogatói élmény egy jól meghatározott határ szerint értékelhető.

Mit tehetsz az LCP javításáért?

• Ne tölts fel szükségtelenül hatalmas főképet; a megjelenítési mérethez illő változatot használj.
• A legfontosabb nyitóképet ne kezeld úgy, mint a képernyő alján lévő galériaképeket: más a betöltési prioritása.
• Vizsgáld meg, nem a lassú szerverválasz vagy egy fölösleges erőforrás késlelteti-e a megjelenést.
• Mobilon is ellenőrizd az oldalt, ne csak az irodai számítógépen.

A Weboldal Bérlés technikai háttércikkében bemutattuk, hogyan kezeli rendszerünk a reszponzív képméreteket, a hero kép prioritását és a kritikus erőforrásokat. Ezek fontos technikai alapok, de a tényleges eredményt mindig mérni kell.

INP: miért kell kétszer megnyomni a gombot?

Az INP, vagyis Interaction to Next Paint a felhasználói interakciókra adott vizuális válasz gyorsaságát jellemzi. Nem egyszerűen az első kattintást figyeli: a felhasználó egy oldalhasználata során tapasztalt interakciók alapján ad képet a válaszkészségről. A jó p75 érték legfeljebb 200 ezredmásodperc.

Példa: egy személyi edző időpontfoglalója. A látogató kiválasztja a szabad időpontot, megnyomja a gombot, de az oldal látszólag meg se moccan. Egy másodperc múlva újra kattint. A végén két foglalás is bekerülhetne, ha a rendszer nem védi ezt megfelelően. Az INP nem azt méri, sikeresen bekerült-e az adat a háttérrendszerbe, hanem hogy mennyire hamar látható a böngésző válasza az interakcióra.

Gyakori ok a túl sok, egyszerre futó JavaScript vagy egy olyan hosszú feladat, amely közben a böngésző nem tud időben új képet rajzolni. Egy jól működő szerveroldali foglalás mellett is lehet gyenge az élmény, ha a gomb visszajelzése késik.

Mit érdemes ellenőrizni?

• Telefonon nyisd meg a menüt, kattints a kapcsolat gombra, próbáld ki az űrlapot.
• Figyeld, hogy van-e azonnali, egyértelmű vizuális visszajelzés.
• Ha időnként akad a kattintás, jegyezd fel a pontos oldalt és műveletet a fejlesztőnek.
• Ne feltételezd, hogy egyetlen Lighthouse-futás teljesen megméri az INP-t: a valós interakciókhoz látogatói adatok szükségesek.

CLS: amikor a „Kapcsolat” gomb az utolsó pillanatban arrébb ugrik

A CLS, a Cumulative Layout Shift az oldal váratlan vizuális elmozdulásait méri. Itt nem másodpercet látunk, hanem egy egység nélküli elmozdulási pontszámot. Jó értéknek a 0,1 vagy az alatti p75 számít.

Példa: egy autószerelő ajánlatkérő oldala. Már majdnem rányomnál a „Kérek árajánlatot” gombra, amikor betöltődik egy kép, odébb tolja az egész blokkot, és a kattintás egy másik elemre megy. A weboldal nem romlott el látványosan; csak éppen a rossz pillanatban mozdult el.

Jellemző ok, ha a képeknek nincs előre fenntartott helyük, egy hozzájárulási sáv hirtelen átrendezi az oldalt, vagy a betűtípus késői cseréje miatt ugrik a szöveg. Nem minden animáció számít rossz CLS-nek: a mutató a váratlan elmozdulásokra koncentrál, külön szabályokkal a felhasználó által kiváltott mozgásokra.

Mit lehet vele kezdeni?

• A képeknek, videóknak és beágyazott elemeknek legyen előre meghatározott helye.
• Kerüld az olyan felső sávot, amely utólag lelöki a tartalmat.
• Ellenőrizd, mi történik a betűtípusok, galériák és felugró elemek megjelenésekor.
• Próbáld végig az oldalt lassabb mobilkapcsolat mellett is: ilyenkor könnyebb észrevenni az elmozdulásokat.

Mit jelent a p75? Nem átlag, és nem egyetlen mérés

A 75. percentilis azt jelenti, hogy a megfigyelések mintegy 75%-a az adott értéken vagy az alatt helyezkedik el. Ez nem ugyanaz, mint az egyszerű számtani átlag. Ha csak a leggyorsabb irodai gépet nézed, sok valódi látogató élménye rejtve marad.

Fontos az is, honnan származik a szám. A PageSpeed Insights egyik része a Lighthouse laborvizsgálata, amely szabályozott körülményeket szimulál. Másik része a Chrome UX Report (CrUX) elérhető valós felhasználói adataiból dolgozik. A saját RUM-mérés ezzel szemben a saját weboldaladon, a hozzájárulást adó tényleges látogatókról gyűjthet adatokat. Ezek a populációk és mérési feltételek eltérhetnek egymástól.

A 288 PageSpeed-futásos saját kutatásunk és a központi weboldal-sebesség útmutatónk azt is szemlélteti, hogy egyetlen labormérésből miért kockázatos messzemenő következtetést levonni. A 288 futás nem 288 valódi látogatót jelent; a HUB-ban szereplő későbbi 576 futásos sorozat ugyancsak laboradat. Ezekből nem állítunk fel látogatói átlagot, és nem tulajdonítunk saját mérési számot egy másik ügyfélnek.

Hol tudod ellenőrizni az LCP, INP és CLS értékeidet?

1. PageSpeed Insights: add meg az oldal pontos URL-jét a pagespeed.web.dev felületen. Külön nézd a mobil- és asztali nézetet, illetve a valós adatokat és a laboreredményt.
2. Google Search Console: a Core Web Vitals jelentésben keresd a problémás URL-csoportokat. Ez nem minden oldal minden kattintásának naplója, hanem összesített jelentés.
3. Saját RUM, ha van: nézd meg, ténylegesen hány mérés gyűlt össze, melyik oldalról és milyen eszközökről. Alacsony mintaszám mellett óvatosan következtess.
4. Valódi használati próba: nyisd meg a legfontosabb szolgáltatási, kapcsolat- és foglalási oldalaidat egy hétköznapi telefonon. Néha egy félreugró gomb többet elárul, mint egy szép összpontszám.

A Weboldal Bérlésnél a Weboldal Vitalitás és a saját RUM-megfigyelés abban segít, hogy ne csak egyetlen teszt eredményét lássuk: a rendszeren belül a megvalósult mérések összesített mutatói és az időbeli változások is értelmezhetők. A RUM statisztikai hozzájáruláshoz kötött, ezért az adatok mennyiségét és összetételét mindig figyelembe vesszük. A központi üzemeltetés, a reszponzív képkezelés és a teljesítményre figyelő frontend sok technikai feladatot levesz a vállalkozó válláról, de egyedi tartalom vagy külső beágyazás továbbra is okozhat lassulást.

Összefoglalva: melyik számmal érdemes kezdeni?

Ha a fő tartalom késik, LCP. Ha a gomb nyomására késve történik valami, INP. Ha a képernyő elemei váratlanul elmozdulnak, CLS. Az első lépés nem az, hogy mindhárom számot pánikszerűen „zöldre festjük”, hanem hogy megkeressük a látogatónak valóban gondot okozó oldalt és helyzetet.

A teljes mérési képhez olvasd el a Weboldal betöltési sebesség: mit érdemes nézni a pontszámon túl? című HUB-útmutatót is. Ott részletesebben bemutatjuk, hogyan kapcsolódik össze a PageSpeed, a saját kutatás, a RUM és a Search Console. A három alapmutató ismerete után már könnyebb eldönteni, milyen hibát érdemes először javítani – és melyik szám miatt nem szükséges azonnal aggódni.