Core/Dash-dimensjon: Load State (INP)

Dimensjon: Load State INP (inpls)

Dimensjonen Load State (INP) registrerer dokumentets ready-tilstand på det nøyaktige tidspunktet en brukerinteraksjon ble fanget opp. Hver INP-hendelse i Chrome User Experience Report har en tag for lastetilstand: enten loading, dom-interactive, dom-content-loaded eller complete. CoreDash tilgjengeliggjør denne taggen som en filtrerbar og grupperbar dimensjon, slik at du kan svare på spørsmålet rå INP-skårer ikke kan: når i sidens livssyklus skjedde den dårligste interaksjonen?

Dette spørsmålet er skillelinjen mellom to helt forskjellige tekniske løsninger. Et INP-problem som samler seg under loading, krever en strategi for utsettelse av JavaScript. Et INP-problem som samler seg under complete, krever at du kutter ned på arbeidet i hendelseshåndterere, reduserer rammeverkets overhead eller deler opp long tasks i runtime-koden din. Gruppering etter lastetilstand gir deg denne oppdelingen uten manuell instrumentering.

I CoreDash-data på tvers av overvåkede nettsteder er fordelingen av INP-interaksjoner etter lastetilstand omtrent: loading 15 %, dom-interactive 20 %, dom-content-loaded 25 % og complete 40 %. De fleste interaksjoner skjer etter at siden er fullstendig lastet, men de dårligste INP-skårene samler seg overveldende i de tidlige tilstandene.

Skjermbilde

Hvorfor lastetilstand betyr noe for INP

Metrikken Interaction to Next Paint måler den fulle forsinkelsen til en brukerinteraksjon: input-forsinkelse, behandlingstid for hendelseshåndterere og presentasjonsforsinkelse til neste tegnede ramme. Av disse tre komponentene er input-forsinkelse den som i størst grad styres direkte av hva nettleseren gjør i det øyeblikket brukeren klikker eller trykker.

Under tidlig sidelasting er main thread maksimalt belastet. Nettleseren parser HTML, kjører synkrone skript, bygger CSSOM, kjører parser-blokkerende ressurser og utløser rendringssykluser på løpende bånd. Hver long task på main thread er et tidsvindu der en brukerinteraksjon blir satt i kø og må vente. Denne ventetiden er input-forsinkelse, og den er hoveddriveren bak dårlig INP under sidelasting.

Interaksjoner som oppstår etter at document.readyState har nådd complete, møter en roligere main thread. Nettleseren er ferdig med å laste. Hvis INP fremdeles er dårlig på dette stadiet, skyldes det ikke belastning fra lasting. Det er JavaScript-koden siden din kjører som svar på brukerhandlinger: oppblåste hendelseshåndterere, re-render-sykluser i rammeverket, layout-thrashing utløst av skript eller uoptimalisert tredjepartskode som kjører synkront under interaksjonen.

Lastetilstand er det raskeste filteret for å skille mellom disse to rotårsakene.

Lastetilstandene

loading

Siden er ikke ferdig med å parse HTML-dokumentet. Main thread kjører synkrone skript, henter parser-blokkerende ressurser og bygger den første DOM-en. Dette er det mest ugjestmilde miljøet for brukerinteraksjon. Input-forsinkelsen er på sitt høyeste fordi enhver long task blokkerer nettleseren direkte fra å behandle klikket eller trykket. Brukere som interagerer i dette vinduet, er vanligvis de mest utålmodige besøkende, eller de på raske tilkoblinger som når det synlige innholdet før siden er ferdig lastet. Deres INP-skårer er de dårligste du vil samle inn. Hvis en betydelig andel av dine dårlige INP-hendelser har tilstanden loading, bør du flytte ikke-kritiske skript til defer eller async, og fjerne parser-blokkerende ressurser over bretten.

dom-interactive

document.readyState når interactive når HTML-en er ferdig parset og DOM-en er bygget, men underressurser som bilder, stilark og deferred-skript fremdeles laster. Deferred-skript begynner å kjøre på dette tidspunktet, noe som betyr at main thread fremdeles kan være tungt belastet. Hydrering av rammeverket starter ofte her. Dette er et farlig vindu fordi siden ser klar ut for brukeren, men main thread er fremdeles opptatt. Input-forsinkelsen forblir høy. Hvis dårlig INP konsentrerer seg her, er løsningen den samme som for loading: reduser mengden synkront arbeid som kjører umiddelbart etter at DOM-parsingen er fullført.

dom-content-loaded

DOMContentLoaded-hendelsen har blitt utløst. DOM-en er komplett og deferred-skript har kjørt. De fleste JavaScript-rammeverk har fullført sin første hydreringsrunde på dette tidspunktet. Arbeidsbelastningen på main thread faller, og interaksjoner begynner å få raskere respons. INP-skårer i denne tilstanden er vanligvis bedre enn i de to foregående tilstandene, men fremdeles forhøyet sammenlignet med complete. Hvis du ser en konsentrasjon av dårlige interaksjoner her, må du se på hva rammeverket eller applikasjonsskriptene dine gjør i DOMContentLoaded-hendelseshåndterere, og om hydreringsarbeidet kan deles opp eller yieldes for å tillate input-behandling mellom oppgaver.

complete

document.readyState når complete når alle ressurser, inkludert bilder, fonter og tredjeparts-iframer, er lastet. Dette er normaltilstanden siden opererer i resten av økten. Dårlig INP i denne tilstanden er et rent runtime-problem. Siden er ferdig lastet. Hvis main thread fremdeles blokkerer interaksjoner, ligger årsaken i JavaScript-kjøringen din under interaksjon: hendelseshåndterere som gjør for mye synkront arbeid, rammeverksoppdateringer som utløser dyre layout-rekalkuleringer, eller tredjepartsskript som kjører long tasks kontinuerlig. Løsningen handler ikke om utsettelse. Den handler om å redusere kostnaden for det som faktisk skjer når brukeren klikker.

Arbeidsflyt for feilsøking

Trinn 1: Filtrer etter lastetilstand i CoreDash. Åpne INP-nedbrytingstabellen og grupper etter Load State. Identifiser hvilken tilstand som har den største andelen dårlige interaksjoner (over 200 ms). Dette forteller deg umiddelbart om du står overfor et sidelastingsproblem eller et runtime-problem.

Trinn 2: Kryssreferer med URL og enhet. Kombiner dimensjonen Load State med URL-dimensjonen for å finne ut hvilke spesifikke sider som genererer dårlige interaksjoner under tidlige lastetilstander. Mobilenheter blir uforholdsmessig hardt rammet under lasting fordi tregere CPU-er forlenger hver long task.

Trinn 3: Tilpass løsningen til tilstanden. For loading og dom-interactive bør du revidere strategien for skriptlasting ved hjelp av guiden Optimize INP. Flytt skript til defer, eliminer render blocking-ressurser og bruk scheduler.yield() til å dele opp lange initialiseringsoppgaver. For complete bør du profilere hendelseshåndtererne dine i Chrome DevTools og redusere det synkrone arbeidet de utløser per interaksjon.

Teknisk tommelfingerregel

Hvis mer enn 30 % av de dårlige INP-interaksjonene dine er tagget med loading eller dom-interactive, er INP-problemet ditt et sidelastingsproblem, og utsettelse av JavaScript vil gi den største forbedringen. Hvis mer enn 60 % av de dårlige interaksjonene er tagget med complete, er INP-problemet ditt et runtime-problem, og du må optimalisere kostnaden for hendelseshåndterere, ikke rekkefølgen på skriptlasting. Load State (INP) gir deg det svaret i én enkelt tabellvisning, uten at du trenger en lab-økt eller tilpasset instrumentering.