Rövid válasz: A Google PageSpeed Insights (PSI) egy ingyenes eszköz, ami megmutatja:
- valódi felhasználói adatok alapján (Field/CrUX), hogyan teljesít az oldalad az elmúlt ~28 napban, és
- szimulált tesztben (Lab/Lighthouse), milyen konkrét fejlesztésekkel gyorsítható a betöltés és a használhatóság.
A cél nem (csak) a „100-as pontszám”, hanem hogy a Core Web Vitals mutatók (LCP, INP, CLS) jó tartományba kerüljenek – különösen mobilon.
Tartalom
- Mire jó a PageSpeed Insights, és mikor érdemes használni?
- Hogyan indíts mérést lépésről lépésre?
- Field (CrUX) vs Lab (Lighthouse): mi a különbség és miért fontos?
- Core Web Vitals: melyik szám mit jelent, és mi számít „jónak”?
- A PSI jelentés fő részei – mit hol nézz?
- Optimalizálási teendők – a PSI „hibák” lefordítva a gyakorlatra
- WordPress gyors ellenőrzőlista (gyors, „80/20” megközelítés)
- Hogyan ellenőrizd, hogy a javítás tényleg segített?
- Gyakori kérdések (FAQ)
Mire jó a PageSpeed Insights, és mikor érdemes használni?
A PSI akkor hasznos, ha:
- mobilon lassúnak érződik az oldal,
- romlottak a Google Search Console Core Web Vitals státuszok,
- egy új sablon/bővítmény/builder frissítés után ellenőriznéd a hatást,
- konkrét, technikai teendőlistát szeretnél (képoptimalizálás, CSS/JS, szerver válaszidő, stb.).
Hogyan indíts mérést lépésről lépésre?
- Nyisd meg a pagespeed.web.dev oldalt.
- Illeszd be a vizsgálni kívánt URL-t (pl. kezdőlap vagy egy tipikus aloldal).
- Kattints az Analyze / Elemzés gombra.
- Nézd meg külön a Mobile és a Desktop fület (mobil általában szigorúbb és fontosabb).
- A jelentésben válaszd szét fejben:
- Discover what your real users are experiencing (Field/CrUX) = valós felhasználói élmény
- Diagnose performance issues (Lab/Lighthouse) = fejlesztési javaslatok szimulált mérésből
Field (CrUX) vs Lab (Lighthouse): mi a különbség és miért fontos?
Field data (CrUX) – „valós felhasználók”
- A PSI a Chrome UX Report (CrUX) adatait használja, ami valós Chrome felhasználói mérésekből származó, 28 napos gördülő időszakot összesítő adat.
- A megjelenített érték jellemzően a 75. percentilis (azaz a „rosszabbul járó” felhasználók felé húz).
- Előfordulhat, hogy nincs elég adat (különösen új/kevés látogatójú oldalaknál). Ilyenkor a Lab eredményekre kell támaszkodni.
Lab data (Lighthouse) – „szimulált teszt”
- A PSI a Lighthouse segítségével futtat szimulált mérést kontrollált környezetben, és ad konkrét optimalizálási javaslatokat.
- A Lighthouse pontszám értelmezése általánosan:
- 90–100: jó
- 50–89: fejlesztendő
- 0–49: gyenge
Core Web Vitals: melyik szám mit jelent, és mi számít „jónak”?
A Core Web Vitals 3 kulcsmutatója: LCP, INP, CLS. Ezeknél a cél, hogy a 75. percentilis „Good” legyen – ekkor a PSI szerint „átmegy” a CWV értékelésen.
LCP (Largest Contentful Paint)
- Mit mér? A legnagyobb látható tartalmi elem (pl. hero kép, nagy címsor blokk) megjelenésének idejét.
- „Jó” célérték: ≤ 2,5 s
- „Gyenge” tartomány: > 4,0 s
INP (Interaction to Next Paint)
- Mit mér? Interakció (kattintás/tap/billentyű) után mennyi idő alatt történik érdemi vizuális frissülés (reakció).
- „Jó” célérték: ≤ 200 ms
- „Gyenge” tartomány: > 500 ms
CLS (Cumulative Layout Shift)
- Mit mér? Betöltés közben mennyire „ugrál” az elrendezés (layout shift), mennyire stabil a tartalom.
- „Jó” célérték: ≤ 0,1
- „Gyenge” tartomány: > 0,25
Tipp: ha az INP rossz, az gyakran túl sok/nehéz JavaScriptre, rosszul kezelt animációkra, vagy „túlterhelt” builder megoldásokra utal.
A PSI jelentés fő részei – mit hol nézz?
1) „Discover what your real users are experiencing” (Field)
- Itt látod a Core Web Vitals státuszt és a valódi felhasználói mérőszámokat.
- A PSI a méréseket „Good / Needs improvement / Poor” sávokban is mutatja, és a 75. percentilist emeli ki.
2) „Diagnose performance issues” (Lab)
- Itt kapsz Lighthouse alapú pontszámot és metrikákat (pl. FCP, LCP, Speed Index, CLS, TBT, TTI).
- Alatta jönnek az Opportunities és Diagnostics típusú ajánlások.
Optimalizálási teendők – a PSI „hibák” lefordítva a gyakorlatra
Az alábbiak a leggyakoribb PSI javaslatok mögötti tipikus megoldások (különösen WordPressnél):
LCP javítása (betöltésérzet / „hero” tartalom)
Gyakori okok
- túl nagy hero kép / slider,
- render-blockoló CSS/JS,
- lassú szerver válasz (TTFB).
Mit csinálj
- Hero képet optimalizálj (méret, tömörítés, modern formátum), és ne legyen feleslegesen óriási.
- Csökkentsd a kezdeti CSS/JS terhelést (kritikus CSS, halasztott JS).
- Ellenőrizd a tárhely oldali válaszidőt és cache-t (oldalgyorsítótár, objektum cache – ha elérhető).
INP javítása (kattintás/űrlap/menü reakcióidő)
Gyakori okok
- túl sok JavaScript (builder, animációk, űrlapok, követőkódok),
- harmadik fél scriptek (chat, heatmap, reklám),
- nehéz DOM és túl sok widget.
Mit csinálj
- Kapcsold ki, amit nem használsz (bővítmény, modul, widget, tracking).
- Késleltesd/korlátozd a harmadik fél scripteket (csak ott töltődjenek, ahol kell).
- Egyszerűsítsd a layoutot (kevesebb mozgó elem, kevesebb beágyazás).
CLS javítása (elugráló tartalom)
Gyakori okok
- képek/videók méret nélkül,
- betűtípus késői betöltése,
- későn beérkező bannerek (cookie, akciós sáv).
Mit csinálj
- Adj fix méretet (width/height vagy arány) képeknek, videóknak, iframe-eknek.
- Font betöltés optimalizálása (kevesebb font, megfelelő preload – csak ha indokolt).
- Foglalj helyet a dinamikus elemeknek (banner/cookie sáv ne tolja szét a tartalmat).
Részletes fejlesztői megoldások: Google PageSpeed Insights – LCP/INP/CLS hibák javítása fejlesztői szinten
WordPress gyors ellenőrzőlista (gyors, „80/20” megközelítés)
- Frissítsd a WordPress magot, sablont, bővítményeket.
- Töröld a nem használt bővítményeket (nem csak kikapcsolni!).
- Képoptimalizálás: tömörítés + megfelelő méret (ne 4000 px-es képet tölts be 600 px helyett).
- Cache: legyen oldalgyorsítótár, és legyen ésszerű cache-invalidate.
- Minimalizáld a külső scripteket (chat, map, font, tracker) – ezek nagyon gyakran rontják az INP-t.
- Builder esetén: kerüld a slider/animáció túlhasználatát, és figyelj a DOM méretre.
Hogyan ellenőrizd, hogy a javítás tényleg segített?
- Végezd el a változtatást.
- Ürítsd az oldal cache-t (WordPress cache + szerver oldali cache, ha van).
- Futtasd újra a PSI tesztet (mobil + asztali).
- Ha Field (CrUX) adat is van: tudd, hogy az nem azonnal frissül, mert gördülő időszakot mutat.
- Kövesd a Search Console Core Web Vitals riportját is (mobil/desktop bontásban).
Gyakori kérdések (FAQ)
Miért más a mobil és az asztali eredmény?
A mobil mérés jellemzően szigorúbb (gyengébb hardver + hálózat), ezért gyakran rosszabb pontszámot és metrikákat ad.
Miért ugrál a pontszám, ha ugyanazt mérem?
A Lab mérés szimulált és több tényező befolyásolja. Érdemes több futtatást nézni, és inkább a tendenciát figyelni. A Field adat stabilabb, de lassabban reagál a változásokra.
Elég a 90+ Lighthouse pontszám?
Jó cél, de a lényeg, hogy a Core Web Vitals (LCP/INP/CLS) legyen jó – ezek állnak legközelebb a valós felhasználói élményhez.
Mit tegyek, ha nem boldogulok a javításokkal?
Ha szeretnéd, írd meg milyen CMS-t használsz (pl. WordPress + melyik builder), és melyik 2–3 hibát dobja a PSI – vagy nyithatsz hibajegyet is: https://ugyfeladmin.tarhely.eu/submitticket.php
