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

> Miért késik a weboldal fő képe, miért reagál lassan egy gomb, és miért ugrál a tartalom? Az LCP, INP és CLS közérthetően, kisvállalkozói példákkal és gyakorlati ellenőrzési tippekkel.

- **Eredeti HTML oldal:** [https://weboldal-berles.hu/blog/core-web-vitals-erthetoen-lcp-inp-cls](https://weboldal-berles.hu/blog/core-web-vitals-erthetoen-lcp-inp-cls)
- **AI tartalmi térkép:** [llms.txt](https://weboldal-berles.hu/llms.txt)

- **Megjelenés:** 2026-11-10
- **Kategória:** Weboldal teljesítmény
- **Szerző:** Szabó Balázs

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](https://developers.google.com/search/docs/appearance/page-experience) is beszél.

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

| Mutató | Mit érzékel a látogató? | Jó érték (p75) | Gyakori ok, ha rossz |
| --- | --- | --- | --- |
| **LCP** Largest Contentful Paint | Mikor jelenik meg a fő tartalom? | **Legfeljebb 2,5 mp** | Nagy fő kép, lassú szerverválasz, későn betöltődő erőforrás |
| **INP** Interaction to Next Paint | Milyen gyorsan reagál a kattintásra vagy billentyűleütésre? | **Legfeljebb 200 ms** | Túl sok vagy sokáig futó JavaScript, elfoglalt böngésző |
| **CLS** Cumulative Layout Shift | Elmozdulnak-e váratlanul a gombok, képek, szövegek? | **Legfeljebb 0,1** | Hely nélküli képek, felugró sávok, későn érkező betűkészletek |

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](https://web.dev/articles/defining-core-web-vitals-thresholds).

## **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](https://weboldal-berles.hu/blog/mi-van-a-motorhazteto-alatt-weboldal-teljesitmeny-core-web-vitals-rum) 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](https://weboldal-berles.hu/blog/leteszteltuk-miert-ne-higgy-a-google-pagespeed-insightsnak) és a [központi weboldal-sebesség útmutatónk](https://weboldal-berles.hu/blog/weboldal-betoltesi-sebesseg-mit-erdemes-nezni) 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](https://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.
1. **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.
1. **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.
1. **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?](https://weboldal-berles.hu/blog/weboldal-betoltesi-sebesseg-mit-erdemes-nezni) 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.**