Core Web Vitals 2026-ban: mi mozgatja tényleg a rangsorolást

A Core Web Vitals 2024 óta hivatalos rangsorolási tényező, 2026-ra pedig alapkövetelmény: a legtöbb technikai SEO-audit ezzel kezdi a listát. A gyakorlatban viszont ritkán egyértelmű, hogy a három mutató közül melyiket érdemes elsőként javítani, és melyik riasztás számít ténylegesen, melyik csak zaj a PageSpeed Insights jelentésében. Ez a cikk sorra veszi az LCP, az INP és a CLS küszöbeit, megmutatja, melyik javítása hozza a legnagyobb rangsorolási és felhasználói nyereséget, és ad egy gyakorlati sorrendet ahhoz, hogy mivel kezdj.

Mi a három mutató (LCP, INP, CLS) és a küszöbök?

A Core Web Vitals három mutatóból áll, és mindegyik a felhasználói élmény más szeletét méri.

• LCP (Largest Contentful Paint): az az idő, amíg az oldal legnagyobb, vizuálisan domináns eleme — jellemzően egy hero-kép vagy a fő címsor — megjelenik a képernyőn. 2,5 másodperc alatt jó, 2,5–4 másodperc között javítandó, 4 másodperc felett rossz.
• CLS (Cumulative Layout Shift): azt méri, mennyit „ugrál" az oldal betöltés közben — például amikor egy hirdetés becsúszik, és lejjebb tolja a szöveget, amire épp kattintanál. 0,1 alatt jó, 0,25 felett rossz.
• INP (Interaction to Next Paint): 2024-ben váltotta a korábbi FID-et, és azt méri, mennyi idő telik el egy kattintás vagy érintés, valamint a látható válasz között. 200 ezredmásodperc alatt jó, 500 felett rossz.

A Google csak akkor sorolja „jó" kategóriába az oldalt, ha mindhárom mutató a látogatók legalább 75%-ánál a jó tartományban van — nem az átlagot nézi, hanem a 75. percentilist. Így egy-két kirívóan lassú munkamenet nem ront a besoroláson, de egy rendszeresen ingadozó mobilteljesítmény igen.

Melyik javítása hozza a legtöbbet?

Az LCP javítása hozza szinte mindig a leggyorsabb és legnagyobb nyereséget, mert ez az első vizuális benyomás — és a látogatók ez alapján döntik el másodperceken belül, hogy maradnak-e. Jellemzően kép- és szerverválaszidő kérdése, ezért gyakran a leggyorsabban is javítható: egy nem optimalizált hero-kép cseréje önmagában másodperceket vehet le a betöltésből. Arról, hogy a lassú betöltés pontosan mennyibe kerül konverzióban, külön cikkben írtunk részletesen. Az INP a második prioritás, mert közvetlenül a felhasználói interakciót méri — egy lomha keresőmező vagy egy döcögő menü rontja a benyomást, még ha az oldal gyorsan be is töltött. A CLS a legtöbb jól megtervezett oldalon már eleve rendben van, ha a képeknek és beágyazott elemeknek van explicit szélessége és magassága.

Mi csak zaj (amit a toolok riasztanak, de nem számít)?

Zaj minden, amit a PageSpeed Insights „Lehetőségek" listája felsorol, de ami nem szerepel a három hivatalos mutató között. Az FCP (First Contentful Paint) és a TBT (Total Blocking Time) nem rangsorolási tényezők — hasznos diagnosztikai jelek, de a Search Console „Page experience" fülén nem jelennek meg külön pontszámként. Ugyanígy a harmadik féltől származó szkriptek (chat widget, elemzőeszköz) miatti figyelmeztetések ritkán érdemesek azonnali beavatkozásra, ha a tényleges CrUX-adatok jók. A laboreredmények kis, futásonkénti ingadozása — egy-két tized másodperc — szintén nem jelent valódi problémát: ez a mérés természetes zaja, nem trend.

Hogyan mérj valós felhasználói adatot (CrUX vs lab)?

A CrUX (Chrome User Experience Report) valódi Chrome-felhasználók anonimizált méréseiből épül fel, és ez táplálja a Google Search Console „Page experience" fülét — ez az adat számít a rangsoroláshoz. A PageSpeed Insights laboreredménye ezzel szemben egyetlen szimulált futás, fix hálózati és eszközfeltételek mellett: hasznos egy konkrét probléma reprodukálásához és javításához, de nem tükrözi, mit tapasztalnak a valódi látogatóid különböző hálózaton és eszközön. A gyakorlatban a kettőt együtt érdemes használni: a CrUX-adatból (Search Console vagy a public CrUX dashboard) látod, hol állsz ténylegesen a látogatóid szemével, a laborméréssel pedig lebontod, melyik erőforrás okozza a problémát. Ha az oldalad túl friss vagy túl kis forgalmú ahhoz, hogy a Search Console CrUX-adatot mutasson, a nyilvános CrUX-dashboard és a Lighthouse rendszeres, azonos körülmények közötti futtatása jelenti a legjobb közelítést, amíg össze nem gyűlik elég valós adat.

Mit tegyél először — prioritási sorrend

Egy gyakorlatban bevált sorrend: először nézd meg a CrUX-adatot eszköz szerint bontva — mobilon szinte mindig rosszabb a kép, és ott térül meg legjobban a munka. Utána jöjjön az LCP: optimalizáld a hero-képet, told előre a kritikus erőforrások betöltését, és ellenőrizd a szerver válaszidejét. Ezután az INP: darabold fel a hosszú JavaScript-feladatokat, és halaszd későbbre azt, ami nem a kezdeti interakcióhoz kell. Végül a CLS: adj explicit méretet minden képnek és beágyazott widgetnek, és foglalj helyet előre a késve betöltődő elemeknek, például egy bannernek vagy a cookie-sávnak. Egy fontos részlet: a CrUX egy 28 napos gördülő átlag, tehát egy javítás hatása csak hetekkel később látszik meg a hivatalos adatban — ne ess pánikba, ha a Search Console nem reagál azonnal.

Érdemes ezt a munkát nem egyszeri projektként kezelni, hanem visszatérő ellenőrzésként: minden nagyobb dizájn- vagy tartalomfrissítés — új hero-kép, új harmadik féltől származó szkript, szezonális banner — visszaeshet a mutatókon, ha nem figyeled. Ha nem vagy biztos benne, hol a legnagyobb szűk keresztmetszet a saját oldaladon, a weboldal-auditunk pontosan ezt méri fel, valós mérési adatok alapján, nem találgatással — és 24 órán belül válaszolunk, ha szeretnéd, hogy átnézzük a tiédet.