Core/Dash Dimension: Load State (INP)

Dimension: Load State INP (inpls)

Dimensionen Load State (INP) registrerar dokumentets laddningstillstånd vid det exakta ögonblicket då en användarinteraktion fångades. Varje INP-händelse i Chrome User Experience Report har en tagg för laddningstillstånd: antingen loading, dom-interactive, dom-content-loaded eller complete. CoreDash exponerar taggen som en filtrerbar och grupperbar dimension så att du kan svara på frågan som råa INP-värden inte kan: när i sidans livscykel skedde den sämsta interaktionen?

Den frågan är skiljelinjen mellan två helt olika tekniska lösningar. Ett INP-problem som hopar sig under loading kräver en strategi för att skjuta upp JavaScript. Ett INP-problem som hopar sig under complete kräver att du minskar arbetet i händelsehanterarna, reducerar ramverkets overhead eller delar upp long tasks i din kod under körning. Att gruppera efter laddningstillstånd ger dig den uppdelningen helt utan manuell instrumentering.

I data från övervakade sajter i CoreDash är fördelningen av INP-interaktioner per laddningstillstånd ungefär: loading 15 %, dom-interactive 20 %, dom-content-loaded 25 %, complete 40 %. Majoriteten av interaktionerna sker efter att sidan har laddats helt, men de sämsta INP-värdena hopar sig i överväldigande grad i de tidiga tillstånden.

Skärmdump

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

Måttet Interaction to Next Paint mäter den fulla latensen för en användarinteraktion: input delay, händelsehanterarens bearbetningstid och presentation delay till nästa ritade bildruta. Av dessa tre komponenter är input delay den som styrs mest direkt av vad webbläsaren gör i det ögonblick användaren klickar eller trycker.

Under den tidiga sidladdningen är main thread maximalt belastad. Webbläsaren tolkar HTML, kör synkrona skript, bygger CSSOM, kör parser-blockerande resurser och triggar renderingscykler efter varandra. Varje long task på main thread är ett fönster där en användarinteraktion hamnar i kö och väntar. Den väntan är input delay, och det är den dominerande orsaken till dålig INP under sidladdningen.

Interaktioner som sker efter att document.readyState har nått complete möter en lugnare main thread. Webbläsaren är klar med laddningen. Om INP fortfarande är dålig i det skedet beror det inte på trängsel vid laddning. Det är det JavaScript som din sida kör som svar på användarens åtgärden: uppsvällda händelsehanterare, ramverkets omrenderingscykler, layout thrashing triggad av skript, eller ooptimerad tredjepartskod som körs synkront under interaktionen.

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

Laddningstillstånden

loading

Sidan har inte tolkat klart HTML-dokumentet. Main thread kör synkrona skript, hämtar parser-blockerande resurser och bygger den initiala DOM:en. Detta är den mest fientliga miljön för en användarinteraktion. Input delay är som högst eftersom varje long task blockerar webbläsaren direkt från att hantera klicket eller trycket. Användare som interagerar i det här fönstret är vanligtvis de mest otåliga besökarna, eller de med snabba anslutningar som når det synliga innehållet innan sidan har laddat klart. Deras INP-värden är de sämsta du kommer att samla in. Om en betydande andel av dina dåliga INP-händelser har tillståndet loading bör du flytta icke-kritiska skript till defer eller async och eliminera parser-blockerande resurser ovanför vikningen.

dom-interactive

document.readyState blir interactive när HTML-koden är helt tolkad och DOM:en är byggd, men underresurser som bilder, stilmallar och uppskjutna skript fortfarande laddas. Uppskjutna skript börjar köras här, vilket gör att main thread fortfarande kan vara hårt belastad. Hydrering av ramverk startar ofta här. Detta är ett farligt fönster eftersom sidan ser färdig ut för användaren, men main thread är fortfarande upptagen. Input delay förblir förhöjt. Om dålig INP koncentreras hit är åtgärden densamma som för loading: minska mängden synkront arbete som körs direkt efter att DOM-tolkningen är klar.

dom-content-loaded

Händelsen DOMContentLoaded har fyrats av. DOM:en är komplett och uppskjutna skript har körts. De flesta JavaScript-ramverk har slutfört sin initiala hydrering vid det här laget. Belastningen på main thread minskar och interaktioner börjar få snabbare svar. INP-värdena under det här tillståndet är vanligtvis bättre än i de två tidigare, men fortfarande förhöjda jämfört med complete. Om du ser en koncentration av dåliga interaktioner här bör du titta på vad ditt ramverk eller dina applikationsskript gör i händelsehanterare för DOMContentLoaded, och om hydreringsarbetet kan delas upp eller yieldas för att tillåta input-bearbetning mellan tasks.

complete

document.readyState når complete när alla resurser, inklusive bilder, teckensnitt och tredjeparts-iframer, har laddats. Detta är det stabila tillstånd som sidan befinner sig i under resten av sessionen. Dålig INP i detta tillstånd är ett rent problem under körning. Sidan är klar med laddningen. Om main thread fortfarande blockerar interaktioner ligger orsaken i din JavaScript-exekvering under interaktionen: händelsehanterare som gör för mycket synkront arbete, ramverksuppdateringar som triggar dyra layout-omräkningar eller tredjepartsskript som kör long tasks kontinuerligt. Åtgärden handlar inte om att skjuta upp saker. Det handlar om att minska kostnaden för det som sker när användaren faktiskt klickar.

Arbetsflöde för felsökning

Steg 1: Filtrera efter laddningstillstånd i CoreDash. Öppna INP-fördelningstabellen och gruppera efter Load State. Identifiera vilket tillstånd som har den största andelen dåliga interaktioner (över 200 ms). Detta visar direkt om du har att göra med ett laddningsproblem eller ett runtime-problem.

Steg 2: Korsreferera med URL och enhet. Kombinera dimensionen Load State 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 laddningen eftersom långsammare CPU:er förlänger varje long task.

Steg 3: Anpassa åtgärden efter tillståndet. För loading och dom-interactive bör du granska din strategi för skriptladdning med hjälp av guiden Optimize INP. Flytta skript till defer, eliminera render blocking-resurser och använd scheduler.yield() för att dela upp långa initierings-tasks. För complete profilerar du dina händelsehanterare i Chrome DevTools och minskar det synkrona arbetet de triggar per interaktion.

Teknisk tumregel

Om mer än 30 % av dina dåliga INP-interaktioner är taggade med loading eller dom-interactive är ditt INP-problem ett sidladdningsproblem, och uppskjutning av JavaScript kommer att ge den största förbättringen. Om mer än 60 % av de dåliga interaktionerna är taggade med complete är ditt INP-problem ett runtime-problem och du behöver optimera händelsehanterarnas kostnad, inte ordningen för skriptladdning. Load State (INP) ger dig det beskedet direkt i en tabellvy, utan att kräva labbsessioner eller anpassad instrumentering.