Core Web Vitals a gyakorlatban: INP, LCP, CLS

A Core Web Vitals három mérőszám: az LCP a betöltést (jó, ha legfeljebb 2,5 másodperc), az INP a reakcióidőt (jó, ha legfeljebb 200 ms), a CLS a vizuális stabilitást méri (jó, ha legfeljebb 0,1), mindhármat a valós látogatók 75. percentilisén. A Google rangsorolásában számítanak, de nem írják felül a relevanciát. Egy kkv-oldalon a legtöbbet szinte mindig ugyanaz a három dolog hozza: a szerver válaszideje, a nyitókép betöltése és a harmadik féltől jövő szkriptek.

Sok ügyfél úgy érkezik hozzánk, hogy „a PageSpeed 54-et mutat, csináljuk meg 100-ra”. Szerintünk ez rossz cél. A Lighthouse-pontszám laborpontszám, a Google viszont a valós felhasználói adatokat nézi. Az alábbiakban azt írjuk le, mit érdemes ténylegesen mérni, és milyen sorrendben javítunk.

Mit mér a három mutató, és mi számít jónak?

A küszöböket a Google a web.dev Core Web Vitals-oldalán rögzíti. Egy oldal akkor „megfelelt”, ha a látogatások legalább 75%-ánál mindhárom mutató a jó sávban van.

Mutató	Mit mér	Jó	Javítandó	Gyenge
LCP (Largest Contentful Paint)	mikor jelenik meg a látható terület legnagyobb eleme	≤ 2,5 s	2,5–4 s	> 4 s
INP (Interaction to Next Paint)	mennyi idő telik el egy kattintás, koppintás vagy billentyűleütés és a következő képkocka között, a látogatás során mért leglassabb interakciók alapján	≤ 200 ms	200–500 ms	> 500 ms
CLS (Cumulative Layout Shift)	mennyit ugrál a tartalom váratlanul	≤ 0,1	0,1–0,25	> 0,25

Az INP 2024. március 12-én váltotta le a FID-et. Ez azért fontos, mert a FID csak az első interakció késleltetését mérte, az INP viszont a teljes látogatást. Sok oldal, amely a FID-del simán átment, az INP-vel elbukott, főleg mobilon.

Melyik számot nézd: a Lighthouse-pontszámot vagy a terepi adatot?

A terepi adatot. A Chrome UX Report (CrUX) valódi Chrome-felhasználók méréseit gyűjti egy gördülő 28 napos ablakban; ezt látod a PageSpeed Insights tetején és a Search Console Core Web Vitals jelentésében. A Lighthouse (és a PageSpeed Insights alsó, 0–100-as része) egyetlen szimulált betöltés egy rögzített eszközprofillal. Hibakeresésre kiváló, a valóságot viszont nem írja le. A kettő gyakran eltér, és ilyenkor a terepi adat a mérvadó.

Két gyakorlati következmény:

• INP-t a Lighthouse betöltési tesztje nem mér, mert nincs benne felhasználói interakció. A laborban a Total Blocking Time (TBT) a legközelebbi helyettesítő, de csak jelzi a bajt, nem méri ugyanazt.
• Kis forgalmú oldalnál gyakran nincs CrUX-adat. Ilyenkor saját mérés kell: a Google nyílt forrású web-vitals könyvtárával néhány sorból elküldheted a valós értékeket az analitikába, az attribution változat pedig azt is megmondja, melyik elem vagy interakció okozta a rossz értéket.

Mennyit számít a rangsorolásban?

A Google Search Central dokumentációja szerint a Core Web Vitals mutatókat használják a rangsoroló rendszerek, és jó értékeket ajánlanak. Az oldalélményről szóló útmutató ugyanakkor egyértelmű: a Google a legrelevánsabb tartalmat próbálja megmutatni akkor is, ha az oldalélmény gyengébb, és a jó mutatók önmagukban nem garantálnak előkelő helyezést.

A mi olvasatunk: a Core Web Vitals inkább döntetlenfeloldó, mint motor. Egy gyenge tartalmú, de villámgyors oldal nem fog előrébb kerülni. A lassúság viszont a konverzión közvetlenül látszik: a látogató, aki három másodpercig fehér képernyőt néz, vagy akinek a „Kosárba” gomb fél másodpercig nem reagál, nem vár. Ezért mérünk és javítunk, nem a pontszám kedvéért. A technikai SEO többi elemét a technikai SEO-ról szóló cikkünkben vettük sorra.

Hogyan javítsd az LCP-t konkrét számokon?

Bontsd négy részre az időt

A web.dev LCP-optimalizálási útmutatója négy részre bontja az LCP-t:

1. Time to First Byte (TTFB): mikor érkezik meg a HTML első bájtja.
2. Erőforrás-betöltési késés: mennyit vár a böngésző, mire elkezdi letölteni az LCP-képet.
3. Erőforrás-betöltési idő: maga a letöltés.
4. Elem renderelési késés: a letöltés vége és a megjelenés közti idő.

Ez a bontás teszi számszerűvé a munkát. A 2,5 másodperces keret közös: ha a TTFB a 75. percentilisen 1,2 másodperc, a másik háromra összesen 1,3 marad. Ilyenkor hiába tömöríted a képet, előbb a szervert kell rendbe tenni. Ha a TTFB rendben van, de a kép csak a betöltés közepén indul, akkor a késés a gond, nem a fájlméret. A Chrome DevTools Performance panelje mind a négy részt megmutatja az LCP-elemre.

Amit egy kkv-oldalon szinte mindig találunk

• Lassú TTFB: gyorsítótár nélküli WordPress, túlterhelt osztott tárhely, sok bővítmény. Oldalszintű gyorsítótár és CDN általában többet hoz, mint bármilyen képoptimalizálás.
• Lusta betöltésű nyitókép: a loading="lazy" a hajtás alatti képekre való, az LCP-képre soha.
• Későn felfedezett kép: ha a nyitókép CSS-háttér vagy JavaScript (például egy slider) teszi be, a böngésző csak későn találja meg. Legyen sima <img> a HTML-ben, fetchpriority="high" attribútummal.
• Túlméretes kép: egy 2400 pixel széles JPEG egy telefon 400 pixeles képernyőjére. srcset, sizes és modern formátum (WebP, AVIF) kell.
• Renderblokkoló CSS és betűtípusok: egy egész témacsomag CSS-e töltődik be az első festés előtt.

Hogyan javítsd az INP-t?

Az INP egy interakciót három szakaszra bont: bemeneti késés (a böngésző épp mással van elfoglalva), feldolgozási idő (lefutnak az eseménykezelők) és megjelenítési késés (a következő képkocka kirajzolása). A web.dev INP-útmutatója szerint a fő ellenség a hosszú, 50 ms-nál tovább futó feladat, amely közben a fő szál nem tud reagálni.

Kkv-oldalakon a tipikus bűnösök:

• Harmadik féltől jövő szkriptek: csevegőwidget, hőtérkép, több analitikai és hirdetési címke egy címkekezelőben. Mindegyik a fő szálon fut. Az első lépés nálunk mindig egy leltár: mi van fent, és kinek kell még.
• Nehéz eseménykezelők: webshopban a szűrő, amely minden kattintásra újrarajzolja az egész terméklistát, vagy a „Kosárba” gomb, amely előbb öt analitikai hívást indít, és csak utána frissíti a felületet.
• Túl nagy DOM: megamenük, rejtett mobilnézetek, végtelen terméklisták. Minél több elem van, annál drágább minden újrarajzolás.

A javítás iránya: előbb adj vizuális visszajelzést, a többit pedig tedd későbbre (a hosszú feladatot darabold, és engedd vissza a vezérlést a böngészőnek), a nem kritikus szkripteket töltsd később vagy interakcióra. Egyedi fejlesztésnél ezt már tervezéskor beépítjük; sablonos rendszernél gyakran egy-két bővítmény eltávolítása többet ér, mint bármilyen finomhangolás.

Hogyan javítsd a CLS-t?

A CLS-t a web.dev útmutatója szerint leggyakrabban méret nélküli képek, később beszúrt tartalom és webes betűtípusok okozzák. A gyakorlatban:

• Minden képnek és beágyazásnak legyen width és height attribútuma (vagy CSS aspect-ratio), hogy a böngésző előre lefoglalja a helyet.
• A sütibanner és az akciós sáv ne tolja le a tartalmat: legyen fölötte lebegő réteg, vagy foglalj neki helyet előre.
• Betűtípusok: a tartalék betűtípus méreteit igazítsd a webes betűhöz (size-adjust és társai), így a betűcsere nem rendezi át a sorokat.
• Animációt transform-mal csinálj, ne a top vagy a height állításával.

Milyen sorrendben állj neki?

1. Search Console, Core Web Vitals jelentés, mobil nézet. Melyik URL-csoport bukik, és melyik mutatón?
2. Egy reprezentatív URL a PageSpeed Insightsban. Felül a terepi adat (mi a baj), alul a labor (miért).
3. Egyszerre egy mutató, a legrosszabbal kezdve. LCP-nél a négyes bontás alapján, INP-nél a hosszú feladatok és a szkriptleltár alapján.
4. Ellenőrzés laborban, élesítés előtt, ugyanazon az eszközprofilon.
5. Türelem. A CrUX 28 napos ablaka miatt a javítás nagyjából egy hónap alatt látszik teljesen; addig a saját web-vitals-mérésed mutatja, jó irányba mentél-e.

Gyakori kérdések

Kell 100-as Lighthouse-pontszám?

Nem. A Google a terepi adatot nézi, és ott a három küszöb számít. Egy 80-as laborpontszámú oldal, amely a valós látogatóknál mindhárom mutatón jó, rendben van.

Miért nem mutat terepi adatot a PageSpeed Insights?

Mert az oldalnak vagy URL-nek nincs elég Chrome-os látogatása a 28 napos ablakban. Ilyenkor a Search Console hasonló URL-ek csoportjára vagy a teljes domainre adhat értéket, a pontos képhez pedig saját mérés kell a web-vitals könyvtárral.

Az asztali vagy a mobil érték számít?

Mindkettőt külön méri a Google. Kkv-oldalaknál szinte mindig a mobil a gyengébb: lassabb processzor, gyengébb hálózat. Mi mobillal kezdünk.

Megoldja egy gyorsító bővítmény?

Részben. A gyorsítótárazás és a képtömörítés sokat hoz az LCP-n. Az INP-t viszont ritkán javítja, mert az a szkriptek mennyiségén és a kód minőségén múlik, és a túl agresszív szkriptkésleltetés néha még rontja is az interakciókat.

Ha nem tudod, melyik mutatón és miért bukik az oldalad, kérj tőlünk ingyenes SEO- és AI-láthatósági auditot: a Core Web Vitals is része. Ha pedig a gond a rendszerben van, nem a beállításokban, a webshopfejlesztésnél és az egyedi szoftverfejlesztésnél a teljesítményt az első sortól tervezzük.