Core Web Vitals 2026: mérés és javítás KKV-knak

Ha a látogató megnyitja egy magyar szolgáltató ajánlatkérő oldalát, három különböző hibával találkozhat: sokáig vár a tartalomra, a gomb késve reagál, vagy kattintás előtt elmozdul az űrlap. A Core Web Vitals ezeknek az élményeknek egy-egy mérhető részét írja le. Az értékekből javítási feladat vezethető le, de önmagukban nem mondják meg, hogy jó-e az ajánlat vagy sikeres lesz-e az értékesítés.

A Google használja ezeket a mutatókat a rangsorolási rendszereiben, azonban a jó eredmény nem garantál előkelő helyezést. A tartalom relevanciáját és a teljes oldalélményt sem helyettesíti. Ez a cikk 2026. októberi mérési útmutató, nem egy új rangsorolási szabály bejelentése. Forrás: Google Search Central.

Mit jelent a három jó határérték?

Mutató	Mit ír le?	Jó érték
LCP	A nézetben látható legnagyobb releváns kép- vagy szövegelem megjelenésének idejét	legfeljebb 2,5 másodperc
INP	A kattintások, érintések és billentyűzetes interakciók válaszkészségét	legfeljebb 200 milliszekundum
CLS	A váratlan elrendezésváltozások mértékét	legfeljebb 0,1

Ezeket a határokat a látogatások 75. percentilisénél értékelik. Leegyszerűsítve: a vizsgált látogatások legalább háromnegyedének el kell érnie az adott jó szintet. Elegendő adat mellett mindhárom mutatónak teljesülnie kell a jó összesített minősítéshez. A PageSpeed Insights kivételt alkalmaz: hiányzó INP-adat mellett a jó LCP és CLS alapján is adhat megfelelő minősítést. Ez nem bizonyítja a válaszkészséget. A mobilos és asztali eredményt külön vizsgáld. Forrás: PageSpeed Insights módszertan.

Az LCP nem mindig a nyitókép: lehet nagy szövegblokk is. Az INP nem pusztán egyetlen első kattintást vizsgál, hanem az oldal használata során megfigyelt interakciókból képez jellemző értéket. A CLS pedig a betöltés utáni használat során is romolhat. A hibakereséshez ezért a főoldal egyszeri megnyitása kevés.

A PageSpeed-pontszám és a terepi adat két külön dolog

A PageSpeed Insights felső, felhasználói élményt bemutató része a Chrome UX Report, röviden CrUX adatait használja. Az ott megjelenő értékek az előző 28 napot összesítik. Ha nincs elegendő adat az adott URL-ről, a jelentés a teljes eredetre, például a domain megfelelő protokollú változatára vonatkozó adatot mutathat, vagy nem ad terepi értékelést. Mindig olvasd el, milyen adatkör látható. Forrás: PageSpeed Insights.

Lejjebb a Lighthouse laborvizsgálata jelenik meg. A teljesítménypontszám több mérőszám súlyozott eredménye, és a körülményektől függően változhat. Egy jó laborpontszám mellett is lehet gond egy régebbi telefonon használt termékszűrővel, amelyet a betöltési teszt nem próbált ki. A pontszámban szereplő TBT nem azonos a terepi INP-vel. Forrás: Lighthouse pontszámítás.

Ha nincs CrUX-adat, az eredmény nem „megfelelt”, és nem is „megbukott”: nincs elég nyilvános mérési bizonyíték. Kis forgalmú B2B-oldalnál ilyenkor több reprezentatív laborvizsgálatra és dokumentált használati próbára lehet támaszkodni. Saját felhasználói mérés is kialakítható, megfelelő adatkezeléssel és a mintanagyság feltüntetésével.

Készíts összehasonlítható mérési alapot

Válassz oldalakat az üzleti szerepük alapján: szolgáltatás, kapcsolat, cikk, kategória, termék. Az ajánlatkérést vagy vásárlást végig is kell próbálni. Egy menü gyors megnyitása nem bizonyítja, hogy a pénztár használható marad címkitöltés közben.

A mérési naplóban szerepeljen az URL, időpont, kiadott verzió, eszköz vagy laborprofil, hozzájárulási állapot és az elvégzett művelet. Ismételd meg a labortesztet azonos feltételekkel, és őrizd meg az eredményeket; ne csak a legjobb futást válaszd ki. Ha jelentős a szórás, előbb annak okát keresd meg.

Az éles üzleti folyamat vizsgálatát egyeztesd: egy próbarendelés számlázást vagy kiszállítási folyamatot indíthat. Tesztkörnyezetben vagy erre kialakított eljárással ellenőrizd, és jelöld, hogy melyik környezetben készült a mérés. A tesztszerver eredményét ne nevezd éles teljesítménynek.

Lassú LCP: keresd meg, hol telik el az idő

Először azonosítsd a tényleges LCP-elemet a jelentésben. Ezután nézd meg a hálózati időzítést: későn érkezik a HTML, későn indul a kép letöltése, nagy az állomány, vagy a böngésző késve rajzolja ki az elemet? Ezek eltérő javításokhoz vezetnek.

A szerverválasz idejét adatbázis-lekérdezés, gyorsítótár és hálózati út is befolyásolhatja. A CDN használata nem jelent minden kérésre állandó válaszidőt. Ha a válasz gyors, de a nyitókép későn derül ki a böngésző számára, a szervercsere nem a megfelelő első lépés.

A képernyő tetején megjelenő, LCP-t adó képet ne töltsd késleltetve. A megfelelő képméret, srcset, tömörítés és indokolt esetben magasabb letöltési prioritás segíthet. Előtöltést csak az azonosított fontos erőforrásra állíts be; ha mindent sürgősnek jelölsz, a prioritás elveszíti az értelmét. Forrás: Google LCP-optimalizálási útmutató.

Átvételi feltételként azt rögzítsd, hogy mely URL-en, milyen profil mellett, melyik szakasz javult. Az új képformátum önmagában nem bizonyíték: a ténylegesen letöltött állományt és a megjelenést is ellenőrizni kell.

Lassú INP: a problémás műveletet javítsd

Jegyezd fel, mely műveletnél késik a felület: menünyitás, szűrés, kosárfrissítés vagy űrlapellenőrzés. A böngésző teljesítményfelvételén keresd a hosszú feladatokat, a nehéz eseménykezelőket és a drága újrarajzolást. Egy betöltéskor jól működő oldal hosszabb használat után is belassulhat.

A javítás lehet a munka kisebb részekre bontása, felesleges JavaScript eltávolítása vagy a megjelenített lista egyszerűsítése. A külső chatet és mérőkódokat külön is próbáld ki. Ha a hozzájárulás után lép fel a hiba, a kezdeti, elutasított sütis állapotban készült teszt nem fogja megmutatni. Forrás: Google INP-optimalizálási útmutató.

A gyors vizuális visszajelzés fontos, de ne jelezzen hamis sikert. A „Rendelés feldolgozása” állapot megjelenhet azonnal; a sikeres rendelés állítása csak a háttérrendszer visszaigazolása után helyes. A gyors felület és a tranzakció pontossága együtt követelmény.

Magas CLS: foglalj helyet a később érkező tartalomnak

A képek méretarányának megadása alapvető ellenőrzés. Hasonlóan vizsgáld meg az utólag megjelenő bannert, betűtípust, ajánlódobozt és űrlaphibát. Görgess végig, nyiss le elemeket, és várd meg a külső tartalmak betöltését is.

A CLS számítása nem minden mozgást kezel azonosan; a felhasználói beavatkozáshoz közvetlenül kapcsolódó elrendezésváltozás egy része nem számít bele. Ettől a rosszul tervezett mozgás még zavaró lehet. A CLS a mérőszám szempontjából releváns elmozdulásokat, nem a teljes használhatóságot minősíti. Forrás: Google CLS-optimalizálási útmutató.

Az elfogadási próba legyen konkrét: a telefonszámra mutató linket ne tolja arrébb az utólag betöltött kép, a rendelés gombja maradjon kiszámítható helyen. Így a javítás üzleti értelme a pontszám nélkül is érthető.

Milyen sorrendben költs a javításokra?

Előre vedd azt a hibát, amely fontos feladatot akadályoz és sok releváns oldalon jelentkezik. Utána következzenek az azonosított, kisebb ráfordítással javítható okok. Egyetlen színkód vagy 70 alatti laborpontszám nem indokol automatikus technológiacserét.

Ha felmerül az újraépítés, hasonlítsd össze a célzott javítás és a költözés költségét. A költözés új hibalehetőségeket hoz: elvesző URL-eket, eltérő tartalmat, integrációs problémákat és betanítási feladatot. A választást mérési bizonyíték és fenntarthatósági szempont indokolja.

A kiadás után azonnal ismételd meg a labor- és használati próbákat. A terepi adatokban fokozatos változást várj a gördülő időablak miatt. A sikerjelentés külön tartalmazza a teljesítményadatokat és az üzleti mutatókat: több ajánlatkérést csak tényleges, összehasonlítható mérés alapján állíts. A további indexelési ellenőrzéseket a technikai SEO-lista foglalja össze.