Core/Dashin ulottuvuus: Input Type (INP)

Ulottuvuus: Input Type INP (inpit)

Input Type (INP) -ulottuvuus tallentaa DOM-tapahtumatyypin, joka aiheutti yksittäisen huonoimman vuorovaikutuksen käyttäjän sivuvierailun aikana. Arvo on raaka tapahtuman nimi selaimen Event Timing API:sta: click, keydown, pointerdown, pointerup, keypress ja muutamat muut.

INP on pahimman tapauksen mittari. Se ei laske vuorovaikutusten keskiarvoa. Se etsii sen yhden vuorovaikutuksen, jonka kesto syötteestä seuraavaan piirtoon oli pisin, ja raportoi tämän keston. Input Type -ulottuvuus kertoo, mitä käyttäjä teki juuri sillä hetkellä. Tämä on ero sen välillä, tiedätkö vain, että ”INP on 450 ms”, vai tiedätkö, että ”INP on 450 ms, koska käyttäjä kirjoitti hakukenttääsi”.

Event Timing API ryhmittelee toisiinsa liittyvät tapahtumat yhdeksi loogiseksi vuorovaikutukseksi. Kosketusnäytön napautus laukaisee tapahtumat pointerdown, pointerup ja click yhtenä ryhmänä. Ryhmän yksittäinen pisin tapahtumankäsittelijä määrittää vuorovaikutuksen viiveen. CoreDash tallentaa pisimmän käsittelijän tapahtumatyypin. Se teki vuorovaikutuksesta hitaan.

Miksi Input Type -ulottuvuudella on merkitystä INP:lle

Jokainen syötetyyppi kytkeytyy eri osaan JavaScript-koodikantaasi. Jos näet keydown-tapahtuman hallitsevana syötetyyppinä sivulla, jonka INP on huono, tiedät heti, että ongelma on painalluskäsittelijöissäsi: automaattisessa täydennyksessä, kirjoittaessa hakevassa toiminnossa (search-as-you-type) tai jokaisella näppäimen painalluksella ajettavassa lomakkeen validoinnissa. Jos taas näet click-tapahtuman, ongelma on painike- ja linkkikäsittelijöissäsi: navigointilogiikassa, tilan päivityksissä, modaalien avaamisessa tai synkronisesti suoritettavissa analytiikkakutsuissa.

Ilman tätä ulottuvuutta INP-tutkinta alkaa profiloinnilla, toistovaiheiden etsimisellä ja sen arvailemisella, mitä vuorovaikutusta 75. persentiilin käyttäjä yritti tehdä. Input Type -ulottuvuuden avulla siirryt suoraan asiaankuuluvaan käsittelijään. Ajansäästö on todellinen.

Syötetyyppi paljastaa myös erot alustojen välillä. Sivusto, jolla tehokäyttäjät navigoivat paljon näppäimistöllä, näyttää suuren määrän huonoa INP:tä aiheuttavia keydown-tapahtumia. Pääasiassa mobiililaitteilla käytettävässä tuotteessa taas hallitsee pointerdown. Sama sivu, sama INP-tulos, mutta eri käsittelijöihin sovellettava korjaus riippuen siitä, keitä käyttäjäsi todellisuudessa ovat.

Syötetyypit

click ja pointerdown

Nämä ovat yleisimmät syötetyypit CoreDashin datassa. Ne kattavat noin 75 % huonoimmista INP-tapahtumista. Työpöytälaitteilla click edustaa hiiren painikkeen vapauttamista. Mobiilissa napautus laukaisee koko ketjun: pointerdown suoritetaan ensin, kun sormi koskettaa näyttöä, sitten pointerup, kun sormi nousee, ja lopuksi click. CoreDash tallentaa sen ketjun tapahtuman, jolla oli pisin käsittelijä.

Click-käsittelijät ovat pääasiallinen paikka raskaalle synkroniselle JavaScript-työlle. Yksi klikkaus navigointielementtiin voi käynnistää tilanhallinnan päivitykset, DOM-mutaatiot, analytiikkatapahtumat ja uudelleenpiirron saman tehtävän aikana. Jokainen synkronisen työn millisekunti click-käsittelijässä lisää INP-arvoa yhdellä millisekunnilla.

Ratkaisu hitaisiin click-käsittelijöihin on tehtävien pilkkominen (task decomposition). Käytä metodia <code>scheduler.yield()</code> pilkkomaan käsittelijä pienempiin tehtäviin. Näin selain voi piirtää niiden välissä. Siirrä ei-kriittinen työ, kuten analytiikkakutsut, setTimeout-kutsuun nollaviiveellä tai lykkää ne kokonaan requestIdleCallback-funktiolle. Selaimen tarvitsee suorittaa ennen seuraavaa piirtoa vain työ, joka vaikuttaa visuaaliseen vasteeseen. Kaikki muu voi odottaa.

keydown

Näppäimistösyötteet kattavat noin 15 % huonoimmista INP-tapahtumista CoreDashin datassa, mutta ne aiheuttavat kaikkein räikeimpiä viiveitä. Syy tähän on toistuvuus: hakukenttään kirjoittava käyttäjä laukaisee keydown-tapahtuman jokaisella näppäimen painalluksella. Jos käsittelijäsi kestää 200 ms, käyttäjä kokee 200 ms viiveen jokaisen kirjoittamansa merkin jälkeen. 10 merkin pituinen hakukysely aiheuttaa siten 2 sekuntia kumulatiivista estävää aikaa.

Yleisimpiä syyllisiä ovat haku kirjoittaessa -toteutukset, jotka tekevät synkronisia API-pyyntöjä tai suorittavat raskasta DOM-vertailua (diffing) jokaisella näppäimen painalluksella, sekä lomakkeen validointi, joka tarkistaa koko lomakkeen uudelleen jokaisella näppäimen painalluksella. Nämä toimintamallit toimivat hyvin pienessä mittakaavassa, mutta pettävät todellisissa käyttöolosuhteissa.

Standardiratkaisut ovat debouncing ja työn siirtäminen pois main threadistä. Viivästä (debounce) hakukäsittelijääsi siten, että se laukeaa vasta, kun käyttäjä keskeyttää kirjoittamisen. Yleensä sopiva viive on 200–300 millisekuntia. Monimutkaisemmissa tapauksissa, kuten tehdessäsi fuzzy-hakua suuresta paikallisesta tietoaineistosta, siirrä laskenta Web Workeriin. Näin main thread pysyy vapaana piirtämään seuraavan kehyksen jokaisen keydown-tapahtuman jälkeen.

pointerup

Pointer up -tapahtumat edustavat noin 8 % huonoimmista INP-tapauksista CoreDashin datassa. pointerup laukeaa kosketus- tai klikkaussarjan lopussa, pointerdown-tapahtuman jälkeen. Jotkin sovelluskehykset ja käyttöliittymäkirjastot sitovat ensisijaisen click-toiminnallisuutensa tapahtumaan pointerup click-tapahtuman sijaan. Tämä siirtää käsittelijän aikaisemmaksi vuorovaikutuksen elinkaaressa.

Kun pointerup näkyy hallitsevana syötetyyppinä, tutkinta on sama kuin click-käsittelijöiden kohdalla. Selvitä, mitä JavaScriptiä käsittelijässä ajetaan. Erota seuraavaa piirtoa estävä työ lykättävästä työstä. Ero tapahtumaan click on yleensä sovelluskehystason valinta, ei sovellustason päätös. Siksi korjaus saattaa vaatia komponenttikirjaston vuorovaikutussidonnan säätämistä.

Vianetsinnän työnkulku

1. Suodata syötetyypin mukaan CoreDashissa: Avaa heikosti suoriutuvan URL-osoitteen INP-erittely. Tarkista, mikä syötetyyppi hallitsee huonoimpia vuorovaikutuksia. Jos yksi tyyppi kattaa yli puolet huonoista INP-tapahtumista, aloita sieltä. Jakauma kertoo, mihin profilointiaika kannattaa käyttää.
2. Toista ongelma oikealla vuorovaikutuksella: Avaa Chrome DevTools, ota Performance-profilointi käyttöön ja tee täsmälleen se vuorovaikutustyyppi, joka näkyy CoreDashissa. Sivua, jota hallitsee keydown, tulee testata kirjoittamalla. Sivua, jota hallitsee click, tulee testata hiiren klikkauksilla niihin elementteihin, joita käyttäjäsi käyttävät. Tallenna jälki (trace) ja tunnista long taskit main threadistä, jotka käynnistyvät heti syötetapahtuman jälkeen.
3. Käytä tyyppikohtaista korjausta ja varmista toimivuus: Ratkaise keydown-ongelmat lisäämällä debouncing ja profiloimalla uudelleen. Ratkaise click-ongelmat lisäämällä scheduler.yield() -kutsuja käsittelijän loogisiin katkaisukohtiin. Vie muutokset testausympäristöön. Käytä WebPageTestiä vuorovaikutusskripteillä tai Chrome DevToolsin Performance-paneelia. Varmista tehtävän keston lyhentyminen ennen tuotantoon vientiä.

Kehittäjän nyrkkisäännöt

• keydown hallitsee huonoa INP:tä: Lisää debouncing kaikkiin haku- ja automaattisen täydennyksen käsittelijöihin. 200 ms viive on suositeltava aloituspiste. Jos laskenta on raskasta vielä tälläkin viiveellä, siirrä se pois main threadistä Web Workerin avulla.
• click tai pointerdown hallitsee: Käsittelijäsi tekevät liikaa synkronista työtä ennen kuin selain voi piirtää. Auditoi jokainen click-käsittelijä heikosti suoriutuvassa URL-osoitteessa. Poista synkroniset analytiikkakutsut. Pilko monivaiheinen logiikka käyttämällä scheduler.yield() -metodia vaiheiden välillä.
• pointerup hallitsee: Tarkista, sitooko sovelluskehyksesi vuorovaikutuslogiikan tapahtumaan pointerup click-tapahtuman sijaan. Korjaus on yleensä sama kuin click-käsittelijöille, mutta koodikannan aloituspiste on eri.
• Sekoittunut jakauma ilman selkeää voittajaa: Ongelma ei johdu vain yhdestä vuorovaikutustyypistä. Profiloi kolme hitainta yksittäistä vuorovaikutusta kaikista tyypeistä ja korjaa ne vaikutuksen mukaisessa järjestyksessä. Älä optimoi yleisellä tasolla.

Input Type on ohjaussignaali. Se ei kerro, mikä on hidasta. Se kertoo, mistä etsiä. Kun tiedät, klikkaavatko, kirjoittavatko vai napauttavatko käyttäjäsi silloin, kun INP heikkenee, jokainen seuraava tutkintavaihe nopeutuu ja kohdentuu paremmin.