Core/Dash-dimensjon: Load State (INP)

Dimensjon: Load State INP (inpls)

Load State (INP)-dimensjonen registrerer dokumentets «ready state» i det nøyaktige øyeblikket en brukerinteraksjon ble fanget opp. Hver INP-hendelse i Chrome User Experience Report bærer en lastestatustag: enten loading, dom-interactive, dom-content-loaded, eller complete. CoreDash fremhever denne taggen som en filtrerbar og grupperbar dimensjon, slik at du kan svare på spørsmålet som rå INP-scorer ikke kan besvare: når i sidens livssyklus skjedde den verste interaksjonen?

Dette spørsmålet er skillelinjen mellom to helt forskjellige tekniske løsninger. Et INP-problem som grupperer seg under loading krever en strategi for å utsette JavaScript (deferral). Et INP-problem som grupperer seg under complete krever trimming av arbeid i hendelseshåndterere, redusering av rammeverk-overhead eller oppdeling av lange oppgaver i runtime-koden din. Å gruppere etter Load State gir deg denne oppdelingen uten noen form for manuell instrumentering.

I CoreDash-data på tvers av overvåkede nettsteder er fordelingen av INP-interaksjoner etter Load State omtrentlig: loading 15 %, dom-interactive 20 %, dom-content-loaded 25 %, complete 40 %. Majoriteten av interaksjonene skjer etter at siden er fullastet, men de verste INP-scorene grupperer seg i overveldende grad i de tidlige fasene.

Skjermbilde

Hvorfor Load State er viktig for INP

Interaction to Next Paint-metrikken måler den fulle forsinkelsen til en brukerinteraksjon: input delay, prosesseringstid for hendelseshåndtereren og presentasjonsforsinkelsen til neste tegnede bilde (frame). Av disse tre komponentene er input delay den som mest direkte kontrolleres av hva nettleseren gjør i det øyeblikket brukeren klikker eller trykker.

Under tidlig sidelasting er hovedtråden under maksimal belastning. Nettleseren analyserer HTML, utfører synkrone skript, bygger CSSOM, kjører parser-blokkerende ressurser og utløser gjengivelsessykluser fortløpende. Hver lange oppgave på hovedtråden er et vindu der en brukerinteraksjon blir satt i kø og må vente. Denne ventetiden er input delay, og det er den dominerende årsaken til dårlig INP under sidelasting.

Interaksjoner som ankommer etter at document.readyState når complete møter en roligere hovedtråd. Nettleseren er ferdig med å laste. Hvis INP fortsatt er dårlig på dette stadiet, er ikke årsaken lastebelastning. Det er JavaScript-koden siden din kjører som respons på brukerhandlinger: oppblåste hendelseshåndterere, re-render-sykluser i rammeverk, layout-thrashing utløst av skript, eller uoptimalisert tredjepartskode som utføres synkront under interaksjonen.

Load State er det desidert raskeste filteret for å skille disse to grunnårsakene fra hverandre.

Load States (Lastestatuser)

loading

Siden er ikke ferdig med å analysere HTML-dokumentet. Hovedtråden utfører synkrone skript, henter parser-blokkerende ressurser og bygger den initielle DOM-en. Dette er det mest fiendtlige miljøet for brukerinteraksjon. Input delay er på sitt høyeste fordi enhver lang oppgave blokkerer nettleseren direkte fra å behandle klikket eller trykket. Brukere som samhandler i dette vinduet er typisk 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-scorer er de verste du vil samle inn. Hvis en betydelig andel av dine dårlige INP-hendelser bærer loading-statusen, flytt ikke-kritiske skript til defer eller async og eliminer parser-blokkerende ressurser over folden (above the fold).

dom-interactive

document.readyState når interactive når HTML-en er fullstendig analysert og DOM-en er bygget, men underressurser som bilder, CSS og utsatte skript fortsatt lastes inn. Utsatte skript begynner å kjøre på dette tidspunktet, noe som betyr at hovedtråden fortsatt kan være tungt okkupert. Rammeverk-hydrering starter ofte her. Dette er et farlig vindu fordi siden ser klar ut for brukeren, men hovedtråden er fortsatt opptatt. Input delay forblir forhøyet. Hvis dårlig INP konsentreres her, er løsningen den samme som for loading: reduser volumet av synkront arbeid som kjører umiddelbart etter at DOM-analysen er fullført.

dom-content-loaded

DOMContentLoaded-hendelsen har utløst. DOM-en er komplett og utsatte skript har kjørt. De fleste JavaScript-rammeverk har fullført sin første hydreringspassering på dette tidspunktet. Arbeidsbelastningen på hovedtråden synker, og interaksjoner begynner å få raskere responser. INP-scorer under denne statusen er typisk bedre enn de to tidligere stadiene, men fortsatt forhøyet sammenlignet med complete. Hvis du ser en konsentrasjon av dårlige interaksjoner her, se på hva rammeverket eller applikasjonsskriptene dine gjør i DOMContentLoaded-håndterere, og om hydreringsarbeid kan deles opp eller bruke yielding for å tillate inputbehandling mellom oppgaver.

complete

document.readyState når complete når alle ressurser, inkludert bilder, skrifttyper og tredjeparts iframes, er lastet inn. Dette er den stabile tilstanden siden opererer i for resten av økten. Dårlig INP på dette stadiet er et rent runtime-problem. Siden er ferdig med å laste. Hvis hovedtråden fortsatt blokkerer interaksjoner, ligger årsaken i din JavaScript-utførelse under interaksjon: hendelseshåndterere som gjør for mye synkront arbeid, rammeverksoppdateringer som utløser dyre layout-rekalkuleringer, eller tredjepartsskript som kjører lange oppgaver kontinuerlig. Løsningen handler ikke om utsettelse. Det handler om å redusere kostnaden av det som skjer når brukeren faktisk klikker.

Arbeidsflyt for feilsøking (Debugging)

Trinn 1: Filtrer etter Load State i CoreDash. Åpne INP-nedbrytningstabellen og grupper etter Load State. Identifiser hvilken status som bærer den høyeste andelen dårlige (over 200ms) interaksjoner. Dette forteller deg umiddelbart om du ser på et lasteproblem eller et runtime-problem.

Trinn 2: Kryssreferer med URL og enhet. Kombiner Load State-dimensjonen med URL-dimensjonen for å finne hvilke spesifikke sider som genererer dårlige interaksjoner under tidlige lastestatuser. Mobile enheter rammes uforholdsmessig hardt under lasting fordi tregere CPU-er forlenger hver eneste lange oppgave.

Trinn 3: Tilpass løsningen til statusen. For loading og dom-interactive, revider strategien din for skriptlasting ved å bruke Optimize INP-guiden. Flytt skript til defer, eliminer render-blokkerende ressurser, og bruk scheduler.yield() for å bryte opp lange initialiseringsoppgaver. For complete, profiler hendelseshåndtererne dine i Chrome DevTools og reduser det synkrone arbeidet de utløser per interaksjon.

Teknisk tommelfingerregel

Hvis mer enn 30 % av dine dårlige INP-interaksjoner er tagget med loading eller dom-interactive, er ditt INP-problem et sidelastingsproblem, og utsettelse av JavaScript vil gi den største forbedringen. Hvis mer enn 60 % av dårlige interaksjoner er tagget med complete, er ditt INP-problem et runtime-problem, og du må optimalisere kostnaden for hendelseshåndtereren, ikke rekkefølgen for lasting av skript. Load State (INP) tar den avgjørelsen i én enkelt tabellvisning, uten å kreve en lab-økt eller tilpasset instrumentering.