Core Web Vitals magyarul 2026: LCP, INP, CLS — mit mérnek, és hogyan javítsa

2026 szeptemberében a Chrome-csapat a saját havi adatjelentésében leírta: különösen az INP — az oldal reakcióidejét mérő mutató — folyamatos romlása „aggodalomra ad okot”, és biztos magyarázata sincs rá (CrUX release notes). Közben a magyar felhasználók által látogatott WordPress-oldalaknak mobilon alig több mint a fele teljesíti mindhárom küszöböt (2026. augusztus) — náluk nem az INP, hanem a betöltés a leggyengébb pont. Ez a cikk a technikai SEO-ellenőrzésünk sebességfejezetének mélyfúrása: ott az alapokat tárgyaltuk, itt azt, hogy mit mér pontosan a három mutató, honnan tudja, van-e gond az oldalával, mi rontja mutatónként, ki javítja — és mit kérdezzen a fejlesztőjétől.

A három mutató a betöltést, a reakciót és a stabilitást méri — a látogatások legalább háromnegyedében

A Core Web Vitals három számmal írja le, milyen élmény egy oldal a valós látogatónak:

• LCP — mikor jelenik meg a fő tartalom. A látogató így éli meg: „sokáig üres a képernyő”. Jó: legfeljebb 2,5 másodperc; 4 másodperc fölött gyenge.
• INP — mennyi idő alatt reagál az oldal egy koppintásra vagy kattintásra. „Megnyomom, és nem történik semmi.” Jó: legfeljebb 200 ezredmásodperc; 500 fölött gyenge.
• CLS — mennyire ugrál a tartalom. „Ugrik a szöveg, mellékattintok.” Jó: legfeljebb 0,1; 0,25 fölött gyenge.

A mérés minden látogatásra kiterjed, a minősítés pedig a 75. percentilisen dől el: akkor jó, ha a látogatások legalább háromnegyedében ilyen jó vagy jobb az élmény. A leglassabb negyed tehát nem rontja el a minősítést, a tipikus mobilos látogató viszont igen. A mobilt és az asztali gépet külön értékeli a mérés. A web.dev szerint a három mutató „stabil”: legfeljebb évente változhat, és 2026-ban nem változott. Az utolsó nagy váltás 2024. március 12-én volt, amikor az INP a régi FID helyére lépett. Hogy a Core Web Vitals hol áll a teljes SEO-munkában, azt a SEO-útmutatónk Core Web Vitals-fejezete mutatja be.

Hogy van-e gond az oldalával, azt a valós használati adat mondja meg — nem a PageSpeed-pontszám

A diagnózis három ingyenes lépés, ebben a sorrendben:

1. Search Console → Core Web Vitals-jelentés. Megmutatja, melyik mutató bukik, mobilon vagy asztali gépen, hasonló oldalakból álló URL-csoportokban. A csoport minősítése mindig a leggyengébb mutatójáé. Csak indexelt oldalak szerepelnek, és csoport csak akkor jelenik meg, ha LCP-re és CLS-re is van elég adat.
2. PageSpeed Insights — a felső rész. A felső blokk a valós használati adat: a Chrome User Experience Report (CrUX), vagyis a Chrome valós felhasználói adatai, 28 napos gördülő időablakban, naponta frissítve. Az alsó laborfuttatás hibakeresésre való: megmutatja, mi lassít, de a pontszáma nem azonos a Core Web Vitalsszal.
3. A trendhez: CrUX Vis vagy a Chrome fejlesztői eszközeinek élő mérése. A CrUX Vis hetente frissül, és 40 hét trendjét mutatja; a DevTools Performance panelje a saját gépén méri az LCP-t, az INP-t és a CLS-t, mellette a valós adattal. (A régi Web Vitals Chrome-bővítmény 2025 januárja óta nem támogatott, a CrUX Dashboardot pedig 2025 novemberében kivezették.)

Miért nem a pontszám a cél? A Lighthouse-pontszám súlyai között (TBT 30%, LCP 25%, CLS 25%, FCP 10%, Speed Index 10%) az INP nem is szerepel, mert egy betöltési laborfuttatásban nincs valós kattintás; helyette a TBT közelít. A web.dev eszközútmutatója egyértelmű: mindig a valós Core Web Vitals-adatra összpontosítson, ne a Lighthouse-pontszámra.

Ha a Search Console-ban „Nincs elérhető adat” áll, az oldalnak nincs elég valós Chrome-forgalma — a minimális küszöb a CrUX módszertana szerint nem nyilvános. A PageSpeed Insights ilyenkor a teljes webhely (origin) adatát mutatja, ha arra van elég adat. Kis forgalmú KKV-oldalaknál ez gyakori, és önmagában nem hiba.

Mutatónként: mi rontja, és ki javítja?

LCP: a rossz értéket többnyire a szerver és a későn induló letöltés okozza, nem a kép mérete

A Chrome-csapat 2024-es, valós használati adatokon végzett elemzése szerint a rossz LCP-jű webhelyek 75. percentilisű értékeinek mediánja: szerverválasz (TTFB) 2270 ezredmásodperc, a képletöltés elindulásáig eltelt idő 1290, maga a letöltés csak 350, a megjelenítés 360. A szerzők megfogalmazásában: a rossz LCP-jű webhelyek többsége a 75. percentilisű LCP-idejének kevesebb mint 10%-át tölti a kép letöltésével. (Az adat a képes LCP-jű oldalbetöltésekre vonatkozik.) A képtömörítés tehát fontos, de ritkán ez a fő ok.

A web gyakorlata ezt megerősíti: a Web Almanac 2025 szerint mobilon az oldalak 76%-ánál kép a legnagyobb tartalmi elem, és ezeknek az oldalaknak 15,7%-a lusta betöltéssel (lazy loading) késlelteti — pedig éppen ennek kellene elsőként megjelennie. A fetchpriority attribútum „high” értékét, amely a böngészőnek jelzi a prioritást, csak az oldalak 17,3%-a használja.

• Ön is megteheti: méretezze és tömörítse a fő képet (WebP vagy AVIF); a nyitóoldali képváltót (slider) a szakmai gyakorlat szerint érdemes egyetlen képre cserélni; frissítse a WordPresst (hogy ez mit hoz, lent, a platformfejezetben olvashatja); ha pedig a szerverválasz lassú, vizsgálja felül a tárhelyét.
• Fejlesztő vagy tárhelyszolgáltató kell: a lusta betöltés levétele a fő képről és magas prioritás adása, oldalgyorsítótár és tartalomkézbesítő hálózat (CDN), a renderelést blokkoló CSS és JavaScript csökkentése, a felesleges átirányítások megszüntetése. A részleteket a web.dev LCP-útmutatója adja.

INP: túlnyomórészt mobilon bukik, a fő szálat foglaló szkriptek miatt

A HTTP Archive 2026. augusztusi globális adata szerint asztali gépen az oldalak 97,7%-ának jó az INP-je, mobilon csak 80,1%-ának: a gyengébb telefonokon a JavaScript lassabban fut, és a böngésző fő szála — ahol a kattintások feldolgozása is történik — tovább foglalt. Mobilon a magyar felhasználók által látogatott oldalaknál a jó INP-arány 78,4% — alacsonyabb, mint a német (88,2%), az osztrák (87,4%) és a lengyel (82,7%) felhasználók által látogatott oldalaknál; ennek okára nincs adat. WordPressen viszont ritkábban ez a szűk keresztmetszet: a magyar felhasználók által látogatott WordPress-oldalak 86,7%-ának jó az INP-je mobilon.

• Ön is megteheti: nézze át a Google Tag Managert — a már nem használt címkéket törölje vagy szüneteltesse, a nem kritikusak töltődjenek be később. Kérdezze meg, szükség van-e minden chat-, pixel- és hőtérkép-widgetre. Ellenőrizze, mit tölt be egyszerre a sütikezelő sáv az „Elfogadom” gombra kattintás után.
• Fejlesztő kell: a hosszú JavaScript-feladatok feldarabolása (a scheduler.yield() a Chrome 129 és a Firefox 142 óta működik, Safariban 2026 szeptemberében még nem, ezért tartalék megoldás kell), az oldal elemszerkezetének (DOM) csökkentése és a Long Animation Frames-mérés, amellyel név szerint azonosítható, melyik szkript lassít.

CLS: méret nélküli képek, késve beszúrt sávok és a betűtípus-csere okozza

A Web Almanac 2025 szerint a mobiloldalak 62%-án van legalább egy méret nélküli kép, és 40%-ukon fut erőforrás-igényes animáció. Gyakori ludas a felülről beúszó sütisáv is: a felhasználói bevitelt követő 500 ezredmásodpercen belüli elmozdulás nem számít bele a CLS-be (web.dev), a magától megjelenő sáv viszont igen. A megoldás többnyire egyszerű: méret minden képnek és beágyazásnak, a sütisáv alul vagy lebegő ablakként (a web.dev ajánlása), a betűtípusokhoz pedig méretigazított tartalék-betűtípus.

Saját példa: az MSM Chicken Goods oldalán az első fázis teljesítménymunkája (saját szerverről kiszolgált betűtípusok, CSS-animációk, reszponzív képméretek) után a laborban mért CLS közel nulla lett, a Lighthouse-teljesítmény pedig asztali gépen 52-ről 100-ra, mobilon 65-ről 92-re javult. Ez laboreredmény az adott tesztkörülmények között: jól mutatja, mit mér a labor, de nem valós felhasználói Core Web Vitals-adat.

Plusz tipp: a vissza/előre gyorsítótár (bfcache). Mobilon minden ötödik navigáció a vissza- vagy előregombbal történik; ha az oldal alkalmas a gyorsítótárazásra, ezek azonnal betöltődnek (web.dev). Egy esettanulmány: a Duda honlapépítő mintegy 40 ezer oldalán a gyorsítótárazást tiltó fejléc eltávolítása után 1,80%-kal több webhely teljesítette a CLS-küszöböt (CrUX, 2025. május).

Platformok a gyakorlatban: mobilon a magyar felhasználók által látogatott WordPress-oldalak fele elbukik, az UNAS- és Shoprenter-boltok 87–94%-a átmegy

A HTTP Archive technológiai jelentése országra is szűrhető. A 2026. augusztusi adat a magyarországi Chrome-felhasználók által látogatott oldalakat méri mobilon — ebben a nagy nemzetközi oldalak is benne vannak, tehát nem „a magyar weboldalak” listája, hanem a magyar felhasználók élménye:

Olvasási szabály, mielőtt bármit leszűrne: ezek összefüggések, nem ok-okozat. A technológiát a kezdőlap alapján ismerik fel, és eltérő típusú oldalakat hasonlítanak össze — egy bérelt webshopmotor egységes, optimalizált sablonra épül, a WordPress-oldalak között a hobbiblogtól a nagy portálig minden van. Ezért ne platformváltással kezdje: előbb nézze meg, melyik mutató bukik az Ön oldalán.

A harmadik oszlop összefüggést mutat: ahol ritka a jó szerverválasz, ott ritkább a megfelelés is — ezeknek a WordPress-oldalaknak csak 26,5%-ánál jó a TTFB. A szerverválaszt a tárhely, a gyorsítótárazás, a sablon és a bővítmények együtt alakítják; hogy az Ön oldalán melyik a szűk keresztmetszet, azt az aggregált adat nem mutatja meg, azt mérni kell. A Shoprenter-boltok példája szerint gyengébb szerverválasz mellett is lehet jó az LCP: náluk 94,2%.

Globálisan (2026. augusztus, mobil) a sorrend hasonló: Wix 81,2%, Shopify 76,5%, Squarespace 72,1%, Webflow 71,2%, Drupal 64,6%, Joomla 57,1%, WordPress 48,7% — és a Next.js 35,1%. Ez utóbbit azért emeljük ki, mert mi magunk is Next.js-szel építünk: a keretrendszer neve nem garancia, a kivitelezés dönt. A platformdöntés sebességkérdéseiről a Next.js vagy WordPress útmutatónk sebességfejezete, a webshopmotorokról a Shopify vagy WooCommerce útmutatónk szól.

WordPressen az első, ingyenes lépés a frissítés: a 6.3 óta a rendszer magától prioritást ad a valószínű LCP-képnek (a fejlesztők szerint jellemzően 5–10% LCP-javulással), a 6.5 óta támogatja az AVIF-formátumot, a 6.8 óta pedig előre betöltheti a valószínű következő oldalt. A gyorsítótár-bővítmény segíthet, de nem csodaszer: a szerverválaszt csak akkor javítja, ha az oldal a gyorsítótárból jön — a kosár vagy a keresés oldalain nem.

Üzleti hatásra csak esettanulmány van — garancia nincs

A Google hivatalos szövege szerint a Core Web Vitalst a rangsoroló rendszerek használják, de a Google Kereső mindig a legrelevánsabb tartalmat igyekszik megjeleníteni, akkor is, ha az oldalélmény gyengébb. A jó eredmény azt sem garantálja, hogy az oldal a találatok élére kerül, és a Google szerint a tökéletes pontszám hajszolása pusztán SEO-okokból nem feltétlenül a legjobb időráfordítás. Konverziós emelkedést sem ígérhet senki: 2024 és 2026 között nem találtunk független, oksági, nagy mintájú kutatást a Core Web Vitals üzleti hatásáról. Ezért legyen óvatos azzal, aki garantált helyezést vagy fix konverziós százalékot ígér a gyorsítás eredményeként.

Ami van, az vállalati esettanulmány — dátummal, módszerrel és azzal a torzítással, hogy csak a sikeres projekteket teszik közzé:

• Vodafone (2021, A/B teszt): az LCP 8,3-ról 5,7 másodpercre javult, az eladások 8%-kal nőttek.
• Trendyol (2023, A/B teszt): nagyjából felére csökkent INP, 1%-kal magasabb átkattintási arány.
• Rakuten 24 (2022, egyetlen érkezőoldal, egyhónapos A/B teszt): 53,37%-kal több bevétel látogatónként — kiugró, nem általánosítható eredmény.

A Vodafone és a Trendyol a javítás után is a „gyenge” sávban maradt, a saját A/B tesztjük mégis üzleti javulást mért: ezekben az esetekben a javulás számított, nem a zöld pipa. Mikor nem éri meg most a Core Web Vitalsra költeni? Ha a valós adat már jó; ha nincs valós adat, és egy egyszerű bemutatkozóoldalról van szó; vagy ha a szűk keresztmetszet a tartalom és a relevancia. Mikor igen? Fizetett forgalmat fogadó érkezőoldalnál (landing page), webshopnál, és ha az oldal a valós adat szerint nagyon lassú.

Tíz kérdés a fejlesztőjének — ebből kiderül, érti-e a Core Web Vitalst

1. Melyik mutató bukik a Search Console-ban — mobilon vagy asztali gépen, és melyik URL-csoportban?
2. Mi a legnagyobb tartalmi elem a fő sablonokon, és mennyi az LCP négy része: szerverválasz, a betöltés késése, letöltés, megjelenítés?
3. Van-e lusta betöltés vagy képváltó a fő képen, és kap-e magas betöltési prioritást?
4. Mennyi a szerverválasz a 75. percentilisen? Van-e oldalgyorsítótár és CDN, és mi történik, ha az oldal nem a gyorsítótárból jön (kosár, keresés)?
5. Mely külső szkriptek futnak, és melyek töltődnek be egyszerre a sütik elfogadása után?
6. Van-e 50 ezredmásodpercnél hosszabb feladat a mobilos menü, a szűrő vagy az űrlap használatakor, és hogyan bontják fel — Safari-tartalékkal?
7. Minden kép, iframe és beágyazás kap-e előre lefoglalt helyet?
8. Hogyan töltődnek be a webes betűtípusok (megjelenítési mód, előtöltés, méretigazított tartalék)?
9. Alkalmas-e az oldal a vissza/előre gyorsítótárra, vagy valamilyen fejléc, illetve eseménykezelő kizárja?
10. Hogyan és mikor mérjük a hatást: Search Console-ellenőrzés, CrUX Vis vagy saját valós mérés?

A Core Web Vitals nem pontszámverseny, hanem három kérdés: mikor látja a látogató, amit keres; reagál-e az oldal, amikor megnyom valamit; és a helyén marad-e, amire kattintana. Ezt a valós adat mondja meg — a javítás pedig a bukó mutatónál kezdődik.

Ha a Search Console jelzi, hogy van probléma, de nem tudja, melyik mutatóval kezdje: a diagnózis és a technikai javítás a Technikai SEO Sprint része, a Foundation pedig ezt kulcsszókutatással és tartalomstratégiával egészíti ki. A díjakat és a terjedelmet lent, a cikk végén találja.