Core/Dash-dimension: Laddningstillstånd (INP)

Dimension: Laddningstillstånd INP (inpls)

Dimensionen Laddningstillstånd (INP) registrerar dokumentets redo-tillstånd (ready state) i det exakta ögonblick en användarinteraktion fångades. Varje INP-händelse i Chrome User Experience Report bär på en laddningstillståndstagg: antingen loading, dom-interactive, dom-content-loaded eller complete. CoreDash lyfter fram den taggen som en filtreringsbar och grupperingsbar dimension så att du kan svara på frågan som råa INP-poäng inte kan: när i sidans livscykel skedde den värsta interaktionen?

Den frågan utgör skiljelinjen mellan två helt olika tekniska åtgärder. Ett INP-problem som klustras under loading kräver en strategi för att skjuta upp JavaScript. Ett INP-problem som klustras under complete kräver att du trimmar arbetet i händelsehanterare, minskar ramverkets overhead eller bryter upp långa uppgifter (long tasks) i din körningskod. Genom att gruppera efter laddningstillstånd får du den uppdelningen utan någon manuell instrumentering.

I CoreDash-data över övervakade webbplatser är fördelningen av INP-interaktioner efter laddningstillstånd ungefär: loading 15 %, dom-interactive 20 %, dom-content-loaded 25 %, complete 40 %. Majoriteten av interaktionerna sker efter att sidan är helt inladdad, men de sämsta INP-poängen klustras i överväldigande grad i de tidiga stadierna.

Skärmavbild

Varför laddningstillstånd spelar roll för INP

Mätvärdet Interaction to Next Paint mäter den fullständiga latensen för en användarinteraktion: inmatningsfördröjning (input delay), bearbetningstid för händelsehanterare och presentationsfördröjning till nästa renderade bildruta. Av dessa tre komponenter är inmatningsfördröjning den som mest direkt styrs av vad webbläsaren gör i det ögonblick användaren klickar eller trycker.

Under den tidiga sidladdningen är huvudtråden under maximal belastning. Webbläsaren tolkar HTML, exekverar synkrona skript, bygger CSSOM, kör tolk-blockerande resurser och utlöser renderingscykler rygg mot rygg. Varje lång uppgift på huvudtråden är ett fönster under vilket en användarinteraktion läggs i kö och väntar. Den väntan är inmatningsfördröjning, och det är den dominerande drivkraften bakom dålig INP under sidladdning.

Interaktioner som anländer efter att document.readyState når complete möter en lugnare huvudtråd. Webbläsaren har laddat klart. Om INP fortfarande är dålig i det skedet, är orsaken inte belastning från sidladdningen. Det är det JavaScript som din sida kör som svar på användaråtgärder: uppblåsta händelsehanterare, ramverks om-renderingscykler, layout thrashing som utlöses av skript, eller ooptimerad tredjepartskod som exekveras synkront under interaktionen.

Laddningstillståndet är det enskilt snabbaste filtret för att skilja dessa två grundorsaker åt.

Laddningstillstånden

loading

Sidan har inte tolkat klart HTML-dokumentet. Huvudtråden exekverar synkrona skript, hämtar tolk-blockerande resurser och bygger det initiala DOM-trädet. Detta är den mest fientliga miljön för användarinteraktion. Inmatningsfördröjningen är som högst eftersom varje lång uppgift direkt blockerar webbläsaren från att bearbeta klicket eller trycket. Användare som interagerar under det här fönstret är vanligtvis de mest otåliga besökarna eller de med snabba uppkopplingar som når det synliga innehållet innan sidan har laddat klart. Deras INP-poäng är de värsta du kommer att samla in. Om en betydande andel av dina dåliga INP-händelser bär på tillståndet loading, flytta icke-kritiska skript till defer eller async och eliminera tolk-blockerande resurser ovanför den synliga sidvyn.

dom-interactive

document.readyState når interactive när HTML-koden är fullständigt tolkad och DOM-trädet är byggt, men underresurser som bilder, stilmallar och uppskjutna skript fortfarande laddas. Uppskjutna skript börjar exekveras vid den här punkten, vilket innebär att huvudtråden fortfarande kan vara hårt belastad. Hydrering av ramverk börjar ofta här. Detta är ett farligt fönster eftersom sidan ser redo ut för användaren men huvudtråden fortfarande är upptagen. Inmatningsfördröjningen förblir förhöjd. Om dålig INP koncentreras här är lösningen densamma som för loading: minska mängden synkront arbete som körs omedelbart efter att DOM-tolkningen är klar.

dom-content-loaded

Händelsen DOMContentLoaded har utlösts. DOM är komplett och uppskjutna skript har exekverats. De flesta JavaScript-ramverk har slutfört sin initiala hydreringsfas vid den här tidpunkten. Arbetsbelastningen på huvudtråden sjunker, och interaktioner börjar få snabbare svar. INP-poängen under det här tillståndet är vanligtvis bättre än i de två tidigare tillstånden, men fortfarande förhöjda jämfört med complete. Om du ser en koncentration av dåliga interaktioner här, titta på vad ditt ramverk eller dina applikationsskript gör i DOMContentLoaded-hanterare och om hydreringsarbetet kan delas upp i stycken eller utnyttja yield för att tillåta bearbetning av inmatning mellan uppgifter.

complete

document.readyState når complete när alla resurser, inklusive bilder, typsnitt och tredjeparts-iframes, har laddats. Detta är det stabila tillstånd som sidan opererar i under resten av sessionen. Dålig INP i det här tillståndet är ett rent körningsproblem. Sidan har laddat klart. Om huvudtråden fortfarande blockerar interaktioner, ligger orsaken i din JavaScript-exekvering under interaktionen: händelsehanterare som gör för mycket synkront arbete, ramverksuppdateringar som utlöser dyra layoutomberäkningar, eller tredjepartsskript som kör långa uppgifter kontinuerligt. Lösningen handlar inte om att skjuta upp. Det handlar om att minska kostnaden för vad som händer när användaren faktiskt klickar.

Arbetsflöde för felsökning

Steg 1: Filtrera efter laddningstillstånd i CoreDash. Öppna uppdelningstabellen för INP och gruppera efter Laddningstillstånd. Identifiera vilket tillstånd som har den högsta andelen dåliga (över 200 ms) interaktioner. Detta talar omedelbart om för dig om du letar efter ett laddningsproblem eller ett körningsproblem.

Steg 2: Korsreferera med URL och enhet. Kombinera dimensionen för laddningstillstånd med URL-dimensionen för att hitta vilka specifika sidor som genererar dåliga interaktioner under tidiga laddningstillstånd. Mobila enheter påverkas oproportionerligt mycket under laddning eftersom långsammare processorer förlänger varje lång uppgift.

Steg 3: Matcha lösningen mot tillståndet. För loading och dom-interactive, granska din skriptladdningsstrategi med hjälp av Optimize INP-guiden. Flytta skript till defer, eliminera renderingsblockerande resurser och använd scheduler.yield() för att bryta upp långa initieringsuppgifter. För complete, profilera dina händelsehanterare i Chrome DevTools och minska det synkrona arbetet de utlöser per interaktion.

Teknisk tumregel

Om mer än 30 % av dina dåliga INP-interaktioner är taggade som loading eller dom-interactive, är ditt INP-problem ett sidladdningsproblem och att skjuta upp JavaScript kommer att ge den största förbättringen. Om mer än 60 % av dina dåliga interaktioner är taggade som complete, är ditt INP-problem ett körningsproblem och du behöver optimera kostnaden för händelsehanterare, inte ordningen för skriptladdning. Laddningstillstånd (INP) tar det beslutet i en enda tabellvy, utan att kräva en labbsession eller anpassad instrumentering.