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

> A Google PageSpeed Insights néhány másodperc alatt ad egy látványos, 0–100 közötti Performance pontszámot. Laikusként könnyű ezt a weboldal és a fejlesztő osztályzatának tekinteni. Mi két napon át vizsgáltuk a saját rendszerünkön, majd ugyanazt a release-t ismételten, automatizáltan mértük. Az eredmény: ugyanazon kód mellett is jelentősen eltérő laborpontszámokat kaptunk. Megmutatjuk, mit mér valójában a PageSpeed Insights, mit mond erről maga a Google, és miért a valós felhasználói RUM adatokból érdemes kiindulni.

- **Eredeti HTML oldal:** [https://weboldal-berles.hu/blog/leteszteltuk-miert-ne-higgy-a-google-pagespeed-insightsnak](https://weboldal-berles.hu/blog/leteszteltuk-miert-ne-higgy-a-google-pagespeed-insightsnak)
- **AI tartalmi térkép:** [llms.txt](https://weboldal-berles.hu/llms.txt)

- **Megjelenés:** 2026-09-05
- **Kategória:** Weboldal bérlés
- **Szerző:** Szabó Balázs
- **Címkék:** Core Web Vitals, LCP, Lighthouse, PageSpeed Insights, RUM, webfejlesztés, weboldal bérlés, weboldal teljesítmény

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.

| Adattípus | Honnan jön? | Mire jó? | Mit nem jelent? |
| --- | --- | --- | --- |
| **CrUX / field data** | Valódi Chrome-felhasználók összesített tapasztalata, megfelelő mintaszám esetén | Valós felhasználói Core Web Vitals állapot és trend | Nem ad részletes kódszintű hibakeresést |
| **Lighthouse / lab data** | Szimulált mobil vagy desktop környezetben lefuttatott egyedi teszt | Diagnosztika, reprodukálható problémafeltárás, technikai javaslatok | Nem azonos a látogatók tényleges élményével |
| **Performance score** | A Lighthouse több metrikából számított, súlyozott 0–100 pontszáma | Gyors laboratóriumi összefoglaló és viszonyítási jel | Nem teljes weboldal-minősítés és nem fejlesztői rangsor |

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](https://developers.google.com/speed/docs/insights/v5/about).

> „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](https://developer.chrome.com/docs/lighthouse/performance/performance-scoring) 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.

| Futás | Idő | Desktop score | Mobil score |
| --- | --- | --- | --- |
| 1. | 21:34–21:35 | **66** | **98** |
| 2. | 21:44–21:45 | **55** | **80** |
| 3. | 21:57–22:00 | **76** | **57** |
| 4. | 22:07–22:08 | **61** | **75** |
| 5. | 22:18–22:19 | **58** | **65** |
| 6. | 22:26–22:27 | **59** | **79** |
| 7. | 22:35–22:36 | **77** | **93** |
| 8. | 22:45–22:46 | **61** | **66** |
| 9. | 22:55–22:56 | **76** | **90** |
| 10. | 23:05–23:07 | **61** | **83** |

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.

| Metrika | Mobil – minimum | Mobil – medián | Mobil – maximum | Desktop – minimum | Desktop – medián | Desktop – maximum |
| --- | --- | --- | --- | --- | --- | --- |
| **Performance score** | 57 | 79,5 | 98 | 55 | 61 | 77 |
| **LCP** | 1,552 s | 1,916 s | 3,077 s | 0,642 s | 1,198 s | 1,595 s |
| **TBT** | 143 ms | 728 ms | 4627 ms | 489 ms | 1518 ms | 3574 ms |
| **CLS** | 0,0000 | 0,0046 | 0,0046 | 0,0372 | 0,0384 | 0,0405 |

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](https://github.com/GoogleChrome/lighthouse/blob/main/docs/variability.md) 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](https://web.dev/articles/vitals-tools).

> „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.

| Dátum | Mobil LCP p75 | Mobil INP p75 | Mobil CLS p75 | LCP minták | INP minták | CLS minták |
| --- | --- | --- | --- | --- | --- | --- |
| 2026.09.03. | **513 ms** | **152 ms** | **0,0004** | 44 | 21 | 42 |
| 2026.09.04. | **554 ms** | **136 ms** | **0,0015** | 44 | 41 | 40 |
| 2026.09.05.* | **655 ms** | **126 ms** | **0,0004** | 7 | 6 | 6 |

* 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](https://web.dev/articles/vitals-measurement-getting-started) 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.

| Metrika / nézőpont | Saját RUM – mobil p75, 2026.09.03–04. | PageSpeed monitor – mobil p75, azonos release 10 futás | Hogyan értelmezzük? |
| --- | --- | --- | --- |
| **LCP** | **537 ms** (88 minta) | **2760 ms** (10 futás) | Ugyanaz a metrika, de teljesen eltérő környezet és populáció |
| **CLS** | **0,0007** (82 minta) | **0,0046** (10 futás) | Mindkettő stabilitást mér, de más körülmények között |
| **Interaktivitás** | **INP 150 ms** (62 minta) | **TBT 1231 ms** | Nem ugyanaz a metrika; a TBT csak labor proxyként használható |
| **FCP** | **506 ms** (87 minta) | **1954 ms** (10 futás) | A field és lab indulási körülménye eltér |
| **TTFB** | **335 ms** (90 minta) | A mentett monitor-összesítőben nincs összevethető TTFB | A szerverválasz RUM-ban közvetlenül követhető |

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?**

| Metrika | Mit mér? | Hol érdemes nézni? | Fejlesztői értelmezés |
| --- | --- | --- | --- |
| **LCP** | A legnagyobb jelentős tartalmi elem megjelenésének idejét | RUM p75 + labor diagnosztika | Hero kép, font, szerver, preload, renderelés és főszál is hathat rá |
| **CLS** | Váratlan elrendezés-eltolódások összességét | Elsősorban RUM p75, mellette labor | Képméretek, fontcsere, későn megjelenő elemek, sticky UI okozhatja |
| **INP** | Valós felhasználói interakciók válaszkészségét | Field / RUM | A valódi kattintások és interakciók késleltetését mutatja |
| **TBT** | A laborfutás főszál-blokkolását | Lighthouse labor | Hasznos jelző JavaScript- és főszál-problémákhoz, de nem azonos az INP-vel |
| **FCP** | Az első tartalom megjelenését | RUM és labor | Jó korai jel, de önmagában nem mondja meg, mikor lett használható a fő tartalom |
| **TTFB** | Az első byte megérkezéséig eltelt időt | RUM és szerveroldali mérés | Szerver, cache, hálózat és backend hatása is megjelenik benne |
| **Performance score** | Lighthouse-metrikák súlyozott pontszámát | Labor összefoglalóként | Jelzőszám; nem külön webes fizikai metrika és nem valós felhasználói KPI |

## **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](https://web.dev/articles/tbt). 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.

| Kérdés | Miért fontosabb egyetlen Performance score-nál? |
| --- | --- |
| **Van valós RUM / Core Web Vitals mérés?** | A tényleges látogatói élményt mutatja, nem egyetlen szimulációt. |
| **p75 LCP, INP és CLS rendben van?** | Ezek a Core Web Vitals felhasználóközpontú mutatói. |
| **Stabilak a trendek release után?** | Megmutatja, hogy a fejlesztés valóban javított vagy rontott. |
| **Mobilon ténylegesen jól használható?** | A használhatóság nem fér bele egyetlen laborpontszámba. |
| **Funkcionálisan stabil a weboldal?** | A 100-as score sem ér sokat, ha a menü, űrlap vagy vásárlási folyamat hibás. |
| **Van diagnosztika és visszamérés?** | A jó fejlesztési folyamat mér, értelmez, majd ellenőriz – nem csak pontszámot hajszol. |

## **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.

| [Performance és RUM a motorháztető alatt](https://weboldal-berles.hu/blog/mi-van-a-motorhazteto-alatt-weboldal-teljesitmeny-core-web-vitals-rum) | [Valós Weboldal Vitalitás adatok](https://weboldal-berles.hu/weboldal-vitalitas) |
| --- | --- |