Core/Dash-dimension: Load State (INP)

Dimension: Load State INP (inpls)

Dimensionen Load State (INP) registrerer dokumentets indlæsningstilstand på det præcise tidspunkt, hvor en brugerinteraktion blev registreret. Hver INP-hændelse i Chrome User Experience Report har et load state-tag: enten loading, dom-interactive, dom-content-loaded eller complete. CoreDash viser dette tag som en dimension, der kan filtreres og grupperes, så du kan besvare det spørgsmål, som rå INP-scorer ikke kan: hvornår i sidens livscyklus skete den værste interaktion?

Det spørgsmål trækker grænsen mellem to helt forskellige tekniske løsninger. Et INP-problem, der koncentrerer sig under loading, kræver en strategi for JavaScript-udskydelse. Et INP-problem, der koncentrerer sig under complete, kræver derimod at man reducerer arbejdet i event handlers, mindsker framework-overhead eller opdeler long tasks i sin runtime-kode. Gruppering efter load state giver dig den opdeling helt uden manuel instrumentering.

I CoreDash-data på tværs af overvågede sites er fordelingen af INP-interaktioner efter load state omtrent: loading 15 %, dom-interactive 20 %, dom-content-loaded 25 %, complete 40 %. Størstedelen af interaktionerne sker, efter siden er helt indlæst, men de værste INP-scorer koncentrerer sig i overvældende grad i de tidlige tilstande.

Screenshot

Hvorfor Load State er vigtig for INP

Metrikken Interaction to Next Paint måler den fulde latenstid for en brugerinteraktion: inputforsinkelse, event handler-behandlingstid og præsentationsforsinkelse til den næste frame, der tegnes. Ud af de tre komponenter er inputforsinkelsen den, der er mest direkte påvirket af, hvad browseren foretager sig i det øjeblik, brugeren klikker eller trykker.

Under den tidlige indlæsning af siden er main thread maksimalt belastet. Browseren parser HTML, afvikler synkrone scripts, bygger CSSOM, afvikler parser-blokerende ressourcer og udløser render-cyklusser lige efter hinanden. Enhver long task på main thread er et vindue, hvor en brugerinteraktion bliver sat i kø og venter. Den ventetid er inputforsinkelse, og den er den dominerende årsag til dårlig INP under indlæsning af siden.

Interaktioner, der sker, efter document.readyState når complete, møder en mere rolig main thread. Browseren er færdig med at indlæse. Hvis INP stadig er dårlig på det tidspunkt, er årsagen ikke ressourcekamp under indlæsning. Det er den JavaScript, din side afvikler som reaktion på brugerhandlinger: oppustede event handlers, framework-re-render-cyklusser, layout thrashing udløst af scripts eller uoptimeret tredjepartskode, der afvikles synkront under interaktionen.

Load state is the single fastest filter for separating those two root causes.

De forskellige load states

loading

Siden er ikke færdig med at parse HTML-dokumentet. Main thread afvikler synkrone scripts, henter parser-blokerende ressourcer og bygger den indledende DOM. Dette er det mest fjendtlige miljø for brugerinteraktion. Inputforsinkelsen er på sit højeste, fordi enhver long task direkte blokerer browseren i at behandle klikket eller trykket. Brugere, der interagerer i dette vindue, er typisk de mest utålmodige besøgende eller brugere på hurtige forbindelser, som når det synlige indhold, før siden er færdig med at indlæse. Deres INP-scorer er de værste, du vil registrere. Hvis en betydelig del af dine dårlige INP-hændelser har tilstanden loading, bør du flytte ikke-kritiske scripts to defer eller async og fjerne parser-blokerende ressourcer over folden.

dom-interactive

document.readyState når interactive, når HTML'en er fuldt parset og DOM'en er bygget, men underressourcer som billeder, stylesheets og deferred scripts stadig indlæses. Deferred scripts begynder at køre på dette tidspunkt, hvilket betyder, at main thread stadig kan være stærkt optaget. Framework-hydration starter ofte her. Dette er et farligt vindue, fordi siden ser klar ud for brugeren, men main thread er stadig optaget. Inputforsinkelsen forbliver forhøjet. Hvis dårlig INP koncentrerer sig her, er løsningen den samme som for loading: Reducer mængden af synkront arbejde, der kører umiddelbart efter, at DOM-parsingen er afsluttet.

dom-content-loaded

Hændelsen DOMContentLoaded er blevet udløst. DOM'en er komplet, og deferred scripts er blevet afviklet. De fleste JavaScript-frameworks har afsluttet deres indledende hydration-fase på dette tidspunkt. Arbejdsbelastningen på main thread falder, og interaktioner begynder at få hurtigere svar. INP-scorer under denne tilstand er typisk bedre end under de to tidligere tilstande, men stadig forhøjede sammenlignet med complete. Hvis du ser en koncentration af dårlige interaktioner her, bør du undersøge, hvad dit framework eller dine applikationsscripts gør i event handlers for DOMContentLoaded, og om hydration-arbejdet kan opdeles i mindre bidder eller yieldes for at tillade behandling af input mellem opgaverne.

complete

document.readyState når complete, når alle ressourcer, herunder billeder, skrifttyper og tredjeparts-iframes, er indlæst. Dette er den stabile tilstand, som siden befinder sig i under resten af sessionen. Dårlig INP i denne tilstand er et rent runtime-problem. Siden er færdig med at indlæse. Hvis main thread stadig blokerer interaktioner, ligger årsagen i din JavaScript-afvikling under interaktionen: event handlers, der udfører for meget synkront arbejde, framework-opdateringer, der udløser dyre genberegninger af layout, eller tredjepartsscripts, der kører long tasks kontinuert. Løsningen handler ikke om udskydelse (deferral). Det handler om at reducere omkostningerne ved det, der sker, når brugeren rent faktisk klikker.

Debugging-workflow

Trin 1: Filtrer efter load state i CoreDash. Åbn INP-nedbrydningstabellen, og grupper efter Load State. Find ud af, hvilken tilstand der har den største andel af dårlige interaktioner (over 200 ms). Det viser dig med det samme, om du står over for et indlæsningsproblem eller et runtime-problem.

Trin 2: Krydsreferér med URL og enhed. Kombiner dimensionen Load State med URL-dimensionen for at finde frem til, hvilke specifikke sider der genererer dårlige interaktioner under de tidlige indlæsningstilstande. Mobiltelefoner påvirkes uforholdsmæssigt meget under indlæsning, fordi langsommere CPU'er forlænger enhver long task.

Trin 3: Match løsningen til tilstanden. For loading og dom-interactive skal du gennemgå din strategi for script-indlæsning ved hjælp af guiden Optimize INP. Flyt scripts til defer, fjern render-blocking ressourcer, og brug scheduler.yield() til at opdele lange initialiseringsopgaver. For complete skal du profilere dine event handlers i Chrome DevTools og reducere det synkrone arbejde, de udløser pr. interaktion.

Teknisk tommelfingerregel

Hvis mere end 30 % af dine dårlige INP-interaktioner er tagget med loading eller dom-interactive, er dit INP-problem et problem med indlæsning af siden, og JavaScript-udskydelse vil give den største forbedring. Hvis mere end 60 % af de dårlige interaktioner er tagget med complete, er dit INP-problem et runtime-problem, og du skal optimere omkostningerne ved event handlers, ikke script-indlæsningsrækkefølgen. Load State (INP) afgør dette i en enkelt tabelvisning uden krav om en lab-session eller tilpasset instrumentering.