CoreDash-ulottuvuus: Lataustila (INP)

Ulottuvuus: Lataustila INP (inpls)

Lataustila (INP) -ulottuvuus tallentaa dokumentin valmiustilan täsmälleen sillä hetkellä, kun käyttäjän vuorovaikutus havaittiin. Jokainen INP-tapahtuma Chrome User Experience Report -raportissa sisältää lataustilan tunnisteen: joko loading, dom-interactive, dom-content-loaded tai complete. CoreDash tuo tämän tunnisteen näkyviin suodatettavana ja ryhmiteltävänä ulottuvuutena, jotta voit vastata kysymykseen, johon pelkät INP-pisteet eivät pysty: missä sivun elinkaaren vaiheessa huonoin vuorovaikutus tapahtui?

Tämä kysymys on jakolinja kahden täysin erilaisen teknisen korjauksen välillä. INP-ongelma, joka keskittyy loading-vaiheeseen, vaatii JavaScriptin lykkäysstrategiaa (deferral strategy). Ongelma, joka keskittyy complete-vaiheeseen, vaatii tapahtumankäsittelijöiden (event handler) työn karsimista, viitekehyksen (framework) yleiskustannusten vähentämistä tai pitkien tehtävien pilkkomista suoritusaikaisessa koodissa. Ryhmittely lataustilan mukaan antaa tämän jaottelun ilman manuaalista instrumentointia.

CoreDash-datassa seuratuilla sivustoilla INP-vuorovaikutusten jakautuma lataustilan mukaan on karkeasti: loading 15 %, dom-interactive 20 %, dom-content-loaded 25 %, complete 40 %. Suurin osa vuorovaikutuksista tapahtuu sen jälkeen, kun sivu on ladattu kokonaan, mutta huonoimmat INP-tulokset keskittyvät ylivoimaisesti varhaisiin tiloihin.

Kuvakaappaus

Miksi lataustilalla on merkitystä INP:lle

Interaction to Next Paint -metriikka mittaa käyttäjän vuorovaikutuksen koko viivettä: syöttöviivettä (input delay), tapahtumankäsittelijän käsittelyaikaa ja esitysviivettä (presentation delay) seuraavaan piirrettyyn kehykseen. Näistä kolmesta komponentista syöttöviive on se, johon vaikuttaa suorimmin se, mitä selain tekee sillä hetkellä, kun käyttäjä klikkaa tai napauttaa.

Sivun lataamisen alkuvaiheessa main thread on maksimikuormituksessa. Selain parsaa HTML-koodia, suorittaa synkronisia skriptejä, rakentaa CSSOM-puuta, ajaa parsaamista estäviä resursseja ja käynnistää renderöintisyklejä peräkkäin. Jokainen pitkä tehtävä main threadilla on ikkuna, jonka aikana käyttäjän vuorovaikutus joutuu jonoon ja joutuu odottamaan. Tämä odotus on syöttöviivettä, ja se on ensisijainen syy huonoon INP-tulokseen sivun latauksen aikana.

Vuorovaikutukset, jotka saapuvat sen jälkeen, kun document.readyState saavuttaa tilan complete, kohtaavat rauhallisemman main threadin. Selain on lopettanut lataamisen. Jos INP on edelleen huono tässä vaiheessa, syynä ei ole latausaikainen kilpailu. Syynä on JavaScript, jota sivusi ajaa vastauksena käyttäjän toimiin: paisuneet tapahtumankäsittelijät, viitekehyksen uudelleenrenderöintisyklit, skriptien käynnistämä layout thrashing tai optimoimaton kolmannen osapuolen koodi, joka suoritetaan synkronisesti vuorovaikutuksen aikana.

Lataustila on nopein suodatin näiden kahden perussyyn erottamiseen toisistaan.

Lataustilat

loading

Selain ei ole vielä lopettanut HTML-dokumentin parsimista. Main thread suorittaa synkronisia skriptejä, hakee parsaamista estäviä resursseja ja rakentaa alkuperäistä DOM-puuta. Tämä on vihamielisin ympäristö käyttäjän vuorovaikutukselle. Syöttöviive on huipussaan, koska mikä tahansa pitkä tehtävä estää suoraan selainta käsittelemästä klikkausta tai napautusta. Käyttäjät, jotka toimivat tämän ikkunan aikana, ovat yleensä kärsimättömimpiä vierailijoita tai niitä, joilla on nopea yhteys ja jotka saavuttavat näkyvän sisällön ennen kuin sivu on latautunut loppuun. Heidän INP-tuloksensa ovat huonoimpia, mitä keräät. Jos merkittävä osa huonoista INP-tapahtumistasi on loading-tilassa, siirrä ei-kriittiset skriptit defer- tai async-tilaan ja poista parsaamista estävät resurssit näkyvän alueen yläpuolelta.

dom-interactive

document.readyState saavuttaa tilan interactive, kun HTML on täysin parsittu ja DOM on rakennettu, mutta aliresurssit, kuten kuvat, tyylitiedostot ja lykätyt skriptit, latautuvat vielä. Lykätyt skriptit alkavat suoriutua tässä vaiheessa, mikä tarkoittaa, että main thread voi edelleen olla vahvasti varattu. Viitekehysten hydraatio (hydration) alkaa usein tästä. Tämä on vaarallinen ikkuna, koska sivu näyttää käyttäjälle valmiilta, mutta main thread on edelleen kiireinen. Syöttöviive pysyy korkeana. Jos huono INP keskittyy tänne, korjaus on sama kuin loading-tilassa: vähennä välittömästi DOM-parsimisen päätyttyä suoritettavan synkronisen työn määrää.

dom-content-loaded

DOMContentLoaded-tapahtuma on lauennut. DOM on valmis ja lykätyt skriptit on suoritettu. Useimmat JavaScript-viitekehykset ovat lopettaneet alkuperäisen hydraatiovaiheensa tähän mennessä. Main threadin työmäärä laskee, ja vuorovaikutukset alkavat saada nopeampia vastauksia. INP-tulokset tässä tilassa ovat yleensä parempia kuin kahdessa aiemmassa tilassa, mutta silti koholla verrattuna complete-tilaan. Jos näet huonojen vuorovaikutusten keskittymän tässä, tarkista mitä viitekehyksesi tai sovellusskriptisi tekevät DOMContentLoaded-käsittelijöissä ja voidaanko hydraatiotyötä paloitella tai voidaanko käyttää yielding-tekniikkaa syötteiden käsittelyn mahdollistamiseksi tehtävien välillä.

complete

document.readyState saavuttaa tilan complete, kun kaikki resurssit, mukaan lukien kuvat, fontit ja kolmannen osapuolen iframe-kehykset, on ladattu. Tämä on vakaa tila, jossa sivu toimii loppukäynnin ajan. Huono INP tässä tilassa on puhdas suoritusaikainen ongelma. Sivu on ladattu loppuun. Jos main thread estää edelleen vuorovaikutusta, syy on JavaScriptin suorituksessa vuorovaikutuksen aikana: tapahtumankäsittelijät tekevät liikaa synkronista työtä, viitekehyksen päivitykset laukaisevat kalliita asettelun uudelleenlaskentoja tai kolmannen osapuolen skriptit ajavat pitkiä tehtäviä jatkuvasti. Korjaus ei liity lykkäämiseen. Kyse on sen työn keventämisestä, mitä tapahtuu, kun käyttäjä todella klikkaa.

Debugging-työnkulku

Vaihe 1: Suodata lataustilan mukaan CoreDashissa. Avaa INP-erittelytaulukko ja ryhmittele lataustilan (Load State) mukaan. Tunnista, mikä tila sisältää suurimman osan huonoista (yli 200 ms) vuorovaikutuksista. Tämä kertoo heti, onko kyseessä latausongelma vai suoritusaikainen ongelma.

Vaihe 2: Ristiinviittaus URL-osoitteen ja laitteen kanssa. Yhdistä lataustila-ulottuvuus URL-ulottuvuuteen löytääksesi ne tietyt sivut, jotka tuottavat huonoja vuorovaikutuksia varhaisissa lataustiloissa. Mobiililaitteet kärsivät suhteettomasti latauksen aikana, koska hitaammat CPU:t pidentävät jokaista pitkää tehtävää.

Vaihe 3: Valitse korjaus tilan mukaan. Jos kyseessä on loading tai dom-interactive, tarkista skriptien latausstrategia Optimize INP -oppaan avulla. Siirrä skriptejä defer-tilaan, poista renderöintiä estävät resurssit ja käytä scheduler.yield()-metodia alkuvaiheen pitkien alustustehtävien pilkkomiseen. Jos kyseessä on complete, profiloi tapahtumankäsittelijäsi Chrome DevToolsissa ja vähennä niiden laukaisemaa synkronista työtä vuorovaikutusta kohden.

Insinöörimäinen peukalosääntö

Jos yli 30 % huonoista INP-vuorovaikutuksistasi on merkitty loading- tai dom-interactive-tunnisteella, INP-ongelmasi on sivun latausongelma ja JavaScriptin lykkääminen tuottaa suurimman parannuksen. Jos yli 60 % huonoista vuorovaikutuksista on merkitty complete-tunnisteella, INP-ongelmasi on suoritusaikainen ongelma ja sinun on optimoitava tapahtumankäsittelijöiden kustannuksia, ei skriptien latausjärjestystä. Lataustila (INP) antaa tämän vastauksen yhdessä taulukkonäkymässä ilman laboratoriotestiä tai mukautettua instrumentointia.