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]
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:
- Időablak. A jelentés az elmúlt 28 napot mutatja, benne a javítás előtti napokkal. A laborteszt a mostani állapotot.
- 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]
- 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.
- 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.
- 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.
- 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:
- 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.
- 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.
- 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.
- 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.
- 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.
- 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.
- Javíts sablonszinten. Egy-egy oldal kézi javítása ritkán mozdítja el a csoportot.
- É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.
- Í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]
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
- GoogleChrome, web-vitals JavaScript-könyvtár (GitHub dokumentáció)
- W3C Web Performance Working Group, Largest Contentful Paint és Event Timing specifikációk
- A Search Console a valós felhasználók Chrome-ból gyűjtött adatát mutatja 75. percentilisen, a laborteszt csak egy szimulált betöltés.
- Az URL-csoportok hasonló szerkezetű oldalakat fognak össze, így egy sablonhiba egyszerre sok URL-t ront el.
- Egy javítás hatása a 28 napos gördülő ablak miatt jellemzően 3-5 hét alatt látszik teljesen.
- A javítás ellenőrzése egy 28 napos megfigyelés, amelyet csak akkor érdemes elindítani, ha a javítás már élesben van.
- Mobilt és asztalit mindig külön nézd, mert a két eszköztípus adata és állapota eltérhet.
Gyakori kérdések
Miért zöld a PageSpeed-tesztem, ha a Search Console rossz állapotot mutat?
A laborteszt egyetlen szimulált betöltést mér egy rögzített eszközzel és hálózattal. A Search Console a valós felhasználók elmúlt 28 napjának 75. percentilisét mutatja, amelybe a lassabb telefonok és gyengébb hálózatok is beleszámítanak.
Mennyi idő alatt frissül a Core Web Vitals jelentés egy javítás után?
Az adat 28 napos gördülő ablakból számolódik, ezért a javítás hatása fokozatosan jelenik meg. Az első elmozdulás pár hét múlva látszhat, a teljes kép jellemzően 4-5 hét után áll össze.
Mikor indítsam el a javítás ellenőrzését?
Akkor, amikor a javítás már minden érintett oldalon élesben van, és a gyorsítótár is frissült. Ha korán indítod, a régi mérések miatt az ellenőrzés sikertelen lehet, és újra kell kezdeni.
Miért nem látok adatot a jelentésben?
A jelentéshez elég valós Chrome-forgalom kell. Kis látogatottságú oldalaknál a Google nem tud megbízható mintát képezni, ilyenkor a jelentés üres marad, vagy csak kevés URL jelenik meg.
Javít a helyezésemen, ha minden URL jó állapotú lesz?
A Google szerint a Core Web Vitals az oldalélmény része, de a tartalom relevanciája erősebb tényező. A jó állapot segítheti a felhasználói élményt és közvetve a teljesítményt, konkrét helyezést viszont nem biztosít.
Források és további olvasnivalók
Ezen az oldalon a hivatalosan igazolt információt elsődleges forrásokból építjük fel; a saját tapasztalatot és a szakmai becslést mindig külön jelöljük a szövegben.