Miért nem tartalmazza a Google Lighthouse az INP-t, a Core Web Vital elemet?
A Google Lighthouse nem használja az Interaction to Next Paint (INP) mérőszámot szabványos tesztjei során, annak ellenére, hogy az INP az egyik alapvető webes vitals.
Barry Pollard, a Web Performance Developer Advocate a Google Chrome-on elmagyarázta ennek okait, és betekintést nyújtott az INP mérésébe.
A világítótorony az oldalbetöltést méri, nem az interakciókat
A Lighthouse egy egyszerű oldalbetöltést mér, és a folyamat során különféle jellemzőket rögzít.
Meg tudja becsülni a legnagyobb tartalommal rendelkező festéket (LCP) és a kumulatív elrendezési eltolást (CLS) meghatározott terhelési feltételek mellett, azonosítja a problémákat, és tanácsot ad e mutatók javítására.
Az INP azonban eltérő, mivel a felhasználói interakcióktól függ.
Pollard elmagyarázta:
„A probléma az, hogy a Lighthouse, mint sok webes tökéletesítő eszköz, általában csak betölti az oldalt, és nem lép kapcsolatba vele. Nincs kölcsönhatás = nincs mérhető INP!”
Egyéni felhasználói folyamatok lehetővé teszik az INP mérést
Míg a Lighthouse nem tudja mérni az INP-t, a gyakori felhasználói utak ismerete lehetővé teszi a „felhasználói folyamatok” használatát az INP mérésére.
Pollard hozzátette:
"Ha webhelytulajdonosként ismeri a gyakori felhasználói útjait, akkor ezeket a Lighthouse-ban mérheti a "felhasználói áramlások" segítségével, amelyek ezután az INP-t mérik.
Ezek a gyakori felhasználói utak automatizálhatók egy folyamatos integrációs környezetben, lehetővé téve a fejlesztők számára, hogy teszteljék az INP-t minden egyes véglegesítéskor, és észleljék a lehetséges regressziókat.
Teljes blokkolási idő INP-proxyként
Bár a Lighthouse nem tudja mérni az INP-t interakciók nélkül, képes mérni a valószínű okokat, különösen a JavaScript-feladatok hosszú távú blokkolását.
Itt jön képbe a teljes blokkolási idő (TBT) mérőszáma.
Pollard szerint:
„A TBT (Total Blocking Time) az összes, 50 ms-nál nagyobb feladat összesített idejét méri. Az elmélet a következő:
- Sok hosszú, blokkoló feladat = nagy az INP kockázata!
- Kevés hosszú, blokkoló feladat = alacsony az INP kockázata!”
A TBT mint INP-helyettesítő korlátai
A TBT-nek vannak korlátai, mint az INP helyettesítője.
Pollard megjegyezte:
„Ha nem kommunikál a hosszú feladatok során, akkor lehet, hogy nincs INP-problémája. Ezenkívül az interakciók TÖBB JavaScriptet tölthetnek be, amelyet nem a Lighthouse mér."
Hozzáteszi:
"Tehát ez egy nyom, de nem helyettesíti az INP tényleges mérését."
Optimalizálás a Lighthouse-pontszámokhoz a felhasználói élményhez képest
Egyes fejlesztők a Lighthouse pontszámokra optimalizálnak anélkül, hogy figyelembe vennék a felhasználókra gyakorolt hatást.
Pollard óva int ettől, kijelentve:
„Gyakori mintát látok, hogy az ÖSSZES JS-t elhalasztják addig, amíg a felhasználó interakcióba nem lép egy oldallal: Nagyszerű a Lighthouse pontszámokhoz! Gyakran szörnyű a felhasználók számára 😢:
- Néha semmi sem töltődik be, amíg meg nem mozgatja az egeret.
- Az első interakció gyakran nagyobb késést okoz.”
Pollard teljes bejegyzése
Miért számít ez?
A Lighthouse, INP és TBT kapcsolatok megértése szükséges a felhasználói élmény optimalizálásához.
Az INP mérésének korlátainak felismerése segít elkerülni a téves optimalizálást.
Pollard tanácsa az INP mérésére, hogy a valós felhasználói interakciókra összpontosítson, hogy a teljesítmény javítása javítsa az UX-t.
Mivel az INP továbbra is Core Web Vital marad, árnyalatainak megértése elengedhetetlen ahhoz, hogy elfogadható küszöbön belül maradjon.
Gyakorlati alkalmazások
A webhely teljesítményének és az INP-nek figyelemmel kísérése:
- Használja a Lighthouse „felhasználói áramlásait” az INP mérésére a közös utakon.
- Automatizálja a felhasználói folyamatokat a CI-ben az INP figyeléséhez és a regressziók rögzítéséhez.
- Használja a TBT-t INP proxyként, de ismerje meg korlátait.
- A pontos INP adatok érdekében előnyben részesítse a helyszíni méréseket.
- Egyensúlyozza a teljesítményoptimalizálást UX-megfontolások mellett.