CoreDash Dimensie: Load State (INP)

Dimensie: Load State INP (inpls)

De Load State (INP) dimensie legt de document ready state vast op het exacte moment dat een gebruikersinteractie werd geregistreerd. Elke INP-gebeurtenis in het Chrome User Experience Report bevat een load state tag: een van de volgende: loading, dom-interactive, dom-content-loaded, of complete. CoreDash presenteert die tag als een filterbare, groepeerbare dimensie, zodat u de vraag kunt beantwoorden die ruwe INP-scores niet kunnen: wanneer in de levenscyclus van de pagina vond de slechtste interactie plaats?

Die vraag vormt de scheidslijn tussen twee volledig verschillende technische oplossingen. Een INP-probleem dat zich concentreert tijdens loading vraagt om een JavaScript uitstelstrategie (deferral strategy). Een INP-probleem dat zich concentreert tijdens complete vraagt om het inkorten van het werk in event handlers, het verminderen van framework overhead, of het opbreken van lange taken in uw runtime-code. Groeperen op load state geeft u die uitsplitsing zonder enige handmatige instrumentatie.

In CoreDash-data over gemonitorde sites is de verdeling van INP-interacties per load state 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 stadia.

Screenshot

Waarom Load State belangrijk is voor INP

De Interaction to Next Paint metriek meet de volledige latentie van een gebruikersinteractie: input delay, verwerkingstijd van de event handler, en de presentation delay tot het volgende getoonde (painted) frame. Van die drie componenten is de input delay degene die het meest direct wordt beïnvloed door wat de browser aan het doen is op het moment dat de gebruiker klikt of tikt.

Tijdens het vroege laden van de pagina is de main thread maximaal bezet. De browser is bezig met het parsen van HTML, het uitvoeren van synchrone scripts, het opbouwen van het CSSOM, het uitvoeren van parser-blocking resources en het achter elkaar triggeren van render-cycli. Elke lange taak op de main thread is een venster waarin een gebruikersinteractie in de wachtrij wordt geplaatst en moet wachten. Dat wachten is de input delay, en het is de dominante oorzaak van een slechte INP tijdens het laden van de pagina.

Interacties die plaatsvinden nadat document.readyState de status complete heeft bereikt, treffen een rustigere main thread aan. De browser is klaar met laden. Als de INP in dat stadium nog steeds slecht is, is de oorzaak niet de belasting door het laden. Het is de JavaScript die uw pagina uitvoert in reactie op gebruikersacties: opgeblazen event handlers, framework re-render cycli, layout thrashing getriggerd door scripts, of niet-geoptimaliseerde code van derden die synchroon wordt uitgevoerd tijdens de interactie.

Load state is het snelste filter om die twee hoofdoorzaken van elkaar te scheiden.

De Load States

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 op. Dit is de meest vijandige omgeving voor gebruikersinteractie. De input delay is hier op zijn hoogst omdat elke lange taak de browser direct blokkeert bij het verwerken van de klik of tik. Gebruikers die tijdens dit venster interactie hebben, zijn meestal de meest ongeduldige bezoekers of bezoekers met een snelle verbinding die de zichtbare inhoud bereiken voordat de pagina klaar is met laden. Hun INP-scores zijn de slechtste die u zult verzamelen. Als een aanzienlijk deel van uw slechte INP-gebeurtenissen 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 interactive wanneer de HTML volledig is geparst en de DOM is opgebouwd, maar subresources zoals afbeeldingen, stylesheets en uitgestelde scripts nog steeds aan het laden zijn. Uitgestelde scripts beginnen op dit punt met uitvoeren, wat betekent dat de main thread nog steeds zwaar bezet kan zijn. Framework hydration begint vaak hier. Dit is een gevaarlijk venster omdat de pagina er voor de gebruiker klaar uitziet, maar de main thread nog steeds druk is. De input delay blijft hoog. Als de slechte INP zich hier concentreert, is de oplossing dezelfde als voor loading: verminder het volume aan synchroon werk dat onmiddellijk na het voltooien van de DOM-parsing wordt uitgevoerd.

dom-content-loaded

De DOMContentLoaded gebeurtenis is afgevuurd. De DOM is compleet en uitgestelde scripts zijn uitgevoerd. De meeste JavaScript-frameworks hebben hun initiële hydration-ronde op dit punt voltooid. De werklast van de main thread daalt en interacties beginnen snellere reacties te krijgen. INP-scores tijdens deze status zijn doorgaans beter dan de twee eerdere statussen, maar nog steeds verhoogd vergeleken met complete. Als u hier een concentratie van slechte interacties ziet, kijk dan naar wat uw framework of applicatie-scripts doen in DOMContentLoaded handlers en of hydration-werk kan worden opgesplitst of geyield (yielding) om input-verwerking tussen taken door mogelijk te maken.

complete

document.readyState bereikt complete wanneer alle bronnen, inclusief afbeeldingen, lettertypen en iframes van derden, zijn geladen. Dit is de stabiele status waarin de pagina de rest van de sessie verkeert. Een slechte INP bij deze status is een puur runtime-probleem. De pagina is klaar met laden. Als de main thread interacties nog steeds blokkeert, ligt de oorzaak in uw JavaScript-uitvoering tijdens de interactie: event handlers die te veel synchroon werk doen, framework-updates die dure layout-recalculaties triggeren, of scripts van derden die continu lange taken uitvoeren. De oplossing gaat niet over uitstel. Het gaat over het verminderen van de kosten van wat er gebeurt wanneer de gebruiker daadwerkelijk klikt.

Hulp bij het Debuggen

Stap 1: Filter op load state in CoreDash. Open de INP-specificatietabel en groepeer op Load State. Identificeer welke status het grootste aandeel slechte interacties (boven 200ms) bevat. Dit vertelt u onmiddellijk of u te maken hebt met een laadprobleem of een runtime-probleem.

Stap 2: Kruisverwijzing met URL en apparaat. Combineer de Load State dimensie met de URL dimensie om te ontdekken welke specifieke pagina's slechte interacties genereren tijdens vroege laadstadia. Mobiele apparaten worden onevenredig zwaar getroffen tijdens het laden omdat tragere CPU's elke lange taak verlengen.

Stap 3: Stem de oplossing af op de status. Voor loading en dom-interactive controleert u uw script-laadstrategie met behulp van de Optimize INP gids. Verplaats scripts naar defer, elimineer render-blocking resources en gebruik scheduler.yield() om lange initialisatietaken op te breken. Voor complete profileert u uw event handlers in Chrome DevTools en vermindert u het synchrone werk dat ze per interactie triggeren.

Insinöörimäinen peukalosääntö

Als meer dan 30% van uw slechte INP-interacties de tag loading of dom-interactive heeft, is uw INP-probleem een paginalaad-probleem en zal het uitstellen van JavaScript de grootste verbetering opleveren. Als meer dan 60% van de slechte interacties de tag complete heeft, is uw INP-probleem een runtime-probleem en moet u de kosten van de event handler optimaliseren, niet de volgorde van het laden van scripts. Load State (INP) maakt die afweging in één tabelweergave, zonder dat een lab-sessie of aangepaste instrumentatie nodig is.