A lecke végére el tudod különíteni a mért és az érzékelt teljesítményt, ismered a Core Web Vitals három mutatóját (LCP, INP, CLS) és a „jó” küszöbértékeket, és egy mérés eredményéből meg tudod mondani, mely beavatkozás javít a legtöbbet.
Mit jelent az, hogy „gyors”?
Képzeljünk el két webáruházat. Az első azonnal kirajzol egy látványos, de még üresnek ható felületet: a betűk, a termékképek és a kosár gombja csak később érkeznek meg. A második nem mutat minden díszítőelemet azonnal, viszont egy pillanat alatt megjelenik a keresett termék neve, ára és egy működő „Kosárba” gomb. Lehetséges, hogy az első oldal egy technikai mérték szerint rövidebb idő alatt „befejezi” a betöltést, mégis a második tűnik gyorsabbnak. A felhasználó ugyanis nem egy hálózati naplót él át, hanem egy feladat elvégzését.
Ezért különítjük el a mért teljesítményt (időtartamok, méretek, processzorhasználat, böngészőesemények) és az érzékelt teljesítményt (mikor érzi a látogató, hogy az oldal használható, a kattintására válaszolt, és nem ugrik el alatta a tartalom). A kettő kapcsolódik, de nem azonos. A 3.3 lecke szerint a „betöltött” állapot nem egyetlen pillanat; itt azt vizsgáljuk, mely mérőszámok mennyire közelítik a felhasználói élményt.
Egy oldal sebességét több szakasz alakítja: a névfeloldás, a kapcsolat, a dokumentum lekérése (4. fejezet), a további erőforrások letöltése, majd az eszköz feldolgozása: DOM, elrendezés, kirajzolás és a JavaScript futtatása (3.3). Egy gyenge telefonon ugyanaz a JavaScript sokkal tovább tarthat, mint egy fejlesztő laptopján.
flowchart LR
N[Hálózat és szerver] --> L[LCP: a fő tartalom megjelenése]
J[JavaScript-terhelés] --> I[INP: reakció a műveletre]
M[Méretezetlen média] --> C[CLS: az elrendezés ugrálása]
L --> E[Felhasználói élmény]
I --> E
C --> E
Core Web Vitals: három nézőpont
A Core Web Vitals olyan, széles körben használt mutatók együttese, amelyek a betöltés, az interakció és a vizuális stabilitás oldaláról közelítik a felhasználói élményt. A web.dev szerinti „jó” küszöbök:
Mutató
Mit mér?
„Jó” érték
LCP (Largest Contentful Paint)
Mikor jelenik meg a legnagyobb látható tartalmi elem (főcím, főkép, nagy szövegblokk)?
legfeljebb 2,5 másodperc
INP (Interaction to Next Paint)
Egy felhasználói művelet (kattintás, érintés, billentyű) után mennyi idő telik a következő látható visszajelzésig?
legfeljebb 200 ezredmásodperc
CLS (Cumulative Layout Shift)
Mennyire ugrál váratlanul az elrendezés?
legfeljebb 0,1
A web.dev azt javasolja, hogy az értékelést a lapbetöltések 75. percentilisén végezzük, mobilra és asztali gépre külön: az oldal akkor felel meg, ha mindhárom mutató eléri a célt ezen a percentilisen. (A percentilis az az érték, amely alatt a mérések 75 százaléka van, vagyis a lassabbik negyedet nem tekintjük kivételnek.) Az INP 2024-ben vált stabil Core Web Vital-lá, és a korábbi FID (First Input Delay) mutatót váltotta.
A mutatók nem teljes minősítések: nem mondják meg, hogy az oldal akadálymentes-e, érthető-e, vagy jogszerűen kezel-e adatot. Viszont segítenek észrevenni néhány nagyon gyakori, bosszantó problémát.
LCP: a fő tartalom megérkezése
Az LCP a látogató számára az a pillanat, amikor az oldal fő mondanivalója megérkezik. Ha a nyitókép túl nagy, rossz formátumú, későn kezd letöltődni, vagy a szerver lassan küldi a HTML-t, az LCP romlik. Nem az a következtetés, hogy „minden képet el kell hagyni”, hanem hogy a képet a megfelelő méretben, formátumban és prioritással kell szállítani (3.4, 9.3). Egy apró ikon optimalizálása keveset segít, ha a fő termékkép 8 megabájtos.
INP: a művelet utáni visszajelzés
Ha a „Fizetés” gombra kattintva hosszú ideig semmi nem történik, a felhasználó újra megnyomhatja, azt hiheti, hibázott, vagy elhagyhatja az oldalt. Az INP nem kizárólag hálózati válaszidő: sok esetben azért rossz, mert a böngésző éppen nagy mennyiségű JavaScriptet dolgoz fel, és egy hosszú feladat elfoglalja a fő szálat, ezért a kattintás feldolgozása várakozik. Jó elv: a felület adjon egyértelmű, azonnali visszajelzést (betöltési állapot, letiltott gomb), és a költséges munkát osszuk kisebb részekre.
CLS: a váratlan ugrás
Mindenki találkozott már azzal, hogy éppen megérint egy linket, amikor egy későn betöltődő kép lejjebb tolja a tartalmat, és a kattintás egy másik elemre esik. Tipikus ok, hogy a képnek vagy beágyazott tartalomnak nincs előre lefoglalt helye. A megoldás a méret megadása (width és height, 3.3) és a dinamikus elemek számára fenntartott hely. A felhasználó műveletére szándékosan megjelenő tartalom (például egy kibontott menü) természetesen változtathatja az elrendezést; a gond a váratlan változás.
Laborban kipróbálva: ugyanaz az oldal rosszul és jól
A 9.2 leckében már használt két oldalt (egy szándékosan hibás és egy javított kurzusoldalt) a Lighthouse 13.5.0-s verziójával, Chrome 154 böngészőben, szimulált mobil környezetben (Lighthouse alapértelmezett lassított hálózat és processzor) mértük. A kiszolgáló mesterségesen késleltette a stíluslapot (0,9 s), a JavaScriptet (0,6 s) és a nagy képet (0,4 s). A hibás oldal egy 1,35 megabájtos képet töltött be méret nélkül, a JavaScript 0,4 s-ig blokkolta a szálat, és egy banner 1,5 s után szúródott be az oldal tetejére. A javított oldal 150 kilobájtos, méretezett képet használt, a stílusokat beágyazva kapta, a JavaScript pedig defer-rel és rövid volt.
Mutató
Hibás oldal
Javított oldal
Jó küszöb
Teljesítmény-pontszám (0–100)
68
100
–
First Contentful Paint (FCP, az első tartalom)
3,3 s
0,8 s
–
LCP
8,5 s
1,8 s
≤ 2,5 s
Total Blocking Time (TBT)
0 ms
0 ms
–
CLS
0,019
0
≤ 0,1
Speed Index
3,9 s
0,8 s
–
(A Lighthouse labormérés: egyetlen betöltés, szimulált környezet. Az INP-t nem méri, mert ahhoz tényleges felhasználói művelet kell; a laborban a TBT, a betöltés alatti főszál-blokkolás közelíti, a web.dev szerint az INP-t.)
Mit olvashatunk ki ebből?
Az LCP a fő probléma: 8,5 s, a küszöb több mint háromszorosa. A Lighthouse két fő okot jelzett: a renderelést blokkoló kérések (a késleltetett stíluslap és a szkript; becsült megtakarítás 2 260 ms) és a képkézbesítés (becsült megtakarítás 1 246 KiB, vagyis a túl nagy kép).
A CLS itt kicsi (0,019), a „jó” küszöbön belül. A beszúródó banner látható volt, de a mért elmozdulás kicsi maradt; a CLS-t tehát nem érdemes „érzésre” megítélni, hanem mérni kell. A Lighthouse viszont a méret nélküli képet (unsized-images) külön hibaként jelezte, mert ez a későbbi elmozdulás kockázata.
A TBT mindkét oldalon 0 ms, annak ellenére, hogy a hibás oldal JavaScriptje 0,4 s-ig foglalta a szálat. A blokkolás ugyanis az első tartalom előtt történt (a parser blokkoló szkript miatt), a TBT viszont az első tartalom utáni blokkolást számolja. Ez jó példa arra, hogy egyetlen mutató nem mutat mindent: a blokkoló szkript az FCP-ben és az LCP-ben látszik.
A javítás nem a mutatók kozmetikázása: a kisebb kép, a beágyazott stílus és a defer pontosan azok a lépések, amelyek a felhasználónak is gyorsabb, stabilabb élményt adnak (3.4).
A Lighthouse a javított oldalon is jelzett egy konzolhibát: a böngésző favicon.ico-t kért, és 404-et kapott. A teljesítményt ez nem érinti, de a „bevált gyakorlatok” pontszámát 92-re csökkentette. A mérés minden részlete a környezettől függ, ezért az eredményeket összehasonlításra, nem abszolút igazságnak kell tekinteni.
Késleltetés: nem csak a fájlméret számít
A késleltetés (4.6) az az idő, amely egy kérés elindítása és a válasz megérkezése között eltelik. Egy kis méretű válasz is lehet lassú, ha a szerver csak sok idő után kezd válaszolni; egy nagyobb kép is elfogadhatóan érkezhet, ha közelről, gyors hálózaton és jól szervezett letöltéssel szolgálják ki. Hasznos külön gondolni a válasz első bájtjára (4.2: TTFB) és a teljes válaszra: ha a szerver az adatbázisra vár, a böngésző sokáig nem kap semmit, a látogató üres képernyőt lát. A hálózat mellett az oldalon futó sok, nagy vagy rosszul ütemezett szkript is lefoglalhatja a böngésző főszálát, ilyenkor a fájlok akár le is töltődhettek, de a felület nem reagál. A „megabájtok száma” ezért nem elég.
Képek, JavaScript és gyorsítótár
Képek: gyakran a letöltött adat nagy részét adják. A feleslegesen nagy felbontás, a gyenge tömörítés, vagy ha a telefon az asztali gépre szánt óriásképet kapja, mind rontja az LCP-t. A böngészőnek több változat is adható (9.3). A fő képet nem szabad késleltetni, a lap alján lévő galériát viszont igen (3.4).
JavaScript: gazdag interakciót ad, de a letöltése, feldolgozása és futása terhelés. Egy külső mérőkód, chat-ablak, hirdetési rendszer mind növelheti a költséget. A kérdés nem az, hogy szabad-e JavaScriptet használni, hanem hogy minden kód szolgál-e valós felhasználói célt, és mikor kell betölteni.
Gyorsítótár: a korábban letöltött, még érvényes erőforrások újrafelhasználása csökkenti a várakozást. A részleteket (HTTP-gyorsítótár, CDN) a 10. fejezet tárgyalja.
Mit és hogyan mérjünk?
A böngésző fejlesztői eszközeinek hálózati nézete megmutatja, melyik kérés mennyi ideig tartott, mekkora volt a válasz, gyorsítótárból érkezett-e. A teljesítményprofil megmutatja, ha egy hosszú JavaScript-feladat blokkolja a felületet. Ezeket nem értelmezhetjük elszigetelten: mindig tegyük fel a kérdést, melyik felhasználói feladat sérül, és melyik változtatás javítana rajta a legtöbbet.
Végigvezetett példa: a Kurzuspont jelentkezési oldala
A Kurzuspont jelentkezési oldalán a hallgatók azt panaszolják, hogy nyitáskor „lassú”. A csapat a következő sorrendben dolgozik: (1) laborban méri az LCP-t, a TBT-t és a CLS-t, a valós adatokban pedig az INP-t is; (2) megnézi, mi az LCP-elem (a kurzus fényképe); (3) a képet megfelelő méretben adja, a stílust a kritikus részre szűkíti, a szkriptet defer-rel tölti; (4) a Jelentkezem gombra azonnali visszajelzést ad (letiltott állapot, „Küldés...”); (5) ellenőrzi a valós adatokat a 75. percentilisen. A siker mércéje nem a pontszám, hanem az, hogy a hallgató gyorsan megtalálja és biztonsággal használja a jelentkezést.
Gyakori tévhitek
Állítás
Pontosítás
„A teljesítmény csak a szerver dolga.”
A képek, a böngészőoldali kód, a betűkészletek és a harmadik féltől származó elemek is döntőek.
„A gyors interneten minden oldal gyors.”
A kapcsolat sebessége nem oldja meg a lassú szerverválaszt, a túl sok kérést vagy a blokkoló JavaScriptet.
„A jó Core Web Vitals érték = jó webhely.”
Csak néhány dimenzióról ad jelzést; a használhatóságot és az akadálymentességet nem vizsgálja.
„A 100 pontos Lighthouse-eredmény a valódi felhasználóknál is 100.”
Labormérés: a valós eszközök és hálózatok eltérőek.
„Mindent gyorsítótárazni kell.”
A hibás szabály régi vagy más felhasználónak szóló tartalmat szolgálhat ki (10. fejezet).
Röviden
A teljesítmény a felhasználó élménye (érzékelt), nem csak időtartamok (mért).
Core Web Vitals: LCP (≤ 2,5 s), INP (≤ 200 ms), CLS (≤ 0,1), a 75. percentilisen értékelve.
A laboratóriumi mérés összehasonlításra jó, a valós mezőadat a tényleges hatást mutatja.
A kipróbált hibás oldalon a nagy kép és a renderelést blokkoló kérések okozták a 8,5 s-os LCP-t; a javítás 1,8 s-ra csökkentette.
Egyetlen mutató sem mutat mindent (a TBT itt 0 volt a blokkoló szkript ellenére).
Ellenőrző kérdések
Mi a különbség a mért és az érzékelt teljesítmény között?
Mit mér az LCP, az INP és a CLS, és mi a „jó” küszöbük?
Miért volt 0 a TBT a hibás oldalon, miközben a szkript blokkolta a szálat?
Miért nem elég egyetlen laborméréssel értékelni egy oldalt?
Felhasználói szempontú teljesítmény
Célok
A lecke végére el tudod különíteni a mért és az érzékelt teljesítményt, ismered a Core Web Vitals három mutatóját (LCP, INP, CLS) és a „jó” küszöbértékeket, és egy mérés eredményéből meg tudod mondani, mely beavatkozás javít a legtöbbet.
Mit jelent az, hogy „gyors”?
Képzeljünk el két webáruházat. Az első azonnal kirajzol egy látványos, de még üresnek ható felületet: a betűk, a termékképek és a kosár gombja csak később érkeznek meg. A második nem mutat minden díszítőelemet azonnal, viszont egy pillanat alatt megjelenik a keresett termék neve, ára és egy működő „Kosárba” gomb. Lehetséges, hogy az első oldal egy technikai mérték szerint rövidebb idő alatt „befejezi” a betöltést, mégis a második tűnik gyorsabbnak. A felhasználó ugyanis nem egy hálózati naplót él át, hanem egy feladat elvégzését.
Ezért különítjük el a mért teljesítményt (időtartamok, méretek, processzorhasználat, böngészőesemények) és az érzékelt teljesítményt (mikor érzi a látogató, hogy az oldal használható, a kattintására válaszolt, és nem ugrik el alatta a tartalom). A kettő kapcsolódik, de nem azonos. A 3.3 lecke szerint a „betöltött” állapot nem egyetlen pillanat; itt azt vizsgáljuk, mely mérőszámok mennyire közelítik a felhasználói élményt.
Egy oldal sebességét több szakasz alakítja: a névfeloldás, a kapcsolat, a dokumentum lekérése (4. fejezet), a további erőforrások letöltése, majd az eszköz feldolgozása: DOM, elrendezés, kirajzolás és a JavaScript futtatása (3.3). Egy gyenge telefonon ugyanaz a JavaScript sokkal tovább tarthat, mint egy fejlesztő laptopján.
flowchart LR N[Hálózat és szerver] --> L[LCP: a fő tartalom megjelenése] J[JavaScript-terhelés] --> I[INP: reakció a műveletre] M[Méretezetlen média] --> C[CLS: az elrendezés ugrálása] L --> E[Felhasználói élmény] I --> E C --> ECore Web Vitals: három nézőpont
A Core Web Vitals olyan, széles körben használt mutatók együttese, amelyek a betöltés, az interakció és a vizuális stabilitás oldaláról közelítik a felhasználói élményt. A web.dev szerinti „jó” küszöbök:
A web.dev azt javasolja, hogy az értékelést a lapbetöltések 75. percentilisén végezzük, mobilra és asztali gépre külön: az oldal akkor felel meg, ha mindhárom mutató eléri a célt ezen a percentilisen. (A percentilis az az érték, amely alatt a mérések 75 százaléka van, vagyis a lassabbik negyedet nem tekintjük kivételnek.) Az INP 2024-ben vált stabil Core Web Vital-lá, és a korábbi FID (First Input Delay) mutatót váltotta.
A mutatók nem teljes minősítések: nem mondják meg, hogy az oldal akadálymentes-e, érthető-e, vagy jogszerűen kezel-e adatot. Viszont segítenek észrevenni néhány nagyon gyakori, bosszantó problémát.
LCP: a fő tartalom megérkezése
Az LCP a látogató számára az a pillanat, amikor az oldal fő mondanivalója megérkezik. Ha a nyitókép túl nagy, rossz formátumú, későn kezd letöltődni, vagy a szerver lassan küldi a HTML-t, az LCP romlik. Nem az a következtetés, hogy „minden képet el kell hagyni”, hanem hogy a képet a megfelelő méretben, formátumban és prioritással kell szállítani (3.4, 9.3). Egy apró ikon optimalizálása keveset segít, ha a fő termékkép 8 megabájtos.
INP: a művelet utáni visszajelzés
Ha a „Fizetés” gombra kattintva hosszú ideig semmi nem történik, a felhasználó újra megnyomhatja, azt hiheti, hibázott, vagy elhagyhatja az oldalt. Az INP nem kizárólag hálózati válaszidő: sok esetben azért rossz, mert a böngésző éppen nagy mennyiségű JavaScriptet dolgoz fel, és egy hosszú feladat elfoglalja a fő szálat, ezért a kattintás feldolgozása várakozik. Jó elv: a felület adjon egyértelmű, azonnali visszajelzést (betöltési állapot, letiltott gomb), és a költséges munkát osszuk kisebb részekre.
CLS: a váratlan ugrás
Mindenki találkozott már azzal, hogy éppen megérint egy linket, amikor egy későn betöltődő kép lejjebb tolja a tartalmat, és a kattintás egy másik elemre esik. Tipikus ok, hogy a képnek vagy beágyazott tartalomnak nincs előre lefoglalt helye. A megoldás a méret megadása (
widthésheight, 3.3) és a dinamikus elemek számára fenntartott hely. A felhasználó műveletére szándékosan megjelenő tartalom (például egy kibontott menü) természetesen változtathatja az elrendezést; a gond a váratlan változás.Laborban kipróbálva: ugyanaz az oldal rosszul és jól
A 9.2 leckében már használt két oldalt (egy szándékosan hibás és egy javított kurzusoldalt) a Lighthouse 13.5.0-s verziójával, Chrome 154 böngészőben, szimulált mobil környezetben (Lighthouse alapértelmezett lassított hálózat és processzor) mértük. A kiszolgáló mesterségesen késleltette a stíluslapot (0,9 s), a JavaScriptet (0,6 s) és a nagy képet (0,4 s). A hibás oldal egy 1,35 megabájtos képet töltött be méret nélkül, a JavaScript 0,4 s-ig blokkolta a szálat, és egy banner 1,5 s után szúródott be az oldal tetejére. A javított oldal 150 kilobájtos, méretezett képet használt, a stílusokat beágyazva kapta, a JavaScript pedig
defer-rel és rövid volt.(A Lighthouse labormérés: egyetlen betöltés, szimulált környezet. Az INP-t nem méri, mert ahhoz tényleges felhasználói művelet kell; a laborban a TBT, a betöltés alatti főszál-blokkolás közelíti, a web.dev szerint az INP-t.)
Mit olvashatunk ki ebből?
unsized-images) külön hibaként jelezte, mert ez a későbbi elmozdulás kockázata.deferpontosan azok a lépések, amelyek a felhasználónak is gyorsabb, stabilabb élményt adnak (3.4).A Lighthouse a javított oldalon is jelzett egy konzolhibát: a böngésző
favicon.ico-t kért, és404-et kapott. A teljesítményt ez nem érinti, de a „bevált gyakorlatok” pontszámát 92-re csökkentette. A mérés minden részlete a környezettől függ, ezért az eredményeket összehasonlításra, nem abszolút igazságnak kell tekinteni.Késleltetés: nem csak a fájlméret számít
A késleltetés (4.6) az az idő, amely egy kérés elindítása és a válasz megérkezése között eltelik. Egy kis méretű válasz is lehet lassú, ha a szerver csak sok idő után kezd válaszolni; egy nagyobb kép is elfogadhatóan érkezhet, ha közelről, gyors hálózaton és jól szervezett letöltéssel szolgálják ki. Hasznos külön gondolni a válasz első bájtjára (4.2: TTFB) és a teljes válaszra: ha a szerver az adatbázisra vár, a böngésző sokáig nem kap semmit, a látogató üres képernyőt lát. A hálózat mellett az oldalon futó sok, nagy vagy rosszul ütemezett szkript is lefoglalhatja a böngésző főszálát, ilyenkor a fájlok akár le is töltődhettek, de a felület nem reagál. A „megabájtok száma” ezért nem elég.
Képek, JavaScript és gyorsítótár
Mit és hogyan mérjünk?
A böngésző fejlesztői eszközeinek hálózati nézete megmutatja, melyik kérés mennyi ideig tartott, mekkora volt a válasz, gyorsítótárból érkezett-e. A teljesítményprofil megmutatja, ha egy hosszú JavaScript-feladat blokkolja a felületet. Ezeket nem értelmezhetjük elszigetelten: mindig tegyük fel a kérdést, melyik felhasználói feladat sérül, és melyik változtatás javítana rajta a legtöbbet.
Végigvezetett példa: a Kurzuspont jelentkezési oldala
A Kurzuspont jelentkezési oldalán a hallgatók azt panaszolják, hogy nyitáskor „lassú”. A csapat a következő sorrendben dolgozik: (1) laborban méri az LCP-t, a TBT-t és a CLS-t, a valós adatokban pedig az INP-t is; (2) megnézi, mi az LCP-elem (a kurzus fényképe); (3) a képet megfelelő méretben adja, a stílust a kritikus részre szűkíti, a szkriptet
defer-rel tölti; (4) aJelentkezemgombra azonnali visszajelzést ad (letiltott állapot, „Küldés...”); (5) ellenőrzi a valós adatokat a 75. percentilisen. A siker mércéje nem a pontszám, hanem az, hogy a hallgató gyorsan megtalálja és biztonsággal használja a jelentkezést.Gyakori tévhitek
Röviden
Ellenőrző kérdések
Tanulási források