PageSpeed-pontszám vagy CrUX-terepadat, melyik alapján dönts

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

Ha lefuttatod a PageSpeed Insightsot egy oldalra, két különböző adatcsomagot kapsz egymás alatt. Felül a valódi látogatóktól gyűjtött terepadat áll (ha van elég), alatta a Lighthouse laborméréséből számolt, 0 és 100 közötti pontszám. A kettő sokszor mást mond. Előfordul, hogy egy oldal mobilon 45 pontot kap, és közben teljesíti a Core Web Vitals értékelést, de az is, hogy 92 pont mellett elbukik rajta. Ha a pontszám alapján rendelsz fejlesztést, könnyen olyan problémára költesz, amit a látogatóid nem is éreznek. Érdemes ezért tisztán látni, mit mér a két forrás, melyiket használja a Google, és mikor éri meg a pontszámmal foglalkozni.

Mi a különbség a Lighthouse-pontszám és a CrUX-terepadat között?

A Lighthouse-pontszám egyetlen, szimulált körülmények között lefuttatott betöltés eredménye. A CrUX-terepadat a valódi Chrome-felhasználók elmúlt 28 napos tapasztalatát mutatja. Az első hibakeresésre való, a második azt méri, amit a látogató ténylegesen átél.

A Lighthouse egyetlen gépen tölti be az oldalt, egy középkategóriás mobiltelefont emulál, és lassú mobilhálózatot szimulál. Öt mutatót mér, a First Contentful Paintet (FCP), a Speed Indexet, a Largest Contentful Paintet (LCP), a Total Blocking Time-ot (TBT) és a Cumulative Layout Shiftet (CLS). Ezekből súlyozott pontszámot számol. A jelenlegi Lighthouse-verziókban a TBT 30, az LCP és a CLS 25-25, az FCP és a Speed Index 10-10 százalékkal számít bele. A pontszám tehát egy modell kimenete, amely egy elképzelt felhasználó egyetlen látogatását írja le.

A CrUX (Chrome User Experience Report) azoknak a Chrome-felhasználóknak a méréseit gyűjti, akik engedélyezték a használati statisztikák megosztását. Itt nincs összesített pontszám. Három Core Web Vitals mutatót kapsz, az LCP-t, az INP-t (Interaction to Next Paint) és a CLS-t, mindegyiket a 75. percentilisen. Egy mutató akkor számít jónak, ha a látogatások legalább háromnegyedében eléri a küszöböt. A küszöb az LCP-nél 2,5 másodperc, az INP-nél 200 ezredmásodperc, a CLS-nél 0,1. Az oldal akkor teljesíti a Core Web Vitals értékelést, ha mindhárom mutató jó.

Fontos részlet, hogy az INP csak terepen mérhető, mert valódi kattintás vagy koppintás kell hozzá. A laborban a TBT áll hozzá a legközelebb, de a kettő kapcsolata laza. Ha egy nehéz szkript csak egy menü megnyitásakor fut le, a Lighthouse gyorsnak látja az oldalt, a látogató viszont akadozást érez. Az INP 2024 márciusában váltotta az FID-et a Core Web Vitals mutatók között.

Gyors összevetés

• Forrás. A Lighthouse egy szimulált betöltést mér, a CrUX több ezer vagy akár több millió valódi látogatást.
• Időablak. A Lighthouse az adott pillanatot rögzíti, a CrUX az utolsó 28 nap gördülő adatát mutatja.
• Eszköz és hálózat. A Lighthouse rögzített profillal dolgozik, a CrUX-ben a látogatóid saját telefonja, gépe és netkapcsolata jelenik meg.
• Felhasználás. A Lighthouse-ból azt tudod meg, mi lassít és hol, a CrUX-ből azt, hogy a látogatóid ebből mennyit éreznek.

Melyik adat számít a Google rangsorolásában?

A Google a terepadatból származó Core Web Vitals mutatókat veszi figyelembe, a Lighthouse-pontszámot nem. Ez a jel ráadásul csak egy a sok rangsorolási tényező közül, és a tartalom relevanciáját nem írja felül.

Hivatalosan igazolt. A Google Search Central dokumentációja szerint a rangsorolási rendszerek használják a Core Web Vitals mutatókat, a Search Console Core Web Vitals jelentése pedig a CrUX terepadatára épül. Ugyanez a dokumentáció hangsúlyozza, hogy a jó oldalélmény egymagában nem juttat egy oldalt a találati lista élére, és a hasznos, releváns tartalom ennél többet nyom a latban. A Google a Lighthouse-pontszámot nem nevezi meg rangsorolási jelként. A Lighthouse fejlesztőknek készült, hogy laborkörülmények között megtalálják a hibát.

Szakmai feltételezés. A Core Web Vitals súlya a rangsorban jó eséllyel kicsi, és leginkább akkor számíthat, ha több oldal tartalmilag nagyjából egyformán jó választ ad ugyanarra a keresésre. Ezt a Google nem számszerűsíti, ezért senki nem tudja megmondani, hány helyet ér egy sárgából zöldbe fordított LCP.

Saját tapasztalat. A sebességjavítás hatása a felhasználói viselkedésben általában jobban látszik, mint a rangsorban. Egy lassú mobiloldal javítása után inkább a visszafordulási arány és az űrlapkitöltés mozdul, a helyezés ritkábban. Ezért a sebességet érdemes konverziós kérdésként is kezelni, nem csak SEO-feladatként.

Miért ingadozik a PageSpeed-pontszám mérésről mérésre?

A laborpontszám azért mozog, mert minden futás valódi hálózaton, valódi szerverről tölti le az oldalt, és ezeknek az apró eltéréseit a szimulált lassítás felnagyítja. A Lighthouse dokumentációja maga is normálisnak tekinti, hogy a futások eredménye eltér egymástól.

A leggyakoribb okok a következők.

• A szerver válaszideje futásonként más, főleg ha a gyorsítótár épp kiürült, vagy ugyanazon a tárhelyen más oldalak is terhelést okoznak.
• A harmadik féltől jövő elemek (hirdetés, chatablak, sütikezelő, analitika, videóbeágyazás) minden betöltéskor más sorrendben és más sebességgel érkeznek.
• A PageSpeed Insights mérőszervere a Google adatközpontjában fut, ezért a terhelése és a földrajzi helye is számít, és a CDN más csomópontról küldheti a fájlokat.
• A/B teszt vagy személyre szabott tartalom esetén nem mindig ugyanaz az oldalváltozat töltődik be.
• Helyi méréskor a böngészőbővítmények, a gép terheltsége és a többi nyitott lap is beleszól az eredménybe.

Saját tapasztalat. Mobilon gyakori az 5-10 pontos kilengés két egymás utáni futás között, a harmadik féltől származó szkriptekkel teli oldalakon ennél nagyobb is előfordul. Egyetlen futásból ezért nem érdemes következtetést levonni, és két fejlesztés hatását sem lehet így összehasonlítani.

Ha a laborszámmal dolgozol, futtasd le legalább ötször, és a mediánt nézd. A Lighthouse parancssori változatával ez egy rövid ciklussal megoldható.

for i in 1 2 3 4 5; do npx lighthouse https://www.pelda.hu/ --only-categories=performance --form-factor=mobile --output=json --output-path=./futas-$i.json --quiet --chrome-flags="--headless"; done

A JSON-fájlokból az egyes mutatók értékét is kiolvashatod, és ez többet ér a pontszámnál. Ha az LCP öt futásból négyszer 4 másodperc fölött van, az valódi jel, akkor is, ha a pontszám 55 és 68 között ugrál.

Mit jelent, ha egy kis forgalmú oldalnak nincs terepadata?

Azt jelenti, hogy az adott URL-re a CrUX nem gyűjtött elég látogatást ahhoz, hogy megbízható statisztikát közöljön. Ez nem hiba, egyszerűen kevesebbet tudsz a valós sebességről.

A CrUX csak nyilvános, indexelhető oldalakról közöl adatot, és csak akkor, ha a mintaméret átlép egy belső küszöböt, amelynek pontos értékét a Google nem hozza nyilvánosságra. Ilyenkor a PageSpeed Insights jelzi, hogy az oldalra nincs elég valós sebességadat, és ha az egész eredetre van, azt mutatja helyette. Ha az eredetre sincs, a terepadat-blokk üres marad. A Search Console Core Web Vitals jelentése a hasonló URL-eket csoportokba rendezi, és ahol a csoportra sincs elég adat, ott nem mutat semmit.

Szakmai feltételezés. Ha egy oldalra nincs saját terepadat, a Google valószínűleg a hasonló oldalak csoportjának vagy az egész eredetnek az adatára támaszkodik, ha az elérhető. Ha semmilyen adat nincs, a Core Web Vitals jó eséllyel nem játszik szerepet az oldal értékelésében. A Google ezt nem írja le részletesen, ezért kezeld óvatosan.

Kis forgalmú oldalnál a saját valós felhasználói mérés (RUM) segít. A Google által fejlesztett, nyílt forrású web-vitals JavaScript-könyvtárral pár sorban mérheted ugyanazt a három mutatót, és elküldheted a saját analitikádba, például a GA4-be.

import { onLCP, onINP, onCLS } from 'web-vitals'; function kuld(m) { gtag('event', m.name, { value: Math.round(m.name === 'CLS' ? m.value * 1000 : m.value), metric_id: m.id, non_interaction: true }); } onLCP(kuld); onINP(kuld); onCLS(kuld);

Ha ezeket az eseményeket néhány hétig gyűjtöd, az alacsony forgalmú oldalakról is lesz képed. Ezek az adatok a CrUX-be nem kerülnek be, a döntéshez viszont már elegendők. A 75. percentilist itt is érdemes nézni, hogy az eredmény összevethető legyen a Google küszöbeivel.

Hogyan olvasd az URL- és az eredetszintű adatot?

Az URL-szintű adat egyetlen konkrét oldal látogatásait mutatja, az eredetszintű a teljes webhely összes oldalát együtt. Az eredet átlaga elfedheti, hogy egy-egy fontos aloldal rossz.

Az eredet (origin) a protokoll, a hosztnév és a port együtt. A https://pelda.hu és a https://www.pelda.hu a CrUX szemében két külön eredet, ahogy egy shop.pelda.hu aldomain is. Ha a webhelyed a www nélküli címről a www-sre irányít át, a látogatások a célcímen kerülnek a mérésbe, ezért azt kérdezd le.

Az eredetszintű érték a látogatások szerint súlyozódik. A főoldal és a legnépszerűbb aloldalak tehát erősebben húzzák, mint egy ritkán látogatott termékoldal. Előfordul, hogy az eredet minden mutatója zöld, miközben a blog vagy a webshop kategóriaoldalai lassúak, mert ezek a forgalom kisebb részét adják. Fordítva is igaz, egy lassú, de népszerű főoldal lehúzhatja az egész webhely képét.

A mobil és az asztali adatot mindig külön kezeld. A PageSpeed Insights két fülön mutatja őket, a CrUX API-ban pedig a formFactor mezővel választasz. Az API-val az eredetszintű adat egyetlen kéréssel lekérhető.

curl -s -X POST 'https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KULCS' -H 'Content-Type: application/json' -d '{"origin": "https://www.pelda.hu", "formFactor": "PHONE"}'

Az origin helyett url kulccsal egy konkrét oldalra kérdezel. A válaszban a p75 érték a lényeg, ez ugyanazt jelenti, amit a PageSpeed Insights felső blokkja mutat. A CrUX Vis felületen ugyanez grafikonon, hónapokra visszamenőleg is látszik, így kiderül, hogy egy javítás után tényleg javult-e a trend.

Mikor érdemes laborpontszámért fejlesztési időt költeni, és mikor nem?

Akkor érdemes, ha a terepadat rossz vagy hiányzik, és a labor ugyanarra a mutatóra mutat. Ha a terepadat minden mutatója zöld, a pontszám emelése ritkán hoz annyit, amennyi munkát elvisz.

A döntést ebben a sorrendben érdemes meghozni.

1. Nézd meg a terepadatot mobilon. Előbb az URL-t, és ha arra nincs adat, az eredetet. A Search Console Core Web Vitals jelentésében azt is látod, mely URL-csoportok gyengék.
2. Ha mindhárom mutató jó, ne a pontszámot üldözd. A 70-ről 95-re emelt pontszám látványos, a látogatóid és a Google szempontjából viszont jó eséllyel alig változik tőle valami. Ilyenkor a fejlesztési időt érdemesebb tartalomra, belső linkekre vagy konverziós javításra fordítani.
3. Ha egy mutató sárga vagy piros, azt a mutatót javítsd. A labort ehhez diagnosztikára használd. LCP-gondnál a Lighthouse megmutatja az LCP-elemet és a késleltetés összetevőit, INP-gondnál a TBT-t és a hosszú feladatokat (long tasks), CLS-nél az elcsúszó elemeket.
4. Ha nincs terepadat, a pontszám helyett a labormutatókat nézd. Ha a medián LCP 2,5 másodperc körül vagy alatta van, a TBT 200 ezredmásodperc alatt, a CLS 0,1 alatt, akkor a pontszámtól függetlenül jó eséllyel nincs nagy baj. Mellé kapcsold be a saját valós mérést.
5. Új oldalnál vagy nagy átépítés előtt a labor az egyetlen forrásod. Itt megéri időt tenni bele, mert élesítés után 28 nap kell, amíg a terepadat teljesen az új állapotot tükrözi.

Szakmai feltételezés. A szabály egy mondatban így hangzik. Ha a terepadat jó, a laborpontszám csak tájékoztató szám, ha rossz vagy hiányzik, a labor diagnosztikája adja a munkalistát. Kivétel lehet, ha egy megrendelő vagy egy pályázat konkrét pontszámot ír elő, de az már üzleti elvárás, a keresőnek nincs köze hozzá.

Saját tapasztalat. A 90 fölötti mobilpontszámhoz gyakran olyan lépések kellenek, amelyek üzleti funkciót érintenek, például egy harmadik féltől jövő szkript elhagyása, a sütikezelő átépítése vagy a betűtípusok cseréje. Ilyenkor érdemes mérlegelni, mit veszítesz vele, mielőtt a pontszám kedvéért belevágsz.

Mit ellenőrizz, mielőtt sebességfejlesztést rendelsz?

Azt, hogy a probléma a valós felhasználóknál is megjelenik-e, és pontosan melyik mutatóban. Az alábbi lista segít, hogy ne a pontszámra, hanem a mért hibára készüljön a feladatleírás.

• Megnézted a mobil terepadatot URL-szinten, és ha arra nincs, eredetszinten.
• Tudod, melyik mutató bukik, és mennyivel van a küszöb fölött.
• A laborban legalább öt futás mediánját nézted, mindig ugyanazzal az eszközzel.
• A Lighthouse diagnosztikája ugyanarra a mutatóra mutat, mint a terepadat.
• A Search Console jelentéséből tudod, hány URL érintett.
• Kipróbáltad inkognitó módban, bővítmények nélkül, és megnézted, van-e olyan harmadik féltől jövő szkript, amely nélkül a hiba eltűnik.
• Javítás után a CrUX Vis vagy a Search Console trendjét követed, nem egyetlen újabb PageSpeed-futást.

Milyen félreolvasások vezetnek rossz döntéshez?

A leggyakoribb hiba, hogy valaki egyetlen laborfutást vet össze egy 28 napos terepadattal, vagy az asztali eredményt a mobillal. Néhány további csapda is gyakran előkerül.

• A javítás utáni napon a terepadat még alig változik, mert a 28 napos ablak nagy része a régi állapotot tükrözi.
• A Chrome fejlesztői eszközeiben futó Lighthouse a saját gépeden mér, ezért gyors gépen és jó neten jobb eredményt adhat, mint a PageSpeed Insights.
• A zöld eredet nem jelenti, hogy minden aloldal gyors.
• A 100 pontos laborpontszám mellett is lehet rossz az INP, mert a labor nem kattint az oldalon.
• A Lighthouse súlyozása verzióról verzióra módosulhat, ezért egy régi és egy új mérés pontszáma nem mindig vethető össze.

Források és további olvasnivalók

• Google Search Central, Az oldalélmény és a Google Kereső találatai
• Google Search Central, Core Web Vitals és a Google keresési eredményei
• Search Console súgó, Core Web Vitals jelentés
• web.dev, Web Vitals és a Core Web Vitals küszöbértékei
• Chrome for Developers, Lighthouse performance scoring
• Chrome for Developers, Lighthouse variability
• Chrome for Developers, Chrome UX Report módszertan és CrUX API dokumentáció
• W3C Web Performance Working Group, Largest Contentful Paint és Event Timing specifikáció