Hogyan olvassunk Lighthouse-jelentést pánik nélkül

Az első szabály: a pontszám nem azonos a webhellyel

Amikor először nyit meg egy Lighthouse-jelentést, számok falával, színkódolt dobozokkal és olyan figyelmeztetésekkel találja szemben magát, amelyekről talán még sosem hallott. A természetes reakció a pánik. A pontszám piros. Tizenhét audit sikertelen. Biztosan elromlott a webhely?

Valószínűleg nem. A Lighthouse diagnosztikai eszköz, nem bizonyítvány. A pontszám egy laboratóriumi körülmények között futtatott szintetikus benchmark — gyakran korlátozott kapcsolaton, egy 2017-es középkategóriás telefont szimulálva. Azt mutatja meg, hogyan teljesít a webhely ebben a konkrét forgatókönyvben, nem azt, hogyan élik meg a valódi felhasználók a valós környezetben.

Ez azért fontos, mert a legtöbb csapat a pontszámra fókuszál, és elveszíti a kontextust. Egy 65-ös pontszám teljesen elfogadható lehet egy összetett, valós idejű adatokkal dolgozó webalkalmazásnál. Egy 95-ös pontszám mellett is lehet gyenge az élmény, ha nem a megfelelő dolgokat optimalizálták. A pontszám a vizsgálat kiindulópontja, nem sikerességi mérőszám.

Mit olvassunk először: Core Web Vitals

Hagyja ki az összesített teljesítménypontszámot. Görgessen le a Metrics szakaszhoz, és nézzen meg három számot: Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) és Interaction to Next Paint (INP). Ezek a Core Web Vitals mutatók, és ezek az egyetlen teljesítménymutatók, amelyeket a Google rangsorolási jelként használ.

• LCP azt méri, mennyi időbe telik a legnagyobb látható elem megjelenítése. Cél: 2,5 másodperc alatt. Ha 4 másodperc felett van, a felhasználók túl sokáig várnak az érdemi tartalomra.
• CLS a vizuális stabilitást méri — vagyis azt, mennyit ugrál az oldal betöltés közben. Cél: 0,1 alatt. Ha 0,25 felett van, a felhasználók véletlenül rossz elemre kattinthatnak, mert a gombok elmozdultak.
• INP a válaszkészséget méri — vagyis azt, milyen gyorsan reagál az oldal kattintásokra, érintésekre és billentyűleütésekre. Cél: 200ms alatt. Ha 500ms felett van, a webhely lomha érzetet kelt.

Ez a három mutató tényleges felhasználói frusztrációval korrelál. Ezeket javítsa, mielőtt bármi más miatt aggódna.

Opportunities vs. Diagnostics: ismerje a különbséget

A Lighthouse két kategóriába sorolja a megállapításait: Opportunities és Diagnostics. Az Opportunities elemeket a becsült időmegtakarítás alapján rangsorolja. A Diagnostics további kontextust ad — olyan dolgokat, amelyek problémák lehetnek, de nem feltétlenül azok.

Kezdje az Opportunities elemekkel. Ha a Lighthouse szerint az „Eliminate render-blocking resources” 1,2 másodpercet takaríthat meg, az konkrét nyereség. Ha azt mondja, hogy a „Reduce unused JavaScript” 0,1 másodpercet takaríthat meg, valószínűleg nem éri meg miatta refaktorálni.

A Diagnostics trükkösebb. Az „Avoid an excessive DOM size” rosszul hangzik, de ha a CLS rendben van, az INP pedig gyors, egy nagy DOM lehet, hogy senkinek sem árt. A diagnosztikák nyomok, nem előírások. Azokat vizsgálja, amelyek összhangban vannak a tényleges mérőszámaival.

Az auditok, amelyeket általában figyelmen kívül hagyhat

Néhány Lighthouse-figyelmeztetés maradványjellegű vagy túl agresszív. Ezek okozzák a legtöbb felesleges pánikot:

• „Does not use passive listeners to improve scrolling performance” — Ez egy mikrooptimalizálás, amely ritkán hoz érdemi változást. Hagyja ki, hacsak nincs bizonyítéka akadozó görgetésre.
• „Image elements do not have explicit width and height” — Ez a CLS szempontjából számít, de csak akkor, ha a képek elrendezés-eltolódásokat okoznak. Ha a CLS már jó, ne refaktoráljon pusztán az audit kedvéért.
• „Serve images in next-gen formats” — Igen, a WebP és az AVIF kisebbek. De ha a képek már optimalizáltak, és az LCP gyors, ez hasznos kiegészítés, nem válság.
• „Avoid enormous network payloads” — A Lighthouse mindent megjelöl, ami 1,6 MB felett van. De egy gyorsan betöltődő 2 MB-os oldal jobb, mint egy 500 KB-os oldal, amely blokkolja a renderelést. Ne csak a teljes méretre figyeljen, hanem arra is, hogyan érkeznek meg a bájtok.

Mi a teendő, ha minden piros

Ha a Lighthouse-pontszám 50 alatt van, és a legtöbb audit sikertelen, valószínűleg a három alapvető ok egyikével áll szemben:

1. Nem optimalizált betűtípusok. A webes betűtípusok továbbra is a legegyszerűbb teljesítménynyereséget adják a legtöbb webhelyen. Ellenőrizze, hogy hat betűvastagságot tölt-e be, miközben csak kettőt használ, vagy WOFF fájlokat küld-e WOFF2 helyett.
2. Renderelést blokkoló CSS és JavaScript. Ha a First Contentful Paint (FCP) 3 másodperc felett van, valami megakadályozza a böngészőt a festésben. Keressen nagy CSS-fájlokat vagy szinkron scripteket a <head> részben.
3. Túlméretezett képek. Ha az LCP-elem egy kép, és 4 MB méretű, akkor ez a probléma. Tömörítse, lazy-loadolja a hajtás alatti képeket, és használjon reszponzív képszintaxist.

Javítson ki ezek közül egyet, majd futtassa újra a Lighthouse-t. Gyakran 20–30 pontos ugrást fog látni. Ezután foglalkozzon a következővel.

Laboradatok vs. valós felhasználói adatok: a realitásellenőrzés

A Lighthouse laborban fut. Lassú kapcsolatot és lassú eszközt szimulál, de nem tudja szimulálni a valódi felhasználói viselkedést — azt, hogyan görgetnek az emberek, mire kattintanak, vagy hogy éppen bizonytalan Wi-Fi-n vannak-e.

Realitásellenőrzésként hasonlítsa össze a Lighthouse-eredményeket a Chrome User Experience Report (CrUX) valós felhasználói adataival. A CrUX azt mutatja meg, hogyan tapasztalták a valódi Chrome-felhasználók a webhelyet az elmúlt 28 napban. Ha a Lighthouse szerint az LCP 4 másodperc, de a CrUX 2 másodpercet mutat, higgyen a CrUX-nak. Ha mindkettő rossz, valódi probléma van.

CrUX-adatokat a PageSpeed Insightsban (a Lighthouse webes verziójában) vagy a Google Search Console „Core Web Vitals” részében talál. Ha eltérés van, vizsgálja meg az okát. Lehet, hogy a valódi felhasználók gyorsabb hálózatokon vannak. Lehet, hogy a Lighthouse egy nem optimalizált fejlesztői buildet tesztel.

Mikor futtassa újra a Lighthouse-t

A Lighthouse zajos. Futtassa háromszor egymás után, és három különböző pontszámot kap, akár ugyanazon az oldalon is. Ennek oka, hogy a teljesítmény változó — háttérfolyamatok, hálózati ingadozás és böngészőheurisztikák egyaránt befolyásolják az eredményt.

Stabil alapértékhez futtassa a Lighthouse-t inkognitó módban, minden bővítményt letiltva, vagy használja a CLI-t a --preset=desktop flaggel a konzisztensebb eredményekért. Futtassa háromszor, és átlagolja a pontszámokat. Ha nagy kilengéseket lát (több mint 10 pontot), valami más nincs rendben — lehet, hogy lassú a szerver, vagy az oldal minden alkalommal más erőforrásokat tölt be.

Minden jelentős változtatás után futtassa újra a Lighthouse-t. Új betűtípus-stratégiát vezetett be? Ellenőrizze az LCP-t. Lazy-loadolja a képeket? Ellenőrizze a CLS-t. Hozzáadott egy harmadik féltől származó scriptet? Ellenőrizze az INP-t. A teljesítmény nem egyszeri javítás; olyan költségkeret, amelyet folyamatosan védeni kell.

Eszközök, amelyek segítenek cselekedni a Lighthouse-megállapítások alapján

A Lighthouse megmondja, mi lassú. Nem mindig mondja meg, hogyan javítható. Ehhez további eszközökre van szükség:

• WebPageTest filmszalagszerű nézetet ad arról, hogyan töltődik be az oldal képkockáról képkockára. Nélkülözhetetlen az LCP- és CLS-problémák diagnosztizálásához.
• Chrome DevTools Performance panel pontosan megmutatja, mely JavaScript blokkolja a fő szálat. Használja egy rossz INP-pontszám forrásának megtalálására.
• Képtömörítő eszközök lehetővé teszik a képek közvetlen böngészőbeli optimalizálását, ami gyorsabb és privátabb, mint egy harmadik féltől származó szolgáltatásba feltölteni őket. A kliensoldali képfeldolgozás adatvédelmi előny, mert a képek soha nem hagyják el a gépét.

A Lighthouse a kiindulópont. Ezek az eszközök segítenek befejezni a munkát.

Fő tanulságok

• A Lighthouse-pontszám laboratóriumi benchmark, nem a valós felhasználói élmény mérőszáma. Mielőtt pánikba esne, hasonlítsa össze a CrUX valós felhasználói adataival.
• Először a Core Web Vitals mutatókra (LCP, CLS, INP) fókuszáljon. Ezek a mutatók korrelálnak a felhasználói frusztrációval és a SEO-hatással.
• Az Opportunities elemeket a becsült időmegtakarítás alapján rangsorolja. Hagyja figyelmen kívül azokat a Diagnostics elemeket, amelyek nem illeszkednek a tényleges teljesítményproblémákhoz.
• Egyes auditok — például a passzív listenerek vagy a next-gen képformátumok — mikrooptimalizálások. Először a nagy dolgokat javítsa.
• Futtassa a Lighthouse-t háromszor, és átlagolja az eredményeket. A teljesítmény változó, és egyetlen futtatás félrevezető lehet.

FAQ

Q: Miért változik a Lighthouse-pontszámom minden futtatáskor?
A: A Lighthouse változó körülmények között méri a teljesítményt — a hálózati sebesség, a CPU-terhelés és a böngészőheurisztikák mind befolyásolják az eredményt. Futtassa háromszor inkognitó módban, és átlagolja a pontszámokat a stabilabb alapértékhez.

Q: Mobilra vagy asztali gépre optimalizáljak először?
A: Mobilra. A Lighthouse alapértelmezésben mobil szimulációt használ, mert a webes forgalom nagy része mobilról érkezik, és a mobileszközök lassabbak. Ha a mobilpontszám jó, az asztali pontszám általában rendben lesz.

Q: A Lighthouse-pontszámom 95, de a webhelyem mégis lassúnak érződik. Mi a gond?
A: A Lighthouse az oldalbetöltést méri, nem a betöltés utáni interaktivitást. Ellenőrizze az INP-pontszámot, és használja a Chrome DevTools Performance panelt annak profilozására, mi történik, amikor a felhasználók kattintanak vagy görgetnek. Lehet, hogy olyan JavaScript-problémája van, amelyet a Lighthouse nem vesz észre.

Q: Szükségem van tökéletes 100-as pontszámra?
A: Nem. A 90+ pontszám kiváló. A 100 hajszolása gyakran olyan dolgok optimalizálását jelenti, amelyek a felhasználóknak nem számítanak. Fókuszáljon a valódi mutatókra — LCP, CLS, INP —, és hagyja figyelmen kívül a pontszámot.

Q: Megbízhatok a Lighthouse-ban, ha sok harmadik féltől származó scriptet használok?
A: A Lighthouse problémaként fogja megjelölni a harmadik féltől származó scripteket, de nem mindig tud különbséget tenni a szükséges és a felesleges elemek között. Használja az „Avoid enormous network payloads” és a „Reduce JavaScript execution time” auditokat a legrosszabb elkövetők azonosítására, majd döntse el, megéri-e megtartani őket.

Források

• „Lighthouse performance scoring” — Google Developers
• „Core Web Vitals” — web.dev
• „Chrome User Experience Report” — Google Developers
• „WebPageTest Documentation” — WebPageTest.org