Core Web Vitals: teljes útmutató

A Core Web Vitals a Google által meghatározott három felhasználói élmény mutató: az LCP a fő tartalom betöltési idejét, az INP az interakciókra adott válasz gyorsaságát, a CLS a váratlan elrendezés-elmozdulásokat méri. A mutatókat valódi látogatók adataiból értékelik. Rangsorolási jelzésként szerepet játszanak, de a releváns, hasznos tartalmat nem helyettesítik.

Alapfogalmak

A Core Web Vitals a Google Web Vitals kezdeményezésének része. A kezdeményezés célja, hogy egységes, mérhető mutatókat adjon arra, milyen élményt nyújt egy oldal a látogatónak. A Web Vitals körébe sok mutató tartozik, ezek közül a Core Web Vitals az a szűk kör, amelyet a Google a legfontosabbnak tart, és amelyet minden webhelytulajdonosnak ajánl figyelni. Jelenleg három mutató alkotja: a Largest Contentful Paint, az Interaction to Next Paint és a Cumulative Layout Shift.

A három mutató a felhasználói élmény három különböző oldalát fogja meg. Az első a betöltés: mikor látja a látogató az oldal fő tartalmát. A második az interaktivitás: milyen gyorsan reagál az oldal, amikor a látogató kattint, koppint vagy gépel. A harmadik a vizuális stabilitás: ugrál-e a tartalom betöltés közben, és kattint-e emiatt a látogató rossz helyre. Egy oldal akkor nyújt jó élményt, ha mindhárom területen rendben van.

A három mutató röviden

Mutató	Mit mér	Jó érték	Gyenge érték
LCP (Largest Contentful Paint)	Mikor jelenik meg a látható terület legnagyobb tartalmi eleme	legfeljebb 2,5 másodperc	több mint 4 másodperc
INP (Interaction to Next Paint)	Mennyi idő telik el egy interakciótól a következő képkocka megjelenéséig	legfeljebb 200 ezredmásodperc	több mint 500 ezredmásodperc
CLS (Cumulative Layout Shift)	Mennyire mozdul el váratlanul a látható tartalom	legfeljebb 0,1	több mint 0,25

A két határ közötti értékek a „javítandó” kategóriába esnek. A Google az értékelésnél az oldalletöltések 75. percentilisét nézi, mobilon és asztali gépen külön. Ez azt jelenti, hogy egy oldal akkor számít jónak egy mutatóban, ha a látogatások legalább háromnegyedénél a jó tartományban van az érték.

Az INP és a korábbi FID

A Core Web Vitals összetétele nem végleges. Az interaktivitást korábban a First Input Delay, vagyis az FID mérte, amely csak az első interakció késleltetését vette figyelembe. 2024 márciusában az INP váltotta fel. Az INP az oldalon töltött teljes idő interakcióit figyeli, ezért jobban tükrözi, milyen érzés használni az oldalt. Aki régebbi anyagokban FID-ről olvas, tudja, hogy az már nem része a Core Web Vitalsnak.

Terepi és laboradatok

A Core Web Vitals mutatóit kétféleképpen lehet mérni. A terepi adat valódi látogatók böngészőjéből származik, és azt mutatja, amit az emberek ténylegesen tapasztalnak. A laboradat egy szimulált környezetben, rögzített eszköz- és hálózati beállításokkal készül, és hibakeresésre való. A Google értékelése a terepi adatokon alapul. A laboradat hasznos a problémák okának felderítésére, de egy jó laboreredmény nem garantálja a jó terepi eredményt, és fordítva.

Hogyan működik?

A terepi adatok fő forrása a Chrome felhasználói élmény jelentés, angol rövidítéssel CrUX. A Chrome böngésző azoktól a felhasználóktól, akik ehhez hozzájárultak, összegyűjti a meglátogatott oldalak teljesítményadatait. Ezekből készül a nyilvános adatkészlet, amelyet a PageSpeed Insights és a Search Console is használ. Az adatok egy gördülő időablakot fednek le, ezért egy javítás hatása nem azonnal, hanem fokozatosan jelenik meg bennük.

Ha egy oldalnak nincs elég forgalma, a CrUX nem ad róla külön adatot. Ilyenkor a Search Console és a PageSpeed Insights a hasonló oldalak csoportjára vagy a teljes webhelyre vonatkozó adatot mutathat, vagy egyáltalán nem mutat terepi eredményt. Kis webhelyeken ezért gyakori, hogy csak laboradat áll rendelkezésre. Ilyenkor a saját terepi mérés, például a web-vitals JavaScript könyvtár használata, pótolhatja a hiányt.

Hogyan számol az LCP?

Az LCP azt az időpontot rögzíti, amikor a látható terület legnagyobb kép- vagy szövegblokkja megjelenik, a navigáció kezdetétől számítva. Jellemzően egy nagy fejléckép, egy kiemelt termékfotó vagy egy címsor blokkja az LCP elem. Az idő több szakaszból adódik össze: a szerver válaszideje, az erőforrás felfedezéséig eltelt idő, az erőforrás letöltése és a megjelenítés. A javításnál azt kell megtalálni, melyik szakasz a leghosszabb.

Hogyan számol az INP?

Az INP a látogatás során történt kattintások, koppintások és billentyűleütések késleltetését figyeli. Minden interakciónál azt méri, mennyi idő telik el a bemenettől addig, amíg a böngésző a következő képkockát kirajzolja. Ez három részből áll: a bemeneti késleltetésből, amíg a böngésző fő szála szabaddá válik; a feldolgozási időből, amíg az eseménykezelők lefutnak; és a megjelenítési késleltetésből. Az INP értéke a leglassabb interakciók közelében lévő érték, így egy-egy nagyon lassú művelet is ronthatja.

Hogyan számol a CLS?

A CLS a váratlan elrendezés-elmozdulásokat összegzi. Egy elmozdulás akkor számít, ha egy látható elem a felhasználó közreműködése nélkül változtat helyet, például mert fölötte betöltődik egy kép méret nélkül, vagy megjelenik egy hirdetés. A felhasználói interakciót közvetlenül követő elmozdulások, például egy lenyíló menü kinyitása, nem számítanak bele. Az érték az elmozdult terület nagyságát és az elmozdulás távolságát veszi figyelembe.

A Core Web Vitals és a rangsorolás

A Google a Core Web Vitalst az oldalélmény jelzései között említi, amelyeket a rangsorolási rendszerei figyelembe vesznek. Ugyanakkor maga a Google is hangsúlyozza, hogy a releváns, hasznos tartalom fontosabb, és egy jó Core Web Vitals eredmény önmagában nem garantál jó helyezést. A gyakorlati következtetés: a mutatók javítása érdemes, mert a látogatónak is jobb, de nem helyettesíti a tartalmi és a technikai alapokat.

Fő módszerek

A Core Web Vitals javítása mutatónként más eszközöket kíván. Az alábbiak a legáltalánosabb, a legtöbb webhelyen alkalmazható módszerek. Mindegyik mutatónak saját részletes útmutatója is van: az LCP, az INP és a CLS útmutatók mélyebben tárgyalják a részleteket.

Az LCP javítása

Gyors szerverválasz. A lassú szerver minden más lépést késleltet. A gyorsítótárazás és a CDN sokat segíthet.
Az LCP erőforrás korai felfedezése. Ha az LCP kép a HTML-ben szerepel, a böngésző hamar megtalálja. Ha csak JavaScript vagy CSS tölti be, késik. A preload segíthet a korai letöltésben.
Az LCP kép ne legyen lusta betöltésű. A lazy loading a hajtás alatti képeknek való, az LCP elemnél késleltetést okoz.
Optimalizált képek. Megfelelő méret és modern formátum, hogy a letöltés rövid legyen.
Renderelést blokkoló erőforrások csökkentése. A fölösleges CSS és JavaScript késlelteti a megjelenítést.

Az INP javítása

Hosszú feladatok felbontása. Ha a JavaScript sokáig foglalja a fő szálat, az interakciók várnak. A munka kisebb részekre bontása lehetővé teszi, hogy a böngésző közben reagáljon.
Kevesebb JavaScript. Minden fölösleges szkript, különösen a harmadik féltől származók, a fő szálat terheli.
Könnyű eseménykezelők. Az interakcióra először a látható visszajelzést érdemes megadni, a nehezebb munkát utána elvégezni.
Kisebb DOM. A nagyon nagy oldalszerkezet minden frissítést lassabbá tesz.

A CLS javítása

Méret a képeknek és videóknak. A width és height attribútum, vagy a CSS aspect-ratio lefoglalja a helyet, mielőtt a kép betöltődik.
Helyfoglalás a hirdetéseknek és beágyazásoknak. A később betöltődő elemeknek előre kell a helyet biztosítani.
Ne szúrj be tartalmat a meglévő fölé. Sávok, bannerek, értesítések ne tolják le a már látható tartalmat, hacsak nem a felhasználó kérte.
Betűtípusok kezelése. A webes betűtípus betöltésekor a szöveg mérete változhat. A hasonló méretű tartalék betűtípus csökkenti az elmozdulást.

Döntési szabály: hol kezdd?

Helyzet	Első lépés
Több mutató is gyenge	Kezdd azzal, amelyik a legtöbb fontos oldalt érinti a Search Console csoportjaiban
Csak mobilon gyenge	Nézd meg a mobilos sablont, a képméreteket és a JavaScript mennyiségét
A laboradat jó, a terepi gyenge	Keress olyan tényezőt, amelyet a labor nem lát: lassú eszközök, lassú hálózat, harmadik féltől származó szkriptek, interakciók
Nincs terepi adat	Mérj saját terepi adatot, addig a laboradatból dolgozz
Egy sablon minden oldala gyenge	A sablont javítsd, ne az egyes oldalakat

Kidolgozott példa: lassú LCP egy blogon

Egy blog cikkoldalain a Search Console gyenge LCP-t jelez mobilon. A PageSpeed Insights szerint az LCP elem a cikk kiemelt képe. A vizsgálat kimutatja, hogy a sablon minden képre lazy loadingot tesz, a kiemelt képre is, és a kép jóval nagyobb felbontásban töltődik le, mint amekkorában megjelenik. A javítás: a kiemelt kép kikerül a lusta betöltés alól, reszponzív méretváltozatokat kap, és a sablon a fejlécben előre jelzi a letöltését. A változás után a laboradat azonnal javul, a terepi adat a gördülő időablak miatt fokozatosan követi.

Kidolgozott példa: magas CLS egy webáruházban

Egy webáruház termékoldalain a CLS gyenge. A laborban a mérés nem mutat nagy elmozdulást, a terepi adat mégis rossz. A vizsgálat szerint egy harmadik féltől származó értékelési modul és egy sütibanner csak a betöltés után jelenik meg, és letolja a tartalmat. A javítás: az értékelési modul előre lefoglalt helyet kap, a sütibanner pedig a tartalom fölé rétegként jelenik meg, nem tolja el azt.

Gyakori hibák

A Core Web Vitals körüli hibák egy része technikai, más része a mérés félreértéséből fakad. Az alábbiak a leggyakoribbak.

A hibák listája

Csak a laboreredményre figyelni. A Google értékelése a terepi adatokon alapul. Egy magas Lighthouse pontszám nem jelenti, hogy a terepi mutatók is jók.
A pontszámot hajszolni a mutatók helyett. A Lighthouse összpontszáma nem Core Web Vitals mutató. A három mutató értéke a lényeg.
Lazy loading az LCP elemen. A leggyakoribb és legkönnyebben javítható LCP hiba.
Méret nélküli képek és hirdetések. A CLS legfőbb forrása.
Harmadik féltől származó szkriptek ellenőrzés nélkül. Chat, analitika, hirdetés, értékelés: mindegyik terheli a fő szálat, és rontja az INP-t.
Azonnali eredmény várása. A terepi adat gördülő időablakból számol, a javítás hatása késve jelenik meg.
Csak a kezdőlap mérése. A forgalom nagy része gyakran más sablonokra érkezik: cikkekre, kategóriákra, termékekre.

Tévhit: „a jó Core Web Vitals az első helyet hozza”

A Core Web Vitals egy jelzés a sok közül. Egy gyors, stabil, de a keresésre nem releváns oldal nem fog jól rangsorolni. A fordítottja is igaz: egy nagyon releváns oldal gyengébb mutatókkal is jó helyen lehet. A mutatók javítása a látogatónak mindig jó, de nem helyettesíti a tartalmat és az on-page SEO alapjait.

Tévhit: „a PageSpeed pontszám a Core Web Vitals”

A PageSpeed Insights oldal tetején két különböző dolog látható. Felül a terepi adatok, ha vannak, a három Core Web Vitals mutatóval. Alatta a Lighthouse laboreredménye és összpontszáma. A pontszám hasznos jelzés, de nem azonos a Core Web Vitals értékeléssel. Érdemes mindig a terepi részt nézni először.

Mérés

A Core Web Vitals mérésére több eszköz áll rendelkezésre, és mindegyik más kérdésre ad választ. A legjobb gyakorlat az, ha a terepi adatokkal azonosítod a problémás oldalcsoportokat, a laboreszközökkel pedig megkeresed az okot.

Az eszközök és szerepük

Eszköz	Adat típusa	Mire való
Search Console Core Web Vitals jelentés	Terepi	Hasonló URL-ek csoportjainak állapota mobilon és asztalon
PageSpeed Insights	Terepi és labor	Egy adott URL gyors ellenőrzése, a terepi adat és a Lighthouse együtt
Chrome DevTools	Labor	Részletes hibakeresés, a hosszú feladatok és az elmozdulások azonosítása
Lighthouse	Labor	Ismételhető mérés és javítási javaslatok
web-vitals JavaScript könyvtár	Saját terepi	A saját látogatók mutatóinak gyűjtése az analitikába

A mérés lépései

Nyisd meg a Search Console Core Web Vitals jelentését, és nézd meg, mely URL-csoportok gyengék vagy javítandók, mobilon és asztalon külön.
Minden csoportból válassz ki néhány jellemző URL-t, és vizsgáld meg őket a PageSpeed Insightsban.
Nézd meg, melyik mutató a gyenge, és mi az LCP elem, mely interakciók lassúak, vagy mely elemek mozdulnak el.
A Chrome DevTools teljesítményfelvételével keresd meg a konkrét okot.
Javíts a sablon szintjén, ahol lehet, majd ellenőrizd a laboradatban.
A Search Console jelentésében indítsd el a javítás ellenőrzését, és kövesd a terepi adat változását a következő hetekben.

Ellenőrzőlista

Megvan-e a három mutató terepi értéke mobilon és asztalon?
Tudod-e, melyik sablon hozza a legtöbb organikus forgalmat, és azon hogyan állnak a mutatók?
Ismert-e a fő sablonok LCP eleme?
Van-e méret minden képen, videón és beágyazáson?
Tudod-e, mely harmadik féltől származó szkriptek futnak, és mennyire terhelik a fő szálat?
Méred-e a saját terepi adatokat, ha a CrUX nem ad elég adatot?

A Core Web Vitals nem egyszeri projekt. Új funkciók, új szkriptek és új sablonok rendszeresen rontanak a mutatókon, gyakran észrevétlenül. Érdemes a Search Console jelentést havonta átnézni, és minden nagyobb fejlesztés előtt és után laborban is mérni. A szélesebb sebességi kérdésekről a page speed útmutató szól.