INP: teljes útmutató

Az INP (Interaction to Next Paint) azt méri, milyen gyorsan reagál az oldal a felhasználó kattintására, koppintására vagy billentyűleütésére: mennyi idő telik el az interakciótól a következő képkocka kirajzolásáig. A Core Web Vitals válaszkészségi mutatója, 2024 márciusában váltotta a FID-et. Jó értéknek a 200 ezredmásodperc vagy kevesebb számít.

Alapfogalmak

Az INP azt a kérdést teszi fel, amelyet minden látogató ösztönösen feltesz: ha rákattintok valamire, látom-e azonnal, hogy történt valami? Egy menü, amely fél másodpercig nem nyílik ki, egy kosárgomb, amely nem ad visszajelzést, vagy egy szűrő, amely lefagyasztja a listát, mind rossz INP-értéket okoz. A mutató nem azt nézi, mikor fejeződik be a teljes művelet, hanem azt, mikor jelenik meg az első vizuális visszajelzés.

Az INP a Core Web Vitals harmadik eleme az LCP és a CLS mellett. Elődje, a FID, csak az első interakció bemeneti késését mérte, vagyis azt, mennyit várt a böngésző, mielőtt egyáltalán elkezdhette feldolgozni az eseményt. Az INP ennél sokkal teljesebb: az oldal teljes életciklusa alatt minden interakciót figyel, és a késés mindhárom részét beleszámolja.

Mi számít interakciónak?

Egérkattintás.
Koppintás érintőképernyőn.
Billentyűleütés fizikai vagy képernyős billentyűzeten.

A görgetés és az egérmutató mozgatása, például a hover, nem számít interakciónak az INP szempontjából. Egy interakció több eseményből állhat: egy koppintás például pointerdown, pointerup és click eseményeket is kivált. Az INP ezeket egy interakcióként kezeli, és a leghosszabb eseménykezelési időt veszi figyelembe.

A küszöbértékek

Minősítés	INP érték	Mit érez a látogató
Jó	200 ezredmásodperc vagy kevesebb	Az oldal azonnal reagál
Javítandó	200 és 500 ezredmásodperc között	Érezhető, de még elviselhető késés
Gyenge	500 ezredmásodperc felett	Az oldal akadozik, a látogató többször kattint

A többi Core Web Vitals mutatóhoz hasonlóan a minősítés a valós látogatások 75. percentilisére vonatkozik, mobilon és asztalon külön. Mivel a mobil eszközök processzora általában gyengébb, az INP-problémák mobilon gyakrabban jelentkeznek.

Hogyan lesz egy oldalnak egy INP-értéke?

Egy látogatás alatt sok interakció történhet. Az INP nem átlagot számol, hanem a leglassabb interakciók egyikét veszi. Ha az oldalon kevés interakció történik, a leglassabb számít. Ha nagyon sok, a mutató a kiugró értékek közül néhányat figyelmen kívül hagy, hogy egyetlen véletlen akadás ne torzítsa az eredményt. A lényeg: az INP a rossz élményeket emeli ki, nem a tipikusat. Ezért egy oldal, amelyen a legtöbb kattintás gyors, de egy szűrő nagyon lassú, rossz INP-t kaphat.

Miért váltotta az INP a FID-et?

A FID két fontos dolgot nem látott. Egyrészt csak az első interakciót mérte, pedig a látogató élményét a későbbi kattintások legalább annyira meghatározzák. Másrészt csak a bemeneti késést számolta, az eseménykezelő futását és a képernyő frissítését nem. Így egy oldal jó FID-et kaphatott akkor is, ha a kattintás után hosszú ideig semmi nem történt a képernyőn. Az INP mindkét hiányt pótolja, ezért a gyakorlatban szigorúbb mutató: sok webhely, amely a FID alapján rendben volt, az INP alapján javítandó vagy gyenge minősítést kapott.

Hogyan működik?

A böngésző fő szála egyszerre csak egy dolgot tud csinálni. Ezen a szálon fut a JavaScript, itt számolja a böngésző a stílusokat és az elrendezést, és innen indul a kirajzolás. Ha a felhasználó kattint, miközben a fő szál egy hosszú feladattal van elfoglalva, a kattintás feldolgozása várni kényszerül. Ez a várakozás, a feldolgozás és a képernyő frissítése együtt adja az INP-t.

Az INP három része

Bemeneti késés. Az interakciótól addig, amíg az eseménykezelők elkezdenek futni. Ha a fő szál foglalt, például egy harmadik féltől származó szkript fut, ez a rész hosszú.
Feldolgozási idő. Az eseménykezelők futási ideje. Ha a kattintásra futó kód sok munkát végez, például nagy listát rendez vagy sok DOM-elemet módosít, ez a rész nő.
Megjelenítési késés. Az eseménykezelők végétől a következő képkocka kirajzolásáig. Ide tartozik a stílusszámítás, az elrendezés és a festés. Nagy és bonyolult DOM esetén ez a rész is jelentős lehet.

A javításhoz először azt kell tudni, melyik rész viszi a legtöbb időt. A bemeneti késés általában arra utal, hogy más kód foglalja a fő szálat az interakció pillanatában. A hosszú feldolgozási idő a saját eseménykezelőre mutat. A hosszú megjelenítési késés a DOM méretére, a drága CSS-re vagy a kirajzolás utáni szinkron munkára.

Hosszú feladatok

A böngészős teljesítménymérés hosszú feladatnak nevezi azt a fő szálon futó munkát, amely 50 ezredmásodpercnél tovább tart. Amíg egy ilyen feladat fut, a böngésző nem tud reagálni a felhasználóra. A hosszú feladatok a betöltés alatt különösen gyakoriak, amikor a keretrendszerek, az elemző és a hirdetési szkriptek egyszerre inicializálódnak. Egy kattintás, amely ebbe az időszakba esik, akkor is lassú lesz, ha maga az eseménykezelő gyors.

Miért a következő kirajzolás?

A felhasználó a képernyőn látja, hogy az oldal reagált. Ha az eseménykezelő gyorsan lefut, de a böngésző nem tud kirajzolni, mert utána azonnal egy újabb hosszú munka következik, a látogató továbbra sem lát semmit. Ezért az INP a következő képkockáig mér, nem csak az eseménykezelő végéig. A gyakorlatban ez azt jelenti, hogy a vizuális visszajelzést előre kell hozni, a nehéz munkát pedig utána kell végezni.

Kidolgozott példa: szűrőpanel egy webáruházban

Egy webáruház kategóriaoldalán a terepi INP mobilon a gyenge sávban volt. A valós felhasználói mérés szerint a leglassabb interakció a szűrőpanel jelölőnégyzeteire esett. A laboratóriumi vizsgálat megmutatta, hogy egy kattintás után az eseménykezelő szinkron módon újraszűrte és újrarajzolta a teljes terméklistát, majd elküldött egy elemzési eseményt. A javítás két lépés volt. Először a jelölőnégyzet azonnal átváltott, és egy töltésjelző jelent meg, majd a kód átadta a vezérlést a böngészőnek, és csak utána kezdte a lista frissítését. Másodszor az elemzési eseményt a kirajzolás utánra ütemezték. Az interakció feldolgozási ideje jelentősen rövidült, mert a látogató az első képkockában már látta a változást.

Fő módszerek

Az INP javítása a fő szál tehermentesítéséről szól. A módszereket a három rész szerint érdemes csoportosítani, de van néhány általános elv, amely mindegyikre hat: kevesebb JavaScript, rövidebb feladatok, kisebb DOM, és a vizuális visszajelzés előrehozása.

A bemeneti késés csökkentése

Harmadik féltől származó szkriptek átvizsgálása. Csevegőablakok, hirdetések, címkekezelők és elemzők gyakran hosszú feladatokat futtatnak. Ami nem szükséges, azt érdemes eltávolítani vagy később betölteni.
Hosszú feladatok feldarabolása. Ha egy nagy munkát kisebb részekre osztasz, és a részek között visszaadod a vezérlést a böngészőnek, az interakció a részek között be tud férni.
Kevesebb JavaScript a betöltéskor. Kódfelosztással csak az adott oldalhoz szükséges kód töltődjön be.
Időzítők ellenőrzése. Az ismétlődő időzítők, amelyek rendszeresen nagy munkát végeznek, bármikor ütközhetnek egy interakcióval.

A feldolgozási idő rövidítése

Az eseménykezelőben csak az fusson szinkron módon, ami a vizuális visszajelzéshez szükséges. Minden más, például adatküldés, elemzési esemény, nem látható részek frissítése, várhat a kirajzolás utánig. A vezérlés visszaadására több technika létezik: a hagyományos setTimeout, a requestAnimationFrame és egy újabb, erre a célra tervezett scheduler.yield() függvény. Ez utóbbit nem minden böngésző támogatja, ezért tartalék megoldás kell mellé.

Ellenőrzőlista egy eseménykezelő átírásához

Mi az a legkisebb vizuális változás, amely jelzi, hogy a kattintás megtörtént? Ez fusson először.
Mi az, ami a következő képkockáig nem szükséges? Ezt tedd a vezérlés visszaadása mögé.
Van-e a kezelőben olyan hálózati hívás vagy elemzési esemény, amely szinkron módon vár? Ha igen, alakítsd aszinkronná.
Hány DOM-elemet módosít a kezelő? Ha sokat, szűkíthető-e a frissítés a ténylegesen látható részre?
Gépelésnél futó logikánál van-e késleltetés, hogy ne minden billentyűleütés indítson drága munkát?

Gyakori hiba az úgynevezett layout thrashing, amikor a kód egy ciklusban felváltva olvas elrendezési értékeket és módosítja a stílusokat. Ilyenkor a böngésző kénytelen újra és újra kiszámolni az elrendezést. A megoldás: előbb minden olvasás, utána minden írás.

A megjelenítési késés csökkentése

Kisebb DOM. Minél több elem van az oldalon, annál drágább a stílusszámítás és az elrendezés.
Kliensoldali renderelés visszafogása. Ha egy interakció nagy HTML-részt renderel újra a kliensen, a megjelenítés lassú. Lásd a kliensoldali renderelés útmutatót.
content-visibility. A képernyőn kívüli részek renderelése elhalasztható ezzel a CSS-tulajdonsággal.
Egyszerűbb szelektorok és animációk. A transform és opacity alapú animációk általában olcsóbbak, mint az elrendezést módosítók.

Döntési szabály

Ha a leghosszabb rész	Valószínű ok	Első lépés
Bemeneti késés	Más szkript foglalja a fő szálat	Hosszú feladatok és harmadik felek azonosítása
Feldolgozási idő	Túl sok munka az eseménykezelőben	Visszajelzés előre, a többi munka a kirajzolás utánra
Megjelenítési késés	Nagy DOM, drága elrendezés	DOM csökkentése, renderelés szűkítése

Gyakori hibák

Az INP-problémák alattomosak, mert a fejlesztői gépen ritkán jelentkeznek. Egy erős asztali processzor könnyedén elvégzi azt a munkát, amely egy középkategóriás telefonon több száz ezredmásodpercig tart. A hibák nagy része ezért abból fakad, hogy a csapat nem a valós körülményeket nézi.

Csak Lighthouse-ra hagyatkozás

A Lighthouse alapértelmezett, navigációs mérése nem végez interakciót, ezért INP-t sem tud mérni. Helyette a Total Blocking Time értéket mutatja, amely a betöltés alatti fő szál-blokkolást méri, és jó jelzője lehet a problémáknak. A TBT azonban nem azonos az INP-vel: a betöltés után történő interakciók lassúságát nem látja. Egy jó TBT mellett is lehet rossz az INP, ha a problémás interakció később történik.

Tévhit: az INP csak a betöltésről szól

A FID idején a figyelem a betöltés alatti első interakcióra irányult. Az INP a teljes látogatást nézi. Egy egyoldalas alkalmazásban, ahol a látogató sokáig marad és sokat kattint, a legrosszabb interakció akár percekkel a betöltés után is történhet. Ellenpélda: egy oldal, amely gyorsan betölt, de a kosár megnyitása egy nagy komponens újrarenderelését váltja ki, gyenge INP-t kaphat.

Visszajelzés nélküli várakozás

Ha egy művelet valóban sokáig tart, például egy szerverhívásra kell várni, az INP szempontjából nem a várakozás hossza a gond, hanem az, hogy a látogató nem kap visszajelzést. Egy töltésjelző, egy lenyomott állapotú gomb vagy egy azonnal megjelenő panel kirajzolása lezárja az interakciót, a szerverválasz pedig utána érkezhet.

További visszatérő hibák

Egy címkekezelőbe halmozott sok szkript, amelyek mind kattintási eseményekre figyelnek.
Szinkron elemzési hívások az eseménykezelőben.
Hatalmas DOM, például egy megakategória-menü, amely minden oldalon teljes egészében benne van a HTML-ben.
Gépelésre futó drága keresés késleltetés nélkül, minden billentyűleütésre.
Hibás optimalizálás: a munka áthelyezése egy setTimeout mögé úgy, hogy a vizuális változás is csak utána jelenik meg.

Keretrendszerek csapdája

A modern JavaScript-keretrendszerek kényelmesek, de könnyű velük túl sokat renderelni. Ha egy állapotváltozás a komponensfa nagy részét újrarendereli, egy egyszerű kattintás is drága lesz. A megoldás általában az állapot szűkebb helyre költöztetése, a felesleges újrarenderelések kiszűrése és a nagy listák virtualizálása. A JavaScript SEO útmutató a keretrendszerek keresőoptimalizálási oldaláról is ad áttekintést. Ha egy komponens betöltéskor hidratálódik, a hidratálás alatt érkező interakciók is lassúak lehetnek, mert a fő szál még a hidratálással van elfoglalva.

Mérés

Az INP elsősorban terepi mutató. A valós látogatók eszközei, a valós interakciók és a valós harmadik féltől származó szkriptek együtt adják az értéket, ezt laborban nehéz pontosan újrateremteni. A munkafolyamat ezért a terepi adatból indul, és a laborban reprodukálja a problémás interakciót.

Eszközök

Eszköz	Adattípus	Mire jó
Search Console, Core Web Vitals jelentés	Terepi	Mely URL-csoportokban gyenge az INP
PageSpeed Insights	Terepi, és laborban TBT	Egy URL vagy a teljes forrás terepi INP-je
Chrome UX Report	Terepi	Összesített és történeti adatok
web-vitals könyvtár, attribúcióval	Terepi, saját	Melyik elemen, milyen interakció, melyik rész volt lassú
Chrome fejlesztői eszközök, Performance panel	Laboratóriumi	Egy interakció részletes lebontása, a hosszú feladatok megtalálása
Lighthouse időszakos mód	Laboratóriumi	Egy felhasználói út alatti interakciók mérése

Munkafolyamat

A Search Console-ban azonosítsd a gyenge INP-jű URL-csoportokat.
Valós felhasználói méréssel derítsd ki, melyik elemen és milyen interakciónál lassú az oldal. Enélkül csak találgatás marad.
A fejlesztői eszközökben kapcsold be a processzorlassítást, hogy közelebb kerülj egy átlagos mobil eszközhöz.
Rögzítsd a problémás interakciót, és nézd meg, melyik rész a leghosszabb.
Alkalmazd a részhez tartozó módszert.
Ismételd meg a laboratóriumi mérést, majd kövesd a terepi adatot.

Kidolgozott példa: hírportál menüje

Egy hírportálon mobilon a hamburger menü megnyitása volt a leglassabb interakció a valós felhasználói mérés szerint. A laboratóriumi rögzítés azt mutatta, hogy a bemeneti késés volt hosszú: a kattintás idején a hirdetési szkriptek hosszú feladatai futottak. A menü eseménykezelője maga gyors volt. A csapat a hirdetési szkriptek betöltését későbbre ütemezte, és a nem látható hirdetési helyek inicializálását a görgetéshez kötötte. A menü megnyitásánál a bemeneti késés lerövidült. A példa jól mutatja, hogy a lassú interakció oka gyakran nem az adott elem kódja.

Mire figyelj az adatok értelmezésénél?

Az INP értéke az oldal típusától és a látogatók viselkedésétől is függ. Egy statikus cikkoldalon kevés interakció történik, ezért ott egyetlen lassú kattintás is meghatározza az értéket. Egy interaktív eszközoldalon, például egy kalkulátorban, sok interakció van, és a lassú esetek aránya számít. Ha egy URL-nek kevés a forgalma, a terepi adat hiányozhat, ilyenkor a saját mérés adhat képet. A javítás hatását mindig a saját korábbi értékedhez mérd.

Ellenőrzőlista

Van valós felhasználói mérésed, amely megmutatja a lassú interakció elemét?
Tudod, melyik rész a leghosszabb a problémás interakciónál?
Az eseménykezelő először vizuális visszajelzést ad?
A nem sürgős munka a kirajzolás után fut?
A harmadik féltől származó szkriptek listája át van nézve?
A DOM mérete indokolt, nincsenek rejtett óriás menük?
A terepi INP a 75. percentilisen 200 ezredmásodperc alatt van?