Dimensione Core/Dash: Load State (INP)

Dimensione: Load State INP (inpls)

La dimensione Load State (INP) registra lo stato di pronto del documento nel momento esatto in cui è stata catturata un'interazione dell'utente. Ogni evento INP nel Chrome User Experience Report porta con sé un tag relativo allo stato di caricamento: può essere loading, dom-interactive, dom-content-loaded o complete. CoreDash fa emergere quel tag come una dimensione filtrabile e raggruppabile, in modo da poter rispondere alla domanda che i punteggi INP grezzi non possono risolvere: quando è avvenuta l'interazione peggiore durante il ciclo di vita della pagina?

Questa domanda rappresenta la linea di demarcazione tra due soluzioni ingegneristiche completamente diverse. Un problema di INP che si concentra durante la fase di loading richiede una strategia di differimento del JavaScript. Un problema di INP che si concentra durante la fase complete richiede di snellire il lavoro degli event handler, ridurre l'overhead del framework o spezzare i long task nel codice di runtime. Il raggruppamento per stato di caricamento ti fornisce questa divisione senza alcuna strumentazione manuale.

Nei dati di CoreDash dei siti monitorati, la distribuzione delle interazioni INP per stato di caricamento è all'incirca: loading 15%, dom-interactive 20%, dom-content-loaded 25%, complete 40%. La maggior parte delle interazioni avviene dopo che la pagina è completamente caricata, ma i punteggi INP peggiori si concentrano in modo schiacciante nelle fasi iniziali.

Screenshot

Perché il Load State è importante per l'INP

La metrica Interaction to Next Paint misura l'intera latenza di un'interazione dell'utente: input delay, tempo di elaborazione dell'event handler e presentation delay fino al frame dipinto successivo. Di queste tre componenti, l'input delay è quello più direttamente controllato da ciò che il browser sta facendo nel momento in cui l'utente fa clic o tocca lo schermo.

Durante le prime fasi di caricamento della pagina, il main thread è al massimo della contesa. Il browser sta analizzando l'HTML, eseguendo script sincroni, costruendo il CSSOM, eseguendo risorse che bloccano il parser e attivando cicli di rendering in sequenza. Ogni long task sul main thread è una finestra di tempo durante la quale un'interazione dell'utente viene messa in coda e aspetta. Quell'attesa è l'input delay, ed è il fattore dominante dei cattivi punteggi INP durante il caricamento della pagina.

Le interazioni che arrivano dopo che document.readyState raggiunge lo stato complete affrontano un main thread più tranquillo. Il browser ha terminato il caricamento. Se in questa fase l'INP è ancora pessimo, la causa non è la contesa del caricamento. È il JavaScript che la tua pagina esegue in risposta alle azioni dell'utente: event handler sovraccarichi, cicli di re-rendering del framework, layout thrashing scatenato dagli script o codice di terze parti non ottimizzato che viene eseguito in modo sincrono durante l'interazione.

Il load state è il singolo filtro più veloce per separare queste due cause alla radice.

I Load State

loading

La pagina non ha terminato l'analisi del documento HTML. Il main thread sta eseguendo script sincroni, recuperando risorse che bloccano il parser e costruendo il DOM iniziale. Questo è l'ambiente più ostile per l'interazione dell'utente. L'input delay è al massimo perché qualsiasi long task blocca direttamente il browser dall'elaborazione del clic o del tocco. Gli utenti che interagiscono in questa finestra sono in genere i visitatori più impazienti o quelli con connessioni veloci che raggiungono i contenuti visibili prima che la pagina abbia finito di caricarsi. I loro punteggi INP sono i peggiori che raccoglierai. Se una quota significativa dei tuoi scarsi eventi INP porta lo stato loading, sposta gli script non critici in defer o async ed elimina le risorse render-blocking above the fold.

dom-interactive

Il document.readyState raggiunge lo stato interactive quando l'HTML è completamente analizzato e il DOM è costruito, ma le sotto-risorse come immagini, fogli di stile e script differiti sono ancora in fase di caricamento. Gli script differiti iniziano a essere eseguiti a questo punto, il che significa che il main thread può essere ancora pesantemente occupato. L'idratazione del framework spesso inizia qui. Questa è una finestra pericolosa perché la pagina sembra pronta per l'utente, ma il main thread è ancora occupato. L'input delay rimane elevato. Se i cattivi punteggi INP si concentrano qui, la soluzione è la stessa del loading: ridurre il volume del lavoro sincrono che viene eseguito subito dopo il completamento dell'analisi del DOM.

dom-content-loaded

L'evento DOMContentLoaded è stato attivato. Il DOM è completo e gli script differiti sono stati eseguiti. La maggior parte dei framework JavaScript ha terminato il suo passaggio di idratazione iniziale a questo punto. Il carico di lavoro del main thread diminuisce e le interazioni iniziano a ottenere risposte più rapide. I punteggi INP durante questo stato sono in genere migliori rispetto ai due stati precedenti, ma ancora elevati rispetto allo stato complete. Se vedi una concentrazione di interazioni scarse qui, osserva cosa stanno facendo il tuo framework o gli script dell'applicazione negli handler di DOMContentLoaded e verifica se il lavoro di idratazione può essere diviso in chunk o se è possibile fare yielding per consentire l'elaborazione dell'input tra un task e l'altro.

complete

Il document.readyState raggiunge lo stato complete quando tutte le risorse, inclusi immagini, font e iframe di terze parti, sono state caricate. Questo è lo stato stazionario in cui la pagina opera per il resto della sessione. Un INP scarso in questo stato è un puro problema di runtime. La pagina ha finito di caricarsi. Se il main thread sta ancora bloccando le interazioni, la causa è nell'esecuzione del JavaScript durante l'interazione: event handler che svolgono troppo lavoro sincrono, aggiornamenti del framework che innescano costosi ricalcoli del layout o script di terze parti che eseguono costantemente long task. La soluzione non riguarda il differimento. Riguarda la riduzione del costo di ciò che accade quando l'utente fa effettivamente clic.

Flusso di debug

Passo 1: Filtra per load state in CoreDash. Apri la tabella di scomposizione dell'INP e raggruppa per Load State. Identifica quale stato presenta la quota più alta di interazioni scarse (superiori a 200 ms). Questo ti dice immediatamente se sei di fronte a un problema di caricamento o a un problema di runtime.

Passo 2: Esegui un controllo incrociato con URL e dispositivo. Combina la dimensione Load State con la dimensione URL per scoprire quali pagine specifiche generano scarse interazioni durante le prime fasi di caricamento. I dispositivi mobili sono colpiti in modo sproporzionato durante il caricamento perché le CPU più lente allungano ogni long task.

Passo 3: Abbina la soluzione allo stato. Per loading e dom-interactive, controlla la tua strategia di caricamento degli script utilizzando la guida Optimize INP. Sposta gli script in defer, elimina le risorse render-blocking e utilizza scheduler.yield() per suddividere i lunghi task di inizializzazione. Per complete, fai il profiling dei tuoi event handler nei Chrome DevTools e riduci il lavoro sincrono che attivano per ogni interazione.

Regola pratica di ingegneria

Se più del 30% delle tue cattive interazioni INP sono etichettate con loading o dom-interactive, il tuo problema di INP è un problema di caricamento della pagina e il differimento del JavaScript produrrà il miglioramento maggiore. Se più del 60% delle interazioni scarse è etichettato con complete, il tuo problema di INP è un problema di runtime e devi ottimizzare il costo degli event handler, non l'ordine di caricamento degli script. La dimensione Load State (INP) ti permette di prendere questa decisione in un'unica visualizzazione di tabella, senza richiedere una sessione di laboratorio o una strumentazione personalizzata.