Core/Dash-dimension: Load State (INP)

Dimension: Load State INP (inpls)

Load State (INP)-dimensionen registrerer dokumentets klar-tilstand (ready state) i det præcise øjeblik, en brugerinteraktion blev registreret. Hver INP-hændelse i Chrome User Experience Report bærer et load state-tag: enten loading, dom-interactive, dom-content-loaded eller complete. CoreDash synliggør dette tag som en filtrerbar og grupperbar dimension, så du kan besvare det spørgsmål, som rå INP-scorer ikke kan: hvornår i sidelivscyklussen fandt den værste interaktion sted?

Det spørgsmål er skillelinjen mellem to fuldstændig forskellige tekniske løsninger. Et INP-problem, der grupperer sig under loading, kræver en JavaScript deferral-strategi. Et INP-problem, der grupperer sig under complete, kræver at man trimmer event handler-arbejde, reducerer framework-overhead eller opdeler lange opgaver i din runtime-kode. Gruppering efter load state giver dig denne opdeling uden nogen form for 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 fuldt indlæst, men de værste INP-scorer grupperer sig overvejende i de tidlige faser.

Skærmbillede

Hvorfor Load State har betydning for INP

Interaction to Next Paint-metrikken måler den fulde forsinkelse af en brugerinteraktion: input delay, event handler-behandlingstid og presentation delay til den næste optegnede frame. Af disse tre komponenter er input delay den, der mest direkte styres af, hvad browseren foretager sig i det øjeblik, brugeren klikker eller tapper.

Under den tidlige sideindlæsning er main thread under maksimal belastning. Browseren parser HTML, eksekverer synkrone scripts, opbygger CSSOM, kører parser-blokerende ressourcer og udløser render-cyklusser ryg mod ryg. Hver lang opgave på main thread er et vindue, hvor en brugerinteraktion bliver sat i kø og venter. Denne ventetid er input delay, og det er den dominerende årsag til dårlig INP under sideindlæsning.

Interaktioner, der ankommer efter document.readyState når complete, møder en mere stille main thread. Browseren er færdig med at indlæse. Hvis INP stadig er dårlig på dette tidspunkt, er årsagen ikke indlæsningsbelastning. Det er den JavaScript, din side kører som reaktion på brugerhandlinger: tunge event handlers, framework re-render-cyklusser, layout thrashing udløst af scripts, eller uoptimeret tredjepartskode, der eksekverer synkront under interaktionen.

Load state er det absolut hurtigste filter til at adskille disse to grundlæggende årsager.

De forskellige Load States

loading

Siden er ikke færdig med at parse HTML-dokumentet. Main thread eksekverer synkrone scripts, henter parser-blokerende ressourcer og opbygger den indledende DOM. Dette er det mest fjendtlige miljø for brugerinteraktion. Input delay er på sit højeste, fordi enhver lang opgave direkte blokerer browseren fra at behandle klikket eller tappet. Brugere, der interagerer i dette vindue, er typisk de mest utålmodige besøgende eller dem på hurtige forbindelser, som når det synlige indhold, før siden er færdigindlæst. Deres INP-scorer er de værste, du vil indsamle. Hvis en betydelig andel af dine dårlige INP-hændelser har loading-tilstanden, skal du flytte ikke-kritiske scripts til defer eller async og eliminere 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 såsom billeder, stylesheets og deferred scripts stadig indlæses. Deferred scripts begynder at eksekvere 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 har stadig travlt. Input delay 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 fuldført.

dom-content-loaded

DOMContentLoaded-hændelsen er udløst. DOM'en er komplet, og deferred scripts er eksekveret. De fleste JavaScript-frameworks har afsluttet deres indledende hydration-gennemgang på dette tidspunkt. Arbejdsbyrden på main thread falder, og interaktioner begynder at få hurtigere svar. INP-scorer i denne tilstand er typisk bedre end de to tidligere tilstande, men stadig forhøjede sammenlignet med complete. Hvis du ser en koncentration af dårlige interaktioner her, skal du se på, hvad dit framework eller dine applikationsscripts gør i DOMContentLoaded-handlers, og om hydration-arbejde kan opdeles i bidder eller der kan foretages yielding for at tillade inputbehandling mellem opgaver.

complete

document.readyState når complete, når alle ressourcer inklusiv billeder, skrifttyper og tredjeparts-iframes er indlæst. Dette er den stabile tilstand (steady state), siden opererer i for 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-eksekvering under interaktionen: event handlers, der udfører for meget synkront arbejde, framework-opdateringer, der udløser dyre layout-genberegninger, eller tredjepartsscripts, der kører lange opgaver kontinuerligt. Løsningen handler ikke om udskydelse. Det handler om at reducere omkostningerne ved det, der sker, når brugeren rent faktisk klikker.

Fejlfindings-workflow

Trin 1: Filtrer efter load state i CoreDash. Åbn INP-nedbrydningstabellen og grupper efter Load State. Identificer hvilken tilstand der har den højeste andel af dårlige interaktioner (over 200 ms). Dette fortæller dig øjeblikkeligt, om du står over for et indlæsningsproblem eller et runtime-problem.

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

Trin 3: Match løsningen til tilstanden. For loading og dom-interactive skal du gennemgå din strategi for indlæsning af scripts ved hjælp af Optimize INP-guiden. Flyt scripts til defer, eliminer render-blokerende 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 per 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 sideindlæsningsproblem, og udskydelse af JavaScript 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 for event handlers, ikke rækkefølgen for scriptindlæsning. Load State (INP) træffer den beslutning i én enkelt tabelvisning uden at kræve en lab-session eller tilpasset instrumentering.