A Search Console Core Web Vitals jelentésének értelmezése valós adatból

Scheo · 2026-09-27 · Frissítve: 2026-10-09 · olvasási idő ~10 perc · Szerző: Schmidt Péter

Kijavítod a lassú főoldalt, lefuttatod a PageSpeed Insightsot, és zöld lesz minden mutató. Egy hét múlva megnyitod a Search Console Core Web Vitals jelentését, és ugyanazokat a piros URL-eket látod, mint előtte. Ez a helyzet szinte minden weboldal-tulajdonossal előfordul, és nem hibát jelez. A két eszköz mást mér, más időtávon, és más kérdésre válaszol. Ebben a cikkben végigmegyünk azon, hogyan olvasd a jelentést valós adatból, mennyit kell várnod egy javítás után, és melyik csoporttal érdemes kezdeni.

A cikkben három jelölést használunk. A [Hivatalosan igazolt] a Google nyilvános dokumentációjában szereplő tény. A [Saját tapasztalat] az, amit oldalak üzemeltetése közben rendszeresen látunk. A [Szakmai feltételezés] jól alátámasztott, de nem hivatalosan megerősített következtetés.

Mi a különbség a laborteszt és a valós felhasználói mérés között?

A laborteszt egyetlen, szimulált betöltést mér rögzített eszközzel és hálózattal, a valós felhasználói mérés pedig azt, amit a látogatóid ténylegesen megéltek, több ezer különböző telefonon, böngészőn és kapcsolaton. A laborteszt gyors és megismételhető, ezért hibakeresésre kiváló. A valós mérés lassú és zajos, de ez mutatja meg a tényleges élményt.

Laboreszköz például a Lighthouse, a Chrome fejlesztői eszközeinek Performance panelje, és a PageSpeed Insights alsó, laboreredményeket mutató része. Valós adat a Chrome UX Report (CrUX), a PageSpeed Insights felső, valós felhasználói adatokat mutató blokkja, és a Search Console Core Web Vitals jelentése. [Hivatalosan igazolt]

A laborteszt egy fontos mutatót nem is tud rendesen mérni. Az INP (Interaction to Next Paint) a felhasználói interakciókra adott válaszidőt nézi, egy automatizált betöltés alatt viszont senki nem kattint. A Lighthouse ezért a Total Blocking Time értéket mutatja helyette, ami csak közelítő jelzés. [Hivatalosan igazolt]

A nézőpontunk ebből adódik. A valós adat lassú, de csak az számít. A labormérés csak irány. Arra jó, hogy megtaláld az okot és ellenőrizd, a javításod egyáltalán jó irányba mozdít-e. Azt viszont nem mondja meg, hogy a látogatóid mit élnek meg.

Honnan jön a Search Console Core Web Vitals adata?

A jelentés a Chrome UX Report adatára épül, vagyis olyan Chrome-felhasználók méréseire, akik engedélyezték a használati statisztikák küldését, és az elmúlt 28 nap adatának 75. percentilisét mutatja. [Hivatalosan igazolt]

A 75. percentilis azt jelenti, hogy a látogatások legalább háromnegyedének el kell érnie a jó küszöböt ahhoz, hogy az oldal jó állapotú legyen. A leglassabb negyed tehát nem számít bele közvetlenül, de a közép sem elég. A jelenlegi küszöbök a következők [Hivatalosan igazolt]:

• LCP (Largest Contentful Paint, a legnagyobb tartalmi elem megjelenése) jó 2,5 másodpercig, gyenge 4 másodperc fölött.
• INP (Interaction to Next Paint) jó 200 ezredmásodpercig, gyenge 500 ezredmásodperc fölött. 2024 márciusában váltotta a korábbi FID mutatót.
• CLS (Cumulative Layout Shift, az elrendezés elcsúszása) jó 0,1-ig, gyenge 0,25 fölött.

Egy URL állapotát a leggyengébb mutatója határozza meg. Ha az LCP és a CLS jó, de az INP gyenge, az URL gyenge állapotú lesz. [Hivatalosan igazolt]

Ebből az is következik, hogy a kis forgalmú oldalak gyakran meg sem jelennek. A Google-nek elég mérés kell egy megbízható percentilishez, ami egy kisebb helyi vállalkozás aloldalainál sokszor nincs meg. Ilyenkor a jelentés üres, vagy csak néhány URL-t mutat. [Hivatalosan igazolt]

Ha a jelentés nálad üres, akkor sem vagy vakon. Először nézd meg a PageSpeed Insights felső blokkjában, van-e legalább a teljes domainre összesített valós adat, mert az kisebb forgalomnál is gyakran megjelenik. Utána teszteld laborban a fő sablonokat (főoldal, szolgáltatásoldal, blogbejegyzés), és javítsd azt, ami ott egyértelműen rossz. Végül építsd be a saját mérést a lentebb leírt web-vitals könyvtárral, így a saját látogatóidról is lesz adatod. [Saját tapasztalat]

Miért URL-csoportokban mutatja az eredményt a Search Console?

A Search Console a hasonló felhasználói élményt adó oldalakat egy csoportba teszi, mert a legtöbb URL-nek nincs elég saját forgalma, a hasonló oldalak pedig jellemzően ugyanabból a sablonból épülnek, és ugyanazért a hibáért lassúak. [Hivatalosan igazolt]

A jelentés hibatípusonként listázza a gondot (például „LCP-probléma: 2,5 mp-nél hosszabb (mobil)”), azon belül pedig példa-URL-eket és csoportokat mutat. Egy csoport mellett látod az érintett URL-ek számát és a csoport összesített mutatóértékét. Ha egy csoport egy példa-URL-jét megnyitod, a hozzá hasonló oldalak listáját is megkapod.

A gyakorlatban ez azt jelenti, hogy egy webshopnál a termékoldalak, a kategóriaoldalak és a blogbejegyzések jó eséllyel külön csoportba kerülnek. Ha a termékoldal-sablonban egy túl nagy, lusta betöltés nélküli fő termékkép van, az 800 termékoldalt ront egyszerre, és egy sablonjavítás 800 oldalt javíthat. [Saját tapasztalat]

A csoportosítás logikáját a Google nem hozza nyilvánosságra. A megfigyelésünk az, hogy nagyrészt az URL-szerkezet és az oldal felépítése alapján dolgozik, de egy csoportba néha meglepő oldalak is bekerülnek. [Szakmai feltételezés] Ezért egy csoport kijavítása előtt nyiss meg 3-5 példa-URL-t, és ellenőrizd, tényleg ugyanaz a sablon van-e mögöttük.

Miért mutathat mást a jelentés, mint az egyszeri sebességteszt?

Az egyszeri teszt egy pillanatfelvétel egy gépről, a jelentés pedig négy hét valós látogatásainak összesítése, ezért a kettő eltérése természetes, és a döntésnél a jelentés a mérvadó.

A leggyakoribb okok, amiért a két szám szétválik:

1. Időablak. A jelentés az elmúlt 28 napot mutatja, benne a javítás előtti napokkal. A laborteszt a mostani állapotot.
2. Eszközpark. A Lighthouse egy közepes mobilt és lassított hálózatot szimulál. Ha a látogatóid nagy része régebbi Androidot használ, a valós LCP rosszabb lesz. Ha főleg új iPhone-ról jönnek, lehet jobb is (bár az iOS-es Safari adata nincs benne a CrUX-ben). [Hivatalosan igazolt]
3. Gyorsítótár és visszatérő látogatók. A laborteszt hideg gyorsítótárral tölt. A visszatérő látogatónál sok elem már a böngészőben van.
4. Interakció. Az INP-t csak valódi kattintásokból lehet mérni. Egy nehéz menü, szűrő vagy sütisáv csak a valós adatban látszik.
5. Elcsúszás a görgetés közben. A laborteszt a betöltés elejét figyeli, a valós CLS viszont a teljes oldalélettartamot. Egy később betöltődő hirdetés vagy csevegőablak a laborban nem, a valós adatban igen ront.
6. Csoportszint. Te egy URL-t teszteltél, a jelentés egy több száz URL-es csoport állapotát mutatja.

Van egy fordított eset is. A laborteszt piros, a valós adat zöld. Ez gyakran akkor fordul elő, amikor a látogatók gyors eszközről és jó hálózatról jönnek, vagy a CDN a valós forgalomnál jól teljesít. Ilyenkor nincs sürgős teendő, a laborhibák listája inkább optimalizálási ötletgyűjtemény. [Saját tapasztalat]

Mennyi idő után látszik egy javítás hatása?

A 28 napos gördülő ablak miatt egy javítás hatása fokozatosan jelenik meg, az első elmozdulás jellemzően 1-2 hét után, a teljes kép 4-5 hét után látszik.

A 28 napos ablak hivatalos, és a jelentés adata pár nap késéssel frissül. [Hivatalosan igazolt] Tegyük fel, hogy szeptember 1-jén élesíted a javítást. Szeptember 8-án az ablak háromnegyede még a régi, lassú méréseket tartalmazza. A 75. percentilis akkor kezd átfordulni, amikor a javított napok aránya elég nagy lesz, ami a mértéktől függően a második-harmadik hét körül történik. Szeptember végére az ablak nagyjából csak javított méréseket tartalmaz. [Szakmai feltételezés, a gördülő ablak működéséből levezetve]

A tapasztalatunk az, hogy a kis mértékű javítás (például 3,1 másodperces LCP-ből 2,6) sokáig a határ körül billeg, és hetekig nem vált zöldre. Egy határozott javítás (3,1-ből 1,8) hamarabb átfordul. Ezért érdemes a küszöb alá jó tartalékkal célozni. [Saját tapasztalat]

Ha gyorsabb visszajelzés kell, nézd a PageSpeed Insights felső blokkját vagy a CrUX API-t az adott URL-re. Ezek is 28 napos adatok, de URL-szinten és frissebben mutatják az elmozdulást, mint a csoportos nézet.

Mit jelent a „javítás ellenőrzése” folyamat?

A javítás ellenőrzése egy 28 napos megfigyelés, amely során a Search Console figyeli, hogy a csoport URL-jei tartósan a jó küszöbön belül maradnak-e, és a végén sikeresnek vagy sikertelennek jelöli a hibát. [Hivatalosan igazolt]

Egy hibatípus részleteinél találod a „Javítás ellenőrzése” gombot. Az elindítás után a folyamat a következő állapotokon mehet végig [Hivatalosan igazolt]:

• Elindult, amikor a megfigyelés még nem gyűjtött elég adatot.
• Jónak tűnik, amikor az eddigi adatok alapján a probléma megszűnőben van.
• Sikeres, amikor 28 nap után a csoport URL-jei jó állapotban vannak.
• Sikertelen, amikor a megfigyelés alatt az URL-ek még mindig hibásak.

Az ellenőrzés nem gyorsítja az adatgyűjtést, és a rangsorolásra sincs hatása. Azt teszi, hogy követhető, lezárt állapotot ad egy konkrét hibához. [Szakmai feltételezés]

A leggyakoribb hiba, amit látunk, a túl korai indítás. Ha a javítás csak a sablon egy részén élesedett, vagy a CDN még a régi változatot szolgálja ki, az ellenőrzés sikertelen lesz, és újra kell indítani, ami újabb 28 nap. Csak akkor indítsd, amikor a laborteszt minden példa-URL-en a jó tartományban van, és a gyorsítótárat is ürítetted. [Saját tapasztalat]

Hogyan olvasd a jelentést lépésről lépésre?

Kezdd a mobilos gyenge csoportokkal, azon belül a legtöbb URL-t érintővel, és csak utána foglalkozz az asztali és a „javításra szorul” állapotú csoportokkal. A mobil azért elöl, mert a Google a mobilos változatot indexeli, és a legtöbb oldal forgalmának nagyobb része mobilról jön. [Hivatalosan igazolt a mobilelsőbbségi indexelés, a sorrend saját tapasztalat]

Ellenőrzőlista:

1. Mobil és asztali külön. Nyisd meg mindkét nézetet, és írd fel a gyenge, a javításra szoruló és a jó URL-ek számát eszközönként. Ne átlagold a kettőt.
2. Melyik mutató a hibás? Nézd meg a hibatípust (LCP, INP vagy CLS). A három teljesen más javítást kíván, ezért ne keverd őket egy feladatba.
3. Hány URL-t érint? Rendezd a csoportokat az érintett URL-ek száma szerint. Egy 600 URL-es termékoldal-csoport előbb jön, mint egy 4 URL-es.
4. Mennyire van messze a küszöbtől? Egy 2,7 másodperces LCP-jű csoport kis javítással átfordulhat, egy 6 másodperces komoly munkát jelent. Ezt is írd fel.
5. Mennyi forgalmat hoz a csoport? Vesd össze a Search Console Teljesítmény jelentésével. Egy sok kattintást hozó csoport javítása többet ér.
6. Nyiss meg 3-5 példa-URL-t. Ellenőrizd, ugyanaz a sablon van-e mögöttük, és futtass rájuk labortesztet az okkereséshez.
7. Javíts sablonszinten. Egy-egy oldal kézi javítása ritkán mozdítja el a csoportot.
8. Élesítés után várj, és laborban ellenőrizz. Ha a laboreredmény minden példán jó, indítsd el a javítás ellenőrzését.
9. Írd fel a dátumot. Az élesítés napja nélkül négy hét múlva nehéz lesz megmondani, mi okozta a változást.

Hogyan gyűjthetsz saját valós adatot, amíg a jelentés frissül?

A Google által fejlesztett nyílt forráskódú web-vitals JavaScript-könyvtárral a saját látogatóid LCP, INP és CLS értékét is mérheted, és elküldheted az analitikádba, így napokon belül látod az elmozdulást. [Hivatalosan igazolt, hogy a könyvtár ugyanazokat a mutatókat méri, mint a CrUX]

Egy egyszerű beépítés, amely a mért értéket GA4-eseményként küldi el:

import {onLCP, onINP, onCLS} from 'web-vitals';

function kuld({name, value, id}) { gtag('event', name, {value: Math.round(name === 'CLS' ? value * 1000 : value), metric_id: id}); }

onLCP(kuld); onINP(kuld); onCLS(kuld);

A saját mérésed nem fog pontosan egyezni a Search Console-lal, mert más a minta (nálad benne van a Safari és a Firefox is, a CrUX-ben nincs), és te nem feltétlenül 75. percentilist számolsz. [Hivatalosan igazolt] Iránynak viszont kiváló, mert a javítás utáni napokban már látod, hogy a valós értékek elmozdultak-e. Ha az analitikában a 75. percentilis a küszöb alá esett, jó eséllyel a Search Console is követni fogja néhány héttel később. [Szakmai feltételezés]

Mit ne várj a Core Web Vitals javításától?

A jó Core Web Vitals állapot segítheti a felhasználói élményt és az oldalélmény-jeleket, de önmagában nem hoz helyezést, és nem pótolja a releváns tartalmat. A Google hivatalosan is azt írja, hogy az oldalélmény egy a sok jel közül, és a jó tartalom erősebb szempont. [Hivatalosan igazolt]

Amit reálisan várhatsz, az a kevesebb visszafordulás egy lassú mobiloldalon, gördülékenyebb űrlapkitöltés és kevesebb elkattintás a sütisáv vagy egy ugráló gomb miatt. Ezeket a konverziós adatokban érdemes figyelni, nem a helyezésekben. [Saját tapasztalat]

Az AI-alapú keresőknél és válaszmotoroknál a sebesség közvetett tényező. A gyorsan és stabilan betöltődő, jól feltérképezhető oldalt a robotok is könnyebben olvassák, de arra nincs nyilvános adat, hogy a Core Web Vitals közvetlenül befolyásolná, melyik oldalt idézik. [Szakmai feltételezés]

Mi az a web vitals, és melyik mutató számít belőle a Google-nek?

A Web Vitals a Google kezdeményezése, amely egységes mutatókat ad a weboldalak felhasználói élményének mérésére. Ezen belül a Core Web Vitals három mutatója, az LCP, az INP és a CLS az, amelyet a Search Console jelentése és a Google oldalélmény-értékelése figyel. [Hivatalosan igazolt]

A kezdeményezés 2020-ban indult, mert addig szinte minden mérőeszköz más számot tartott fontosnak, és a weboldal-tulajdonos nem tudta, mire figyeljen. A Web Vitals körébe a három fő mutatón túl kiegészítő mérőszámok is tartoznak, például a TTFB (Time to First Byte, a szerver első válaszbájtjának ideje) és az FCP (First Contentful Paint, az első tartalom megjelenése). Ezek nem kerülnek be a Search Console állapotértékelésébe, okkeresésnél viszont sokat segítenek. [Hivatalosan igazolt]

A mutatókat érdemes egymásra épülő láncként nézni, mert így hamar kiderül, hol keresd a hibát.

• Lassú TTFB esetén minden későbbi lépés csúszik, ezért az FCP és az LCP is magas lesz. Ilyenkor a tárhely, a gyorsítótárazás vagy a szerveroldali kód a gyanús.
• Jó TTFB, de lassú LCP esetén jellemzően a fő kép mérete, egy késve betöltődő betűtípus vagy egy blokkoló szkript tartja vissza a legnagyobb elem megjelenését.
• Jó LCP, de gyenge INP esetén a betöltés rendben van, a gond a kattintás utáni JavaScript-munkával van, például egy nehéz szűrőnél, menünél vagy sütisávnál.
• Magas CLS esetén méret nélküli képek, később beszúrt sávok vagy betűtípus-csere tolja el a tartalmat.

Az, hogy a lassú szerverválasz az LCP-t is rontja, a Google dokumentációjában szerepel. [Hivatalosan igazolt] A fenti lánc mint diagnosztikai sorrend viszont a saját gyakorlatunk, amellyel a legtöbb esetben egy-két lépésben eljutunk a valódi okhoz. [Saját tapasztalat]

Melyik weboldal sebesség teszt mit mér, és hogyan futtasd, hogy használható eredményt kapj?

A legjobb induló weboldal sebesség teszt a Google PageSpeed Insights, mert egy oldalon mutatja a valós felhasználói adatot és a laboreredményt. A döntést mindig a felső, valós adatokat mutató blokkra építsd, a laboreredményt pedig okkeresésre használd.

A gyakori eszközök más-más kérdésre válaszolnak.

• PageSpeed Insights. Felül valós CrUX-adat, ha van elég mérés, az adott URL-re, ha nincs, a teljes domainre összesítve. Alul Lighthouse-laborteszt. [Hivatalosan igazolt]
• Lighthouse a Chrome fejlesztői eszközeiben. Saját gépen fut, így fejlesztői környezetet vagy bejelentkezés mögötti oldalt is tesztelhetsz vele. A böngészőbővítmények torzíthatják az eredményt, ezért inkognitóablakban futtasd. [Saját tapasztalat]
• Search Console Core Web Vitals jelentés. Csoportos, 28 napos valós adat a teljes webhelyre. Ez mutatja meg, mennyi oldalt érint egy hiba.
• Külső laboreszközök, például WebPageTest vagy GTmetrix. Vízesés-diagramot és filmszalagot adnak a betöltésről, és több tesztelési helyszín közül választhatsz. Valós felhasználói adatot nem mérnek, csak laboreredményt.

Az eredmény csak akkor hasznos, ha összevethető. Ezt a sorrendet követjük minden mérésnél [Saját tapasztalat].

1. Mindig ugyanazt az URL-t teszteld, mobil beállítással, mert a Search Console-ban is a mobil nézet a fontosabb.
2. Futtasd legalább háromszor, és a középső értéket jegyezd fel. A Lighthouse eredménye futásonként szór a hálózat és a szerver terhelése miatt. [Hivatalosan igazolt]
3. Sablononként tesztelj. A főoldal, a kategóriaoldal, a termék- vagy szolgáltatásoldal és a blogbejegyzés külön kerüljön a listádra, mert a Search Console is így csoportosít.
4. Nézd meg, milyen szintű a valós adat. Ha a PageSpeed Insights felső blokkja a teljes domainre mutat adatot, abból ne vonj le következtetést egy konkrét aloldalra.
5. Kösd a hibát a valós mutatóhoz. A laborjavaslatok közül azzal kezdd, amelyik a Search Console-ban gyenge mutatóhoz tartozik. Gyenge LCP-nél a kép- és szerverjavaslatok jönnek elsőnek, gyenge CLS-nél a méret nélküli elemek.
6. Írd fel dátummal az eredményt és azt, melyik változatot tesztelted, hogy a javítás előtti és utáni állapot később is összevethető legyen.

A Lighthouse 0-100 közötti teljesítménypontszáma több labormutató súlyozott összege, és nem azonos a Core Web Vitals állapottal. [Hivatalosan igazolt] A Google oldalélmény-értékelése a valós felhasználói adatra épül, ezért egy 95 pontos oldal is lehet gyenge állapotú a Search Console-ban, és egy 60 pontos is lehet jó. [Hivatalosan igazolt, hogy az értékelés valós adatból dolgozik] A pontszám kergetése helyett a három mutató valós értékét figyeld.

Források és további olvasnivalók

• Google Search Central, Core Web Vitals jelentés (Search Console súgó)
• Google Search Central, Az oldalélmény megértése a Google keresési eredményeiben
• web.dev, Web Vitals és a mutatók küszöbértékei (LCP, INP, CLS)
• web.dev, a labor- és a terepi adatok eltéréséről szóló útmutató
• Chrome for Developers, Chrome UX Report (CrUX) dokumentáció és CrUX API
• Chrome for Developers, Lighthouse teljesítménypontszám és a mérési szórás dokumentációja
• GoogleChrome, web-vitals JavaScript-könyvtár (GitHub dokumentáció)
• W3C Web Performance Working Group, Largest Contentful Paint és Event Timing specifikációk