CoreDash-ulottuvuus: Syötetyyppi (INP)

Ulottuvuus: Syötetyyppi INP (inpit)

Syötetyyppi (INP) -ulottuvuus tallentaa DOM-tapahtumatyypin, joka laukaisi yksittäisen huonoimman vuorovaikutuksen käyttäjän sivun käynnin aikana. Arvo on selaimen Event Timing API:n raaka tapahtuman nimi: click, keydown, pointerdown, pointerup, keypress ja muutamat muut.

INP on huonoimman tapauksen metriikka. Se ei laske vuorovaikutusten keskiarvoa. Se etsii sen yhden vuorovaikutuksen, joka kesti pisimpään syötteestä seuraavaan maalaamiseen (next paint), ja raportoi kyseisen keston. Syötetyyppi-ulottuvuus kertoo, mitä käyttäjä teki täsmälleen sillä hetkellä. Tämä on ero sen välillä, että tiedetään "INP on 450 ms" ja tiedetään "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ä. Kyseisen ryhmän yksittäinen pisin tapahtumankäsittelijä (event handler) määrittää vuorovaikutuksen viiveen. CoreDash tallentaa pisimmän käsittelijän tapahtumatyypin, joka on se, joka teki vuorovaikutuksesta hitaan.

Miksi syötetyypillä on merkitystä INP:lle

Jokainen syötetyyppi vastaa eri osaa JavaScript-koodissasi. Jos näet tapahtuman keydown vallitsevana syötetyyppinä sivulla, jolla on huono INP, tiedät välittömästi, että ongelma on näppäilynkäsittelijöissäsi: automaattinen täydennys, haku kirjoitettaessa tai lomakkeen validointi, joka ajetaan jokaisella näppäimen painalluksella. Jos näet tapahtuman click, ongelma on painikkeiden ja linkkien käsittelijöissä: navigointilogiikka, tilan päivitykset, modaali-ikkunoiden avaamiset tai analytiikkakutsut, jotka laukaistaan synkronisesti.

Ilman tätä ulottuvuutta INP-tutkimus alkaa profilointi-istunnoilla, toistovaiheilla ja arvailulla siitä, mitä vuorovaikutusta 75. persentiilin käyttäjä yritti suorittaa. Syötetyyppi-ulottuvuuden avulla voit siirtyä suoraan asianmukaiseen käsittelijään. Aikasäästöt ovat todellisia.

Syötetyyppi paljastaa myös alustojen väliset erot. Sivusto, jolla tehokäyttäjät käyttävät runsaasti näppäimistönavigointia, näyttää suuren osuuden keydown-tapahtumia huonon INP:n takana. Ensisijaisesti mobiililaitteilla käytettävä tuote näyttää puolestaan pointerdown-tapahtuman hallitsevana. Sama sivu, sama INP-tulos, mutta eri korjaus eri käsittelijöille riippuen siitä, keitä käyttäjäsi todellisuudessa ovat.

Syötetyypit

click ja pointerdown

Nämä ovat CoreDash-datan yleisimmät syötetyypit, ja ne vastaavat noin 75 %:sta huonoimmista INP-tapahtumista. Työpöytäkoneilla click tarkoittaa hiiren painikkeen vapauttamista. Mobiililaitteilla napautus laukaisee koko ketjun: pointerdown laukeaa ensin, kun sormi koskettaa näyttöä, sitten pointerup, kun se nousee, ja lopulta click. CoreDash tallentaa sen ketjun tapahtuman, jolla oli pisin käsittelijä.

Klikkauskäsittelijät ovat raskaan synkronisen JavaScript-työn ensisijainen paikka. Yksittäinen klikkaus navigointikohteessa voi laukaista tilanhallinnan päivityksiä, DOM-muutoksia, analytiikkatapahtumia ja uudelleenrenderöinnin (re-render) kaikki samassa tehtävässä. Jokainen synkronisen työn millisekunti klikkauskäsittelijässä on millisekunti lisää INP-tulokseen.

Hitaiden klikkauskäsittelijöiden korjaus on tehtävien pilkkominen (task decomposition). Käytä metodia scheduler.yield() pilkkoaksesi käsittelijän pienempiin tehtäviin ja antaaksesi selaimen renderöidä niiden välillä. Siirrä ei-kriittinen työ, kuten analytiikkakutsut, setTimeout-funktioon nollaviiveellä tai lykkää ne kokonaan requestIdleCallback-metodiin. Selaimen tarvitsee suorittaa vain se työ, joka vaikuttaa visuaaliseen vasteeseen ennen seuraavaa maalausta. Kaikki muu voi odottaa.

keydown

Näppäimistösyöte vastaa noin 15 %:sta huonoimmista INP-tapahtumista CoreDash-datassa, mutta se tuottaa joitakin räikeimmistä tuloksista. Syynä on tiheys: käyttäjä, joka kirjoittaa hakukenttään, laukaisee keydown-tapahtuman jokaisella näppäilyllä. Jos käsittelijäsi kestää 200 ms, käyttäjä kokee 200 ms:n viiveen jokaisen kirjoittamansa merkin jälkeen. 10 merkin hakukysely muuttuu 2 sekunnin kertyneeksi estäväksi ajaksi (blocking time).

Yleisiä syyllisiä ovat haku kirjoitettaessa -toteutukset, jotka laukaisevat synkronisia API-pyyntöjä tai suorittavat kalliita DOM-erotteluja (DOM diffing) jokaisella näppäilyllä, sekä lomakkeiden validointi, joka tarkistaa koko lomakkeen jokaisella näppäimen painalluksella. Nämä mallit toimivat hyvin pienessä mittakaavassa, mutta pettävät todellisissa käyttäjäolosuhteissa.

Vakiokorjauksia ovat debouncing ja työn siirtäminen muualle. Käytä hakukäsittelijässäsi debouncing-tekniikkaa, jotta se laukeaa vasta, kun käyttäjä pitää tauon kirjoittamisessa, tyypillisesti 200–300 millisekuntia. Monimutkaisempaa käsittelyä varten, kuten sumea haku (fuzzy search) laajasta paikallisesta datasta, siirrä laskenta Web Worker -säikeeseen, jotta main thread pysyy vapaana renderöimään seuraavan kehyksen jokaisen keydown-tapahtuman jälkeen.

pointerup

Pointer up -tapahtumat edustavat noin 8 %:a huonoimmista INP-tapauksista CoreDash-datassa. pointerup laukeaa kosketus- tai klikkaussekvenssin lopussa, tapahtuman pointerdown jälkeen. Jotkin viitekehykset ja UI-kirjastot sitovat ensisijaisen "klikkaus"-käyttäytymisensä tapahtumaan pointerup tapahtuman click sijasta, mikä siirtää käsittelijän aikaisemmaksi vuorovaikutuksen elinkaaressa.

Kun pointerup näkyy hallitsevana syötetyyppinä, tutkimus on sama kuin klikkauskäsittelijöillä: selvitä, mitä JavaScriptiä käsittelijässä ajetaan, ja erota työ, jonka on estettävä seuraava maalaus, työstä, jota voidaan lykätä. Ero tapahtumaan click on yleensä viitekehystason päätös, ei sovellustason päätös, joten korjaus saattaa edellyttää komponenttikirjaston vuorovaikutussidonnan muuttamista.

Debugging-työnkulku

1. Suodata syötetyypin mukaan CoreDashissa: Avaa INP-erittely epäonnistuneelle URL-osoitteelle ja tarkista, mikä syötetyyppi hallitsee huonoimpia vuorovaikutuksia. Jos yksi tyyppi vastaa yli puolta huonoista INP-tapahtumistasi, aloita sieltä. Jakautuma kertoo, mihin profilointiaika kannattaa käyttää.
2. Toista oikealla vuorovaikutuksella: Avaa Chrome DevTools, ota käyttöön Performance-profilointi ja suorita täsmälleen se vuorovaikutustyyppi, joka näkyy CoreDashissa. keydown-painotteinen sivu tulisi testata kirjoittamalla. click-painotteinen sivu tulisi testata hiiren klikkauksilla niihin elementteihin, joita käyttäjäsi käyttävät. Tallenna jälki (trace) ja tunnista Main-säikeen pitkät tehtävät, jotka laukeavat välittömästi syötetapahtuman jälkeen.
3. Käytä tyyppikohtaista korjausta ja varmista: keydown-ongelmissa lisää debouncing ja profiloi uudelleen. click-ongelmissa lisää scheduler.yield()-kutsuja loogisiin kohtiin käsittelijässä. Julkaise testiympäristöön, käytä WebPageTestiä vuorovaikutusskriptauksella tai Chrome DevToolsin Performance-paneelia ja varmista, että tehtävän kesto laskee ennen tuotantoon siirtämistä.

Insinöörimäinen peukalosääntö

• keydown hallitsee huonoa INP-tulostasi: Lisää debouncing kaikkiin haku- ja automaattisen täydennyksen käsittelijöihin. 200 ms:n viive on vakioaloituspiste. Jos laskenta on kallista jopa tällä viiveellä, siirrä se pois main threadista Web Workerin avulla.
• click tai pointerdown hallitsee: Käsittelijäsi tekevät liikaa synkronista työtä ennen kuin selain voi maalata. Tarkista jokainen klikkauskäsittelijä epäonnistuneella URL-osoitteella. Poista synkroniset analytiikkakutsut. Pilko monivaiheinen logiikka scheduler.yield()-metodilla vaiheiden välillä.
• pointerup hallitsee: Tarkista, sitooko viitekehyksesi vuorovaikutuslogiikan tapahtumaan pointerup tapahtuman click sijasta. Korjaus on yleensä sama kuin klikkauskäsittelijöillä, mutta alkupiste koodissa on eri.
• Sekalainen jakautuma ilman selvää voittajaa: Ongelma ei ole vain yhdessä vuorovaikutustyypissä. Profiloi kolme hitainta yksittäistä vuorovaikutusta kaikista tyypeistä ja käsittele ne vaikutusjärjestyksessä. Älä optimoi yleisellä tasolla.

Syötetyyppi on reitityssignaali. Se ei kerro, mikä on hidasta. Se kertoo, mistä kannattaa etsiä. Kun tiedät, klikkaavatko, kirjoittavatko vai napauttavatko käyttäjäsi silloin, kun INP epäonnistuu, jokaisesta seuraavasta tutkimusvaiheesta tulee nopeampi ja kohdistetumpi.