Un filtro si aggiorna in ritardo, un menu non si apre subito o il testo digitato compare dopo una pausa, anche se la pagina carica velocemente. Per trovare la causa, esamina la risposta all’azione e il lavoro di JavaScript. Nelle applicazioni con Worker o iframe, considera anche lo scambio di messaggi.
Perché un sito veloce potrebbe essere lento nel rispondere alle azioni
Dopo il clic, il browser deve gestire l'evento, eseguire JavaScript e mostrare il frame aggiornato. Se il thread principale è occupato, parte del lavoro attende il suo turno. Pertanto, una buona velocità di caricamento non garantisce una risposta rapida di menu, filtri e moduli.
Spostare i calcoli in un Web Worker può liberare il thread principale, ma richiede uno scambio di dati. La finestra della pagina, i Worker e gli iframe scambiano messaggi tramite postMessage(). Anche un messaggio già inviato può dover attendere l’elaborazione.
Dove si verificano ritardi nella coda dei messaggi
Inizia con tre possibili ragioni:
- Il ricevitore sta eseguendo un'attività sincrona di lunga durata. Il nuovo messaggio verrà elaborato quando il thread sarà libero.
- Ci sono troppi messaggi. Anche gestori brevi creano una coda se il lavoro arriva più velocemente di quanto viene elaborato.
- Viene trasferita una grande quantità di dati. La serializzazione al mittente e la deserializzazione al destinatario richiedono tempo sui rispettivi thread.
Per esempio, una ricerca invia una richiesta al Worker dopo ogni lettera digitata. Se sta ancora calcolando i risultati precedenti, le richieste si accumulano. L’utente ha finito di scrivere, ma l’applicazione elabora ancora il vecchio input. Misura la frequenza dei messaggi, il tempo di elaborazione e il volume di dati scambiati.
Come INP misura la risposta della pagina
INP, Interaction to Next Paint, valuta la reattività a clic, tocchi e pressioni dei tasti durante una visita. Il valore rappresenta una delle interazioni più lente, tenendo conto delle regole di esclusione dei valori anomali. La latenza comprende l’attesa prima dell’elaborazione, l’esecuzione dei gestori e il tempo fino alla visualizzazione del fotogramma successivo.
Un buon valore INP non è superiore a 200 ms. L'intervallo superiore a 200-500 ms richiede miglioramenti, superiore a 500 ms è considerato scarso. Per valutare un sito, il 75° percentile delle visite viene utilizzato separatamente su dispositivi mobili e desktop.
La coda dei messaggi può contribuire a questa latenza quando la sua elaborazione occupa il thread principale e interferisce con l'input o il rendering. Ma il tempo di risposta del Worker non può essere considerato automaticamente INP.
Torniamo alla ricerca: la lettera inserita potrebbe apparire subito, ed i risultati verranno aggiornati successivamente. Il fotogramma successivo è già stato mostrato, anche se il lavoro utile non è ancora stato completato. In tale scenario, misura separatamente la risposta agli input e il tempo necessario per ottenere i risultati effettivi. Un indicatore di caricamento rapido non dimostra che la ricerca stessa sia diventata più veloce.
Controllo INP e analisi JavaScript in Milten
Controllo INP aiuta a indagare sui ritardi di interazione in un'esecuzione di test. Seleziona la pagina con l'azione problematica: menu, catalogo, modulo o carrello. Nel report controlla quali interazioni sono state completate e quali cause di ritardo sono state riscontrate. La conclusione si applica a questa prova e alle sue condizioni.
JS Scanner analizza JavaScript durante il caricamento di una singola pagina in Chromium, senza clic o scorrimento. Mostra dimensioni e carichi degli script, esecuzione del codice, attività a esecuzione prolungata, errori e script con un nome host diverso. Una mappa dei moduli all'interno dei bundle è disponibile se il sito fornisce source map.
Confronta i report per selezionare un'area da ispezionare. Un file pesante in JS Scanner può spiegare il caricamento all'avvio della pagina, ma la sua presenza non dimostra ancora il motivo del clic lento. Il comportamento dopo il caricamento deve essere riprodotto separatamente. Entrambi gli strumenti ti aiutano a restringere la ricerca; non forniscono una traccia di ogni messaggio tra tutte le finestre e i Worker.
Il codice che non è stato eseguito durante il caricamento potrebbe essere necessario dopo un clic o in un altro stato della pagina. Controlla questi script prima di rimuoverli. Anche uno script con un nome host diverso non è necessariamente superfluo: la CDN propria del progetto può rientrare in questo gruppo.
Come trovare la causa di un INP errato
- Registra i passaggi per riprodurre il problema. Specifica lo stato della pagina, del dispositivo e dell'interfaccia. Ad esempio: apri un catalogo, inserisci rapidamente una query, quindi seleziona un filtro.
- Se è presente un RUM o CrUX, usa i dati delle visite reali per selezionare il problema più evidente. La prova di laboratorio non sostituisce le statistiche delle visite reali.
- Esegui un controllo INP e abbina la copertura del rapporto all'attività problematica. Se non è stato riprodotto esaminala separatamente nel browser.
- Esplora il caricamento JavaScript tramite JS Scanner. Seleziona file sospetti e attività lunghe che potrebbero sovrapporsi con ritardo.
- Registra lo scenario problematico in DevTools. Per un Worker o un iframe, tieni traccia del messaggio inviato, dell'elaborazione avviata, della risposta e dell'aggiornamento dello schermo. Gli ID richiesta aiuteranno a distinguere la risposta al vecchio input da quella attuale.
- Dopo aver risolto il problema, ripeti gli stessi passaggi con lo stesso dispositivo, CPU e impostazioni di rete. Confronta più esecuzioni, quindi controlla i dati sul campo man mano che si accumulano.
Cosa modificare per ottimizzare INP
Ottimizzazione dell'INP inizia riducendo il lavoro che ritarda il fotogramma successivo. Riduci i gestori sincroni, suddividi le attività lunghe e lascia che il browser restituisca il feedback prima dei calcoli non necessari.
In un’applicazione con Worker, verifica se tutto il lavoro inviato è necessario. Per le ricerche puoi raggruppare gli aggiornamenti frequenti e scartare i risultati obsoleti. Regola l’intervallo di debounce in base all’interfaccia: se è troppo lungo, ritarda la ricerca stessa.
Riduci i messaggi ai dati necessari al destinatario. Dopo una modifica del filtro, può bastare inviare i parametri della query invece dell’intero catalogo. Per dati binari adatti, valuta gli oggetti trasferibili. Tieni conto del trasferimento di proprietà: il mittente non può più usare il buffer trasferito.
Verifica ciascuna ipotesi separatamente. Se hai ridotto la dimensione del messaggio, confronta il tempo di trasmissione e quello di elaborazione. Se hai spostato il calcolo, controlla la risposta dell'interfaccia e il tempo necessario per ottenere il risultato. Questo mostrerà quale modifica ha aiutato.
È possibile vedere automaticamente il sovraccarico della coda?
La proposta WICG punta ora a estendere l’API Long Animation Frames per rilevare una congestione persistente delle code di task nei documenti e nei Worker. Le misurazioni dei singoli messaggi e dei costi di serializzazione non rientrano nell’ambito attuale.
La proposta è sperimentale. Non basare la diagnostica sui primi esempi di osservazione di delayed-message. Parti da un percorso riproducibile, da INP Scanner, dall’analisi JavaScript e da una registrazione in DevTools. Segui un’azione lenta fino al risultato necessario all’utente.
