Core/Dash-dimensie: Laadstatus (INP)

Dimensie: Laadstatus INP (inpls)

De Laadstatus (INP)-dimensie registreert de ready-state van het document op het exacte moment waarop een gebruikersinteractie werd vastgelegd. Elk INP-event in het Chrome User Experience Report bevat een laadstatus-tag: loading, dom-interactive, dom-content-loaded of complete. CoreDash toont die tag als een filterbare, gropeerbare dimensie, zodat je de vraag kunt beantwoorden die ruwe INP-scores niet kunnen beantwoorden: wanneer in de levenscyclus van de pagina vond de slechtste interactie plaats?

Die vraag is de scheidslijn tussen twee totaal verschillende technische oplossingen. Een INP-probleem dat zich concentreert tijdens loading vraagt om een JavaScript-uitstelstrategie. Een INP-probleem dat zich concentreert tijdens complete vraagt om het beperken van eventhandler-werk, het verminderen van framework-overhead of het opknippen van long tasks in je runtime-code. Groeperen op laadstatus geeft je die verdeling zonder handmatige instrumentatie.

In CoreDash-data van gemonitoorde sites is de verdeling van INP-interacties per laadstatus ongeveer: loading 15%, dom-interactive 20%, dom-content-loaded 25%, complete 40%. De meerderheid van de interacties vindt plaats nadat de pagina volledig is geladen, maar de slechtste INP-scores concentreren zich overweldigend in de vroege statussen.

Screenshot

Waarom laadstatus belangrijk is voor INP

De Interaction to Next Paint-metriek meet de volledige latentie van een gebruikersinteractie: input delay, de verwerkingstijd van de eventhandler en de presentation delay naar het volgende gepainte frame. Van die drie componenten wordt de input delay het meest direct bepaald door wat de browser doet op het moment dat de gebruiker klikt of tapt.

Tijdens de vroege laadfase van de pagina is de main thread maximaal bezet. De browser parst HTML, voert synchrone scripts uit, bouwt het CSSOM, verwerkt parser-blocking resources en triggert render-cycli achter elkaar. Elke long task op de main thread is een venster waarin een gebruikersinteractie in de wachtrij wordt geplaatst en wacht. Die wachttijd is de input delay, en dat is de belangrijkste veroorzaker van een slechte INP tijdens het laden van de pagina.

Interacties die plaatsvinden nadat document.readyState de status complete bereikt, treffen een rustigere main thread aan. De browser is klaar met laden. Als de INP in die fase nog steeds slecht is, ligt de oorzaak niet bij drukte tijdens het laden. Het is de JavaScript die je pagina uitvoert als reactie op gebruikersacties: te zware eventhandlers, re-render-cycli van frameworks, layout thrashing getriggerd door scripts, of ongeoptimaliseerde code van derden die synchroon wordt uitgevoerd tijdens de interactie.

Laadstatus is het snelste filter om deze twee bronoorzaken te scheiden.

De laadstatussen

loading

De pagina is nog niet klaar met het parsen van het HTML-document. De main thread voert synchrone scripts uit, haalt parser-blocking resources op en bouwt de initiële DOM. Dit is de meest ongunstige omgeving voor gebruikersinteractie. De input delay is hier het hoogst, omdat elke long task de browser direct blokkeert bij het verwerken van de klik of tap. Gebruikers die in dit venster interactie vertonen, zijn meestal de meest ongeduldige bezoekers of bezoekers met een snelle verbinding die de zichtbare content al zien voordat de pagina klaar is met laden. Hun INP-scores zijn de slechtste die je zult meten. Als een aanzienlijk deel van je slechte INP-events de status loading heeft, verplaats dan niet-kritieke scripts naar defer of async en elimineer parser-blocking resources boven de vouw.

dom-interactive

document.readyState bereikt de status interactive wanneer de HTML volledig is geparst en de DOM is opgebouwd, maar subresources zoals afbeeldingen, stylesheets en uitgestelde scripts nog laden. Uitgestelde scripts worden op dit punt uitgevoerd, waardoor de main thread nog steeds zwaar belast kan zijn. Framework hydration start vaak hier. Dit is een gevaarlijk venster omdat de pagina er klaar uitziet voor de gebruiker, maar de main thread nog steeds bezig is. De input delay blijft verhoogd. Als slechte INP zich hier concentreert, is de oplossing hetzelfde als voor loading: verminder de hoeveelheid synchroon werk dat direct na het voltooien van de DOM-parsing wordt uitgevoerd.

dom-content-loaded

Het DOMContentLoaded-event is afgevuurd. De DOM is compleet en uitgestelde scripts zijn uitgevoerd. De meeste JavaScript-frameworks hebben op dit moment hun eerste hydration-pass voltooid. De belasting van de main thread daalt en interacties krijgen snellere reacties. INP-scores in deze status zijn meestal beter dan in de twee eerdere statussen, maar nog steeds verhoogd vergeleken met complete. Als je hier een concentratie van slechte interacties ziet, kijk dan naar wat je framework- of applicatiescripts doen in DOMContentLoaded-handlers en of hydration-werk kan worden opgeknipt of ge-yield om inputverwerking tussen taken door toe te staan.

complete

document.readyState bereikt de status complete wanneer alle resources, inclusief afbeeldingen, lettertypen en third-party iframes, zijn geladen. Dit is de steady-state waarin de pagina de rest van de sessie functioneert. Een slechte INP in deze status is een puur runtime-probleem. De pagina is klaar met laden. Als de main thread nog steeds interacties blokkeert, ligt de oorzaak bij de uitvoering van je JavaScript tijdens de interactie: eventhandlers die te veel synchroon werk doen, framework-updates die dure lay-out-recalculaties triggeren of third-party scripts die continu long tasks uitvoeren. De oplossing draait hier niet om uitstel. Het gaat om het verminderen van de kosten van wat er gebeurt wanneer de gebruiker daadwerkelijk klikt.

Debugging-workflow

Stap 1: Filter op laadstatus in CoreDash. Open de INP-breakdown-tabel en groepeer op Laadstatus. Identificeer welke status het grootste aandeel slechte interacties (langer dan 200 ms) bevat. Dit vertelt je direct of je te maken hebt met een laadprobleem of een runtime-probleem.

Stap 2: Combineer met URL en apparaat. Combineer de Laadstatus-dimensie met de URL-dimensie om te zien welke specifieke pagina's slechte interacties genereren tijdens vroege laadstatussen. Mobiele apparaten worden onevenredig zwaar getroffen tijdens het laden, omdat tragere CPU's elke long task verlengen.

Stap 3: Stem de oplossing af op de status. Audit voor loading en dom-interactive je scriptlaadstrategie met behulp van de Optimize INP-gids. Verplaats scripts naar defer, elimineer render-blocking resources en gebruik scheduler.yield() om lange initialisatietaken op te knippen. Profileer voor complete je eventhandlers in Chrome DevTools en verminder het synchrone werk dat ze per interactie triggeren.

Technische vuistregel

Als meer dan 30% van je slechte INP-interacties de tag loading of dom-interactive heeft, is je INP-probleem een paginalaadprobleem en levert het uitstellen van JavaScript de grootste verbetering op. Als meer dan 60% van de slechte interacties de tag complete heeft, is je INP-probleem een runtime-probleem en moet je de kosten van eventhandlers optimaliseren, niet de laadvolgorde van scripts. Laadstatus (INP) geeft dat uitsluitsel in één tabelweergave, zonder dat er een lab-sessie of handmatige instrumentatie nodig is.