Kattintás után csend? Az INP mutató és a weboldal válaszideje
Ismerős helyzet: a látogató rákattint a mobilmenüre vagy az ajánlatkérő gombra, és egy pillanatig semmi sem történik. Ilyenkor sokan újra kattintanak, mert azt hiszik, hogy az oldal elromlott. Ezt a késlekedést méri az Interaction to Next Paint, röviden INP. A web.dev cikke, az Interaction to Next Paint (INP) szerint a Chrome használati adatai alapján a felhasználók egy oldalon töltött idejének 90%-a a betöltés után telik el. Ezért nem elég, ha az oldal gyorsan betölt: a kattintásokra is gyorsan kell reagálnia.
Mit mér az INP
A web.dev leírása szerint az INP stabil Core Web Vitals mutató, amely az oldal válaszkészségét méri. Három interakciótípust figyel: az egérkattintást, az érintőképernyős koppintást és a billentyűleütést. A görgetés, az egérrel való rámutatás és a nagyítás nem számít bele.
Egy interakció késleltetése attól a pillanattól tart, amikor a felhasználó elkezdi a műveletet, addig, amíg a böngésző ki tudja rajzolni a következő képkockát. Ennek három része van: a bemeneti késés, amíg az eseménykezelők el sem indulnak, a feldolgozási idő, amíg lefutnak, és a megjelenítési késés, amíg a változás a képernyőre kerül. Az oldal INP értéke a legtöbb webhelynél a leglassabb megfigyelt interakció. Ha egy oldalon nagyon sok interakció történik, minden 50 interakcióból a leglassabbat figyelmen kívül hagyják, hogy egy véletlen akadás ne torzítsa az eredményt. Az INP a korábbi First Input Delay (FID) utódja: a FID csak az első interakció bemeneti késését nézte, az INP az oldal teljes élettartamát.
Mikor jó az érték
A web.dev a mezőben mért oldalbetöltések 75. percentilisét javasolja figyelni, mobilon és asztali gépen külön:
- 200 ezredmásodperc vagy kevesebb: jó válaszkészség.
- 200 és 500 ezredmásodperc között: javítandó.
- 500 ezredmásodperc felett: gyenge válaszkészség.
Hol jön elő egy kisvállalati weboldalon
A web.dev példái hétköznapiak: egy termék kosárba tétele, a mobil navigációs menü kinyitása, egy belépési űrlap elküldése vagy egy lenyitható harmonika-elem. A cikk videós példájában a hosszú feladatok blokkolják a harmonika nyitását, a felhasználó többször kattint, majd amikor a böngésző utoléri magát, az elem váratlanul kinyílik és be is csukódik.
Kisvállalati oldalon ugyanezek a pontok számítanak: a menü, az ajánlatkérő vagy kapcsolati űrlap, az időpontfoglaló és a webshop kosara. Az útmutató külön kitér a beágyazott iframe-ekre is. A felhasználó nem tudja, hogy egy foglalómodul vagy videólejátszó iframe-ben fut, ezért az ottani interakciók is a teljes oldal élményéhez tartoznak. A JavaScript API viszont nem látja az iframe tartalmát, emiatt eltérés lehet a Chrome User Experience Report (CrUX) adatai és a saját valós felhasználói mérés (RUM) között.
Hogyan mérjük
A web.dev szerint a legjobb kiindulópont a valós felhasználóktól gyűjtött mezőadat. Ha a webhely bekerül a CrUX adatkészletbe, a PageSpeed Insights legalább az egész domainre megmutatja az INP értéket, egyes esetekben URL szinten is. A CrUX azt jelzi, hogy van-e gond, de azt nem, hogy mi okozza. Ehhez valós felhasználói mérés kell, például a web-vitals JavaScript könyvtár onINP függvényével.
Előfordulhat, hogy egy oldalnak nincs INP értéke. Ilyen eset, ha a látogató nem kattintott, nem koppintott és nem gépelt, csak görgetett, ha az oldalt kereső robot nyitotta meg, vagy ha nincs elég Chrome-os adat a CrUX-ban. Laborban, mezőadat nélkül a web.dev azt javasolja, hogy a gyakori felhasználói útvonalakat kattintsuk végig, és már betöltés közben is próbáljuk ki az elemeket, mert ilyenkor a legterheltebb a böngésző fő szála. A Total Blocking Time (TBT) közelítő jelzés lehet, de nem helyettesíti az INP-t.
Mit nézünk meg weboldal-üzemeltetéskor
A Flybuiltnél ezt a rövid listát használjuk, amikor egy élő oldal válaszkészségét ellenőrizzük. Nem csodamódszer, hanem a web.dev cikk lefordítása a napi munkára.
- A PageSpeed Insightsban a mezőadatot nézzük, mobilon és asztali gépen külön, ha az oldal szerepel a CrUX-ban.
- Végigkattintjuk a fő útvonalakat: menü, ajánlatkérő űrlap, időpontfoglaló, kosár. Ezt betöltés közben is kipróbáljuk.
- Megnézzük, hogy minden kattintás után azonnal látszik-e valamilyen visszajelzés, például a gomb állapota, még akkor is, ha a háttérben futó művelet tovább tart.
- A beágyazott iframe modulokat külön kezeljük, mert a saját mérés nem mindig látja őket.
- Ha nincs mezőadat, nem találgatunk: labormérést vagy valós felhasználói mérést állítunk be, és a TBT-t csak közelítésként kezeljük.
Forrás: web.dev, Jeremy Wagner és Barry Pollard, Interaction to Next Paint (INP).