Leteszteltük. Miért ne higgy a Google PageSpeed Insightsnak?

Ha valaki nem webfejlesztő, hanem vállalkozóként weboldalt rendel, teljesen érthető, hogy egyszerű választ keres egy bonyolult kérdésre: jó és gyors lett-e a weboldalam? A PageSpeed Insights erre első pillantásra tökéletesnek tűnik. Beírunk egy URL-t, lefut a teszt, majd kapunk egy nagy, színes számot.

Innen már csak egy lépés az a hétköznapi következtetés, hogy 56 pont = rossz weboldal vagy rossz fejlesztő, 95 pont = jó weboldal és jó fejlesztő. Csakhogy a PageSpeed Insights hivatalos dokumentációja sem ezt állítja a számról.

A nagy Performance szám nem a weboldal „valós értéke”, és nem a fejlesztő szakmai osztályzata. Egy szimulált laborfutásból számított diagnosztikai pontszám.

1. Mit mér valójában a Google PageSpeed Insights?

A PageSpeed Insights két külön világot tesz egymás mellé: field data, vagyis valós felhasználói adatokat, valamint lab data, vagyis Lighthouse által előállított szimulált laboradatokat. A kettő célja nem ugyanaz.

A Google saját PageSpeed Insights dokumentációja ezt kifejezetten le is írja: a laboradat kontrollált környezetből származik, hibakeresésre hasznos, de nem feltétlenül fogja meg a valós felhasználói szűk keresztmetszeteket.

„A laboradat hasznos a hibák feltárására, mivel ellenőrzött környezetben gyűjtik. Ugyanakkor nem feltétlenül mutatja meg a valós felhasználói környezet szűk keresztmetszeteit.”
Google PageSpeed Insights – magyar fordítás az eredeti hivatalos szöveg alapján

Ez a mondat önmagában fontosabb, mint a nagy zöld vagy narancssárga kör. A Google nem azt mondja, hogy a laborpontszám a weboldal valós sebessége. Azt mondja, hogy a laboradat hibakeresésre jó.

2. Miért tűnik mégis úgy, mintha a Performance score lenne az igazság?

Mert a felület kommunikációja nagyon erős: egy nagy szám, egy szín és egy egyszerű kategória. A 90 fölötti pontszám zöld, az 50–89 közötti tartomány fejlesztendő, 50 alatt pedig piros. A laikus felhasználó ebből természetesen azt olvassa ki, hogy ez a weboldal végső osztályzata.

A Performance score azonban nem egyetlen fizikai mérés. A Lighthouse több nyers metrikát pontozási görbékre vetít, majd súlyozva összesít. A Chrome dokumentációja szerint ezért a weboldal teljesítményére hasznosabb értékek eloszlásaként gondolni, nem egyetlen számként.

A Lighthouse teljesítménypontozás hivatalos leírása azt is hangsúlyozza, hogy az összpontszám a mögöttes körülmények változásával ingadozhat.

„Hasznosabb lehet a webhely teljesítményére pontszámok eloszlásaként gondolni, nem pedig egyetlen számként.”
Chrome for Developers – Lighthouse Performance scoring, magyar fordítás

3. Leteszteltük ugyanazon release-en: mennyit változik a pontszám?

A Weboldal Bérlés fejlesztése közben két napon át követtük a PageSpeed eredményeket, majd külön automatizált monitorozást indítottunk. Az egyik mérési sorozatban ugyanazt a 1.0.430.105.81.18 release-t, ugyanazon a https://weboldal-berles.hu/ URL-en mértük újra és újra PageSpeed Insights API-val.

A cikkhez felhasznált adatbázis-pillanatképben a hosszabb monitorozásból az első 10 sikeres mobil és 10 sikeres desktop futás állt rendelkezésre, nagyjából 100 perces időablakban. A release a sorozaton belül nem változott.

Ugyanaz a publikus oldal, ugyanaz a release, mégis a mobil Performance score 57 és 98, a desktop pedig 55 és 77 között mozgott. Ha ezt egyetlen futás alapján nézzük, ugyanazt a fejlesztést egyszer majdnem tökéletesnek, máskor gyengének minősíthetnénk.

Ha egy release nem változott, de az összpontszám ilyen tartományban mozog, akkor az egyedi futás pontszáma nem kezelhető a weboldal állandó, „valós” sebességértékeként.

4. Nem csak a score változott: az LCP és főleg a TBT is nagy tartományban mozgott

A pontszám ingadozását a mögötte lévő labor metrikák változása magyarázza. A leglátványosabb eltérést a Total Blocking Time adta, de az LCP is több mint kétszeres tartományt járt be mobilon.

A CLS ezzel szemben meglehetősen stabil maradt, ami jól mutatja, hogy nem minden metrika zajos ugyanúgy. A laboradat tehát nem „véletlen szám”, hanem valós technikai jelzéseket tartalmaz – csak éppen egy adott futás eredménye nem általánosítható automatikusan minden felhasználóra és minden következő futásra.

5. Maga a Lighthouse is figyelmeztet: változhat a score kódmódosítás nélkül

A Lighthouse hivatalos Score Variability dokumentációja kifejezetten arra figyelmeztet, hogy a teljesítménypontszám a web és a hálózati technológiák természetes változékonysága miatt kódmódosítás nélkül is változhat.

„A Lighthouse teljesítménypontszámai a webes és hálózati technológiák természetes változékonysága miatt akkor is változhatnak, ha a kódban nem történt módosítás.”
GoogleChrome/Lighthouse – Score Variability, magyar fordítás

A dokumentáció több lehetséges forrást is felsorol: az oldal nem determinisztikus viselkedését, hálózati útvonalakat, webszerver-változékonyságot, kliens erőforrás-versenyt és a böngésző nem determinisztikus működését.

A PageSpeed Insights saját leírása pedig azt is közli, hogy a laborfutás Google adatközpontban történik, és a mérési hely Észak-Amerika, Európa vagy Ázsia lehet. A mobil teszt emulált eszköz- és hálózati környezetben fut. Ez nem hiba: éppen ez a laborvizsgálat lényege. Csak nem szabad összekeverni a valódi látogatói tapasztalattal.

6. Mit mutat közben a saját RUM? Valódi böngészők, valódi látogatások

A Weboldal Bérlés rendszerében ezért nem csak laboradatot nézünk. Saját Real User Monitoring (RUM) réteg gyűjti a tényleges böngészőkből érkező Web Vitals értékeket. Ezeknél nem egy emulált telefon próbálja megjósolni, mit érezhet egy látogató: a mérés a valódi látogatásból érkezik.

A Google web.dev dokumentációjának megfogalmazása tömör: a Core Web Vitals metrikákat a legjobb field környezetben mérni.

„A Core Web Vitals mutatókat a legjobb valós felhasználói környezetben mérni.”
web.dev – Core Web Vitals workflows with Google tools, magyar fordítás

A következő értékek a Weboldal Bérlés főoldalának saját RUM méréseiből származnak. A fejlesztés ezekben a napokban aktív volt, ezért ez nem ugyanazon release kontrollált összehasonlítása; arra az előző PageSpeed sorozat szolgál. Itt azt mutatjuk meg, hogy a valós felhasználói mérés milyen adatot ad.

* A 2026.09.05-i RUM sor a mentés időpontjában még kis mintaszámú, ezért ebből önmagában nem vonunk le hosszú távú következtetést.

A saját RUM előnye, hogy release, eszköztípus, oldal, metrika és más attribúciók szerint is vizsgálható. A Google maga is azt javasolja, hogy a CrUX mellett érdemes saját RUM-ot gyűjteni, mert az részletesebb és gyorsabb visszajelzést adhat a saját oldal teljesítményéről.

A web.dev saját RUM gyűjtést javasló útmutatója külön kiemeli, hogy a saját RUM részletesebb és közvetlenebb visszajelzést adhat, mint a hosszabb időablakú aggregált források.

7. PageSpeed vs. saját RUM: ugyanazokat a számokat kellene látnunk? Nem.

Gyakori félreértés, hogy a PageSpeed labor LCP-jének és a saját RUM LCP-jének ugyanannyinak kell lennie. Nem kell. Az egyik egy meghatározott szimuláció, a másik sok valódi böngészőből érkező eloszlás.

Ez a táblázat szándékosan nem „RUM nyert, PageSpeed vesztett” rangsor. A két adathalmaz nem ugyanazt a kérdést teszi fel. Éppen ez a lényeg: a laborfutásból kapott Performance score-t nem szabad a valós látogatói teljesítmény helyettesítőjeként használni.

8. LCP, CLS, TBT, INP – mit kell valójában nézni?

9. TBT nem egyenlő INP-vel

Ez különösen fontos, mert a PageSpeed jelentésben a TBT erősen befolyásolhatja a Performance score-t, miközben a Core Web Vitals interaktivitási metrikája ma az INP. A kettő között van kapcsolat, de nem csereszabatosak.

A web.dev hivatalos TBT dokumentációja szerint a TBT ésszerű labor proxy lehet az INP problémák jelzésére, de nem helyettesíti az INP-t. A dokumentáció azt is javasolja, hogy a tényleges válaszkészségi problémákat INP-vel, field környezetben mérjük.

Egy 4 másodperces labor TBT nem azt jelenti, hogy a valós felhasználók INP-je is 4 másodperc.

10. Fejlesztőként mire jó akkor a PageSpeed Insights?

Sokat ér – ha arra használjuk, amire való. A PageSpeed és a Lighthouse nagyon jó diagnosztikai eszköz lehet render-blocking erőforrások, túl nagy JavaScript-terhelés, hosszú taskok, hibás LCP-prioritás, nagy képek, felesleges hálózati kérések és más technikai problémák felderítésére.

Amit viszont nem érdemes csinálni:

• egyetlen PageSpeed futás alapján release-t visszavonni;
• egy 89 → 78 változás miatt automatikusan kódot átírni;
• a 100-as score kedvéért működő funkciókat késleltetni vagy rontani;
• a TBT-t valós INP-ként kezelni;
• a Performance score-t ügyfél vagy fejlesztő minősítésére használni.

Amit helyette érdemes:

• azonos release-en több Lighthouse / PageSpeed futást végezni;
• legalább mediánt és tartományt nézni, nem egyetlen pontszámot;
• a konkrét LCP, CLS, TBT és trace problémákat vizsgálni;
• release előtt és után RUM p75 LCP/INP/CLS trendet összevetni;
• csak reprodukálható technikai vagy valós felhasználói regresszióra fejleszteni.

A Lighthouse CI saját dokumentációja is több futást támogat kifejezetten azért, hogy a természetes ingadozást csökkentse. Vagyis még a Lighthouse ökoszisztémán belül sem az az ajánlott fejlesztői módszer, hogy egyetlen szám alapján hozzunk döntést.

11. És felhasználóként hogyan lehet megítélni egy weboldal teljesítményét?

Ha vállalkozóként weboldalt rendelsz, a PageSpeed score lehet egy gyors ellenőrzési pont, de ne ez legyen az egyetlen kérdés. Sokkal többet mond, hogy a weboldal valódi látogatóknál stabilan gyors-e, mobilon használható-e, nem ugrál-e a felület, gyorsan reagál-e a kattintásokra, és a fejlesztő képes-e ezeket adatokkal alátámasztani.

12. A mi következtetésünk: ne a számot kergessük, hanem a problémát

A két napos vizsgálat és az automatizált ismételt mérés után a következtetésünk nem az, hogy a Google PageSpeed Insights „rossz”. A következtetés az, hogy rosszul használjuk, ha a nagy Performance számot a weboldal valós sebességének vagy a fejlesztő minőségének tekintjük.

Fejlesztőként a PageSpeed Insights nálunk továbbra is megmarad diagnosztikai eszköznek. Megnézzük, mit jelez, keresünk reprodukálható problémát, és több futásból dolgozunk. De a valódi visszacsatolást a saját RUM, a p75 LCP/INP/CLS, a release-ek szerinti trend és a tényleges felhasználói működés adja.

Nem a 95-ös zöld karikát akarjuk megnyerni. Azt akarjuk, hogy a weboldal valódi embereknél legyen gyors, stabil és használható.

Ez a különbség a pontszám-optimalizálás és a teljesítményfejlesztés között.

Egy mondatban

A PageSpeed Insights Performance score hasznos laborjelzés, de nem valós felhasználói sebességmérés; a tényleges weboldal-élményt field/RUM adatokkal, Core Web Vitals trendekkel és reprodukálható diagnosztikával érdemes megítélni.