Trovare e Risolvere i Problemi di Interaction to Next Paint (INP): Una Guida Passo-Passo
Scopri come identificare e risolvere i problemi di Interaction to Next Paint utilizzando i dati RUM, Chrome DevTools e l'API LoAF
Trovare e Risolvere i Problemi di Interaction to Next Paint (INP)
Questa pagina fa parte della nostra serie sull'Interaction to Next Paint (INP). L'INP misura la reattività del tuo sito web tracciando il ritardo tra un'interazione dell'utente e il successivo aggiornamento visivo. Un buon punteggio INP è inferiore a 200 millisecondi, mentre punteggi superiori a 500 millisecondi sono considerati scarsi. Se sei nuovo all'INP, inizia con la pagina hub dell'INP per una panoramica completa.
In questo articolo illustreremo una metodologia completa per identificare i problemi di Interaction to Next Paint e spiegheremo come risolverli. Il processo prevede la conferma del problema in Google Search Console, la diagnosi delle cause principali con i dati del Real User Monitoring (RUM), la replica delle condizioni a livello locale e l'applicazione di correzioni mirate a ciascuna fase dell'INP.
SUGGERIMENTO INP: la maggior parte delle volte l'INP sarà molto peggiore
quando un utente interagisce con la pagina durante la fase di avvio del caricamento
della pagina. Ecco perché, durante il debugging dell'INP,
ha senso registrare tutte le interazioni così come lo stato di caricamento della pagina!
Table of Contents!
Passaggio 1: Controllare l'INP in Search Console
Il primo passo è confermare di avere effettivamente un problema di INP. Prima di apportare qualsiasi modifica al codice, verifica il problema in Google Search Console in modo da lavorare partendo da dati reali sul campo piuttosto che da supposizioni.
Accedi alla tua Google Search Console. Nel menu a sinistra fai clic su Core Web Vitals e seleziona Dispositivi mobili o Desktop (suggerimento: la maggior parte delle volte i problemi di INP emergono prima sui dispositivi mobili, quindi inizia con i dispositivi mobili).
Qui vedrai una panoramica di tutti i problemi relativi ai Core Web Vitals che sono attualmente presenti sul tuo sito. Se uno di questi problemi è correlato all'INP, hai confermato che c'è un problema.
Passaggio 2: Identificare i problemi di Interaction to Next Paint
Google Search Console non ti fornisce alcuna informazione, a parte i gruppi di URL, per capire cosa sta causando i problemi con l'Interaction to Next Paint. Quindi la maggior parte delle volte gli sviluppatori procedono alla cieca. Iniziano a rimuovere il JavaScript inutilizzato (sempre un'ottima idea) e a suddividere il thread principale (anche questa un'ottima idea), ma questo quasi mai risolve completamente l'INP.
Ecco perché, quando si migliora l'INP, dobbiamo sapere esattamente cosa sta succedendo. Abbiamo bisogno di risposte a quattro domande critiche:
Quali elementi, quando si interagisce con essi, causano un punteggio INP scadente?
Di solito un punteggio INP scadente non è causato da un singolo elemento, ma da una combinazione di problemi. Dobbiamo
affrontarli uno per uno, iniziando dai peggiori e procedendo verso l'alto
.
Quando si verificano queste interazioni? Si verificano
durante la fase di avvio del
caricamento della pagina, oppure si verificano anche quando la pagina principale è completamente caricata?
Dove si verificano queste
interazioni? Si verificano su ogni pagina, o si verificano
solo su alcune pagine selezionate?
Come possiamo replicare
queste interazioni? Potresti aver scoperto a questo punto che
è difficile replicare i problemi di INP. Ecco perché dobbiamo prepararci al successo
imitando le caratteristiche dei dispositivi con un punteggio INP scadente.
Impostare il tracciamento RUM
Per rispondere a tutte queste domande dobbiamo iniziare a tracciare gli utenti reali e registrare qualsiasi problema che
potrebbe verificarsi con l'Interaction to Next Paint. Ci sono diversi modi per abilitare il tracciamento RUM. Il
primo è sfruttare la libreria Web Vitals e inviare i risultati al proprio backend di analisi.
Il vantaggio di questo metodo è che è economico e flessibile. Lo svantaggio è che potrebbe richiedere molto
lavoro aggiuntivo.
Una buona alternativa all'invio dei dati dei Core Web Vitals al tuo backend è utilizzare uno dei tanti strumenti RUM in circolazione. Abbiamo sviluppato CoreDash proprio per questi casi d'uso. CoreDash è uno strumento RUM a basso costo, veloce ed efficace che fa il suo lavoro. Ovviamente ci sono molte soluzioni RUM disponibili che faranno altrettanto bene il lavoro (a un prezzo più alto però).
Trovare interazioni lente per elemento che causano un INP elevato
La prima cosa da fare è trovare le interazioni più lente che causano i peggiori punteggi INP. Elenca le tue pagine per "Metrica INP per Elementi" in CoreDash e otterrai le tue interazioni più lente. Fai clic sulla prima riga per filtrare le tue metriche in base a queste interazioni.
Scoprire quando si verificano interazioni INP negative
Successivamente, ordina gli URL filtrati per stato di caricamento. Questo ti darà maggiori informazioni sulla causa principale dell'INP. In questo caso l'INP elevato si verifica quando il contenuto del DOM è stato caricato. Ciò significa che gli script sono stati analizzati ma gli script asincroni e le risorse secondarie della pagina non sono stati ancora caricati. In questo caso l'INP è causato da clic precoci quando il caricamento della pagina non è completamente terminato.
Continua facendo clic sullo stato di caricamento con l'impatto maggiore per creare un altro filtro.
Trovare gli URL responsabili di punteggi INP elevati
Infine, una volta filtrato per gli elementi con l'interazione più lenta e il corretto stato di caricamento, daremo un'occhiata agli URL in cui l'INP è al suo peggio. In questo caso, ciò avviene chiaramente su un set specifico di pagine.
Individuare le caratteristiche del dispositivo
Una volta identificate le interazioni lente, lo stato di caricamento e gli URL che causano un elevato Interaction to Next Paint, daremo un'occhiata a quali tipi di visitatori causano i peggiori punteggi INP. Noi guarderemmo la memoria del dispositivo, la larghezza di banda, le dimensioni dello schermo e altre caratteristiche hardware. Una volta identificate queste caratteristiche possiamo passare a replicare e registrare il problema.
Utilizzare l'API Long Animation Frames (LoAF) per la diagnostica dell'INP
L'API Long Animation Frames (LoAF) fornisce dati di attribuzione granulari che ti aiutano a individuare esattamente quali script e funzioni sono responsabili delle interazioni lente. A differenza della vecchia API Long Tasks, LoAF fornisce URL degli script, nomi delle funzioni e ripartizione dei tempi per frame. Questo la rende uno strumento inestimabile per il debugging dell'INP, specialmente se combinata con i dati RUM di uno strumento come CoreDash.
Usa il seguente codice per raccogliere le voci LoAF per le interazioni che superano una certa soglia. Questo observer cattura l'attribuzione dello script, la durata e il tempo di blocco per ogni long animation frame:
// Observe Long Animation Frames for INP attribution
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// Only log frames longer than 50ms
if (entry.duration > 50) {
console.log('Long Animation Frame:', {
duration: entry.duration,
blockingDuration: entry.blockingDuration,
renderStart: entry.renderStart,
styleAndLayoutStart: entry.styleAndLayoutStart,
scripts: entry.scripts.map(script => ({
sourceURL: script.sourceURL,
sourceFunctionName: script.sourceFunctionName,
invokerType: script.invokerType,
invoker: script.invoker,
duration: script.duration
}))
});
}
}
});
observer.observe({ type: 'long-animation-frame', buffered: true });
L'API LoAF rivela quali script contribuiscono a ciascuna fase dell'INP. L'array scripts ti indica l'esatto file sorgente e il nome della funzione, mentre renderStart e styleAndLayoutStart ti aiutano a separare il tempo di elaborazione dal ritardo di presentazione. Per una discussione più approfondita su come il caricamento JavaScript async vs defer influisce su queste tempistiche, consulta la nostra guida dedicata.
Passaggio 3: Replicare ed eseguire il debug delle interazioni che causano un punteggio INP elevato
Una volta ottenute tutte le informazioni necessarie, possiamo iniziare ad approfondire i problemi alla base dell'Interaction to Next Paint.
Prepararsi al successo: replicare le circostanze in cui l'INP fallisce
La prossima cosa che dovremmo fare è cercare di ricreare l'INP fallito. Lo facciamo imitando le circostanze in cui l'INP potrebbe fallire.
Utilizzare il pannello Prestazioni di Chrome: Apri gli strumenti per sviluppatori di Chrome (Ctrl+Maiusc+I) e seleziona il
pannello prestazioni. Nella barra in alto puoi selezionare la limitazione della CPU (rallentamento 4x per
emulare un normale dispositivo mobile), la limitazione della rete (seleziona il preset 3G veloce per imitare il tuo
dispositivo mobile medio) e imposta la concorrenza hardware su 4 o 8 per imitare il tuo dispositivo mobile medio.
Per caricare Chrome con meno memoria disponibile (sebbene abbassare l'impostazione di rete e CPU spesso sia sufficiente) avvia Chrome in un contenitore Docker e assegna meno memoria.
Ricaricare la pagina, interagire e controllare l'INP con il visualizzatore Core Web Vitals
Il passaggio successivo per trovare la causa dei punteggi INP negativi consiste nel simulare le condizioni e confermare
che i punteggi INP siano effettivamente negativi come riportato.
Ricarica la pagina e fai clic sull' elemento giusto al momento giusto
Eseguire il debug dell'INP con una traccia delle prestazioni
Questo è il momento per cui ti sei preparato nei passaggi precedenti. È tempo di scoprire perché una determinata interazione sta causando il punteggio scadente di Interaction to Next Paint.
Apri di nuovo la Console per Sviluppatori di Chrome (Ctrl+Maiusc+I), vai al pannello Prestazioni e questa volta fai clic sull'icona della Freccia Circolare per ricaricare la pagina e avviare la registrazione (o usa la scorciatoia Ctrl+Maiusc+E ). Mentre la registrazione è in corso, interagisci con l'elemento che causa il cattivo INP. Dopo alcuni secondi, interrompi la registrazione ed esamina la timeline. Cerca l'evento di interazione nella traccia "Interactions", quindi ispeziona le attività corrispondenti nella traccia "Main" per vedere esattamente quale codice viene eseguito durante ogni fase.
Leggere la traccia delle prestazioni
Nel pannello Prestazioni di Chrome, l'interazione apparirà come una barra colorata nella traccia "Interactions". Fai clic su di essa per vedere la durata totale dell'INP e la sua ripartizione. Sotto, nella traccia "Main", puoi vedere le singole attività che sono state eseguite durante l'interazione. Fai attenzione a:
- Attività prima del gestore eventi: queste contribuiscono all'input delay
- Il gestore eventi stesso: questo è il processing time
- Lavoro di rendering dopo il completamento del gestore: questo è il presentation delay
Confronta questi risultati con i tuoi dati LoAF per confermare che gli script identificati nella traccia corrispondano ai dati di attribuzione del tuo strumento RUM. Questo è anche un buon momento per controllare se eventuali gestori di scorrimento JavaScript stanno contribuendo al problema.
Passaggio 4: Risolvere i problemi di INP
Siamo ora a un punto in cui sappiamo quale interazione sta causando il nostro INP scadente e abbiamo analizzato esattamente cosa sta succedendo durante questa interazione lenta. Ciò significa che è il momento di iniziare a correggere l' Interaction to Next Paint. L'Interaction to Next Paint può essere suddiviso in 3 fasi: input delay, processing time, e presentation delay.
Ogni fase dell'Interaction to Next Paint dovrebbe essere trattata in modo diverso. Di seguito è riportato un riepilogo delle strategie più efficaci per ciascuna fase. Per guide complete all'ottimizzazione, segui i link alle pagine tematiche dedicate.
Ridurre al minimo l'Input Delay:
L'input delay è il tempo che intercorre tra l'interazione con la pagina e il momento in cui inizia l'esecuzione del callback dell'evento. Sebbene ci sia sempre un certo ritardo di input (anche i browser hanno bisogno di tempo per programmare i callback) ci sono diverse cose da considerare:
- Evitare attività lunghe. Ogni volta che viene eseguita un'attività, bloccherà il thread principale e lascerà in attesa i callback degli eventi. Questo è particolarmente importante quando si ottimizzano i clic precoci (poiché la maggior parte degli script sarà in esecuzione in quel momento). Per le strategie su come ridurre il blocco di JavaScript, consulta la nostra guida su JavaScript async vs defer.
- Fare attenzione durante la creazione di nuove attività. Ad esempio, attività ricorrenti tramite
setTimeout()o attività che probabilmente si verificheranno prima dell'evento INP, come i callback sull'eventomouseover. - Misurare e valutare l'interazione precoce. Quando un elemento interattivo viene presentato in anticipo (ad esempio un elemento di ricerca del sito) ed è controllato da JavaScript che si carica in un secondo momento, qualsiasi interazione con l'elemento non innescherà un aggiornamento immediato del layout. Dai la priorità alla funzionalità o nascondi/disabilita l'elemento prima che funzioni correttamente.
- Usare i web worker per eseguire JavaScript fuori dal thread principale del browser. I web worker consentono agli script di essere eseguiti al di fuori del thread principale. Ciò impedirà al thread principale di bloccarsi e causare problemi di input delay nell'INP.
- Caricare gli script di terze parti non essenziali durante il tempo di inattività del browser. Alcuni script sono più critici di altri. Ha senso dare la priorità a questi script e caricare gli script meno importanti durante il tempo di inattività del browser. Ad esempio, uno script di chat. Consulta la nostra guida su 14 metodi per differire JavaScript per tecniche pratiche.
Ridurre al minimo il Processing Time
- Rimuovere il codice non necessario. Il codice non necessario è codice più vecchio che viene ancora eseguito o nuovo codice che non è necessario su questa pagina specifica ma occupa comunque tempo della CPU. Questo è di gran lunga il modo più semplice per migliorare immediatamente l'INP.
- Differire il codice che non deve essere eseguito prima del prossimo paint. Suddividi il codice in codice critico che deve essere eseguito prima dell'INP e codice non critico (ad esempio l'invio di analisi) e programmalo dopo l'evento paint con il metodo
requestIdleCallback(). - Ottimizzare il codice che deve essere eseguito prima del paint. Controlla il tuo codice e riscrivi le parti lente o inefficaci.
- Fornire un feedback immediato. In caso di attività complicate o potenzialmente lente, fornisci un feedback immediato prima di eseguire il codice principale.
Ridurre al minimo il Presentation Delay
- Mantenere il DOM piccolo e semplice. Sarà molto più semplice per un browser eseguire il rendering di una pagina con elementi DOM (nodi HTML) pochi, semplici e non annidati, rispetto al rendering di una pagina con molti nodi DOM annidati. Leggi di più su come risolvere le dimensioni eccessive del DOM.
- Usare content-visibility per il rendering pigro dei contenuti fuori schermo. Content-visibility accelererà il rendering delle parti visibili della pagina ritardando il rendering dei contenuti fuori schermo ed eseguendone il rendering solo al momento necessario.
Soluzione rapida: cedere il passo al thread principale con scheduler.yield()
Una delle tecniche più efficaci per migliorare l'INP in tutte e tre le fasi è cedere il passo al thread principale tra il lavoro critico e quello non critico. L'API scheduler.yield() fornisce un modo pulito per farlo. Ecco una funzione di supporto riutilizzabile con un fallback per i browser che non supportano ancora l'API:
async function yieldToMain() {
if ('scheduler' in window && 'yield' in window.scheduler) {
return await window.scheduler.yield();
}
return new Promise((resolve) => {
setTimeout(resolve, 0);
});
}
// Usage in an event handler
async function handleButtonClick() {
// Critical work: update the UI
updateVisualFeedback();
// Yield to let the browser paint
await yieldToMain();
// Non-critical work: analytics, logging
sendAnalyticsEvent('button_click');
logInteraction();
}
Approfondimento su ogni fase dell'INP
Ora che sai come identificare e risolvere i problemi di INP, esplora ogni fase in dettaglio:
- Input Delay: Scopri come ridurre al minimo il tempo che intercorre tra l'interazione dell'utente e l'inizio dell'elaborazione dell'evento. L'input delay rappresenta circa il 18% del tempo totale dell'INP.
- Processing Time: Ottimizza l'esecuzione del gestore di eventi, che rappresenta circa il 40% del tempo totale dell'INP.
- Presentation Delay: Riduci il lavoro di rendering e painting, che rappresenta circa il 42% del tempo totale dell'INP.
Per ulteriori strategie che si estendono su tutte e tre le fasi, consulta le nostre guide su come migliorare l'INP abbandonando lo scorrimento JavaScript e come scegliere async vs defer per il tuo JavaScript.
Ask AI why your INP spiked.
CoreDash is the only RUM tool with MCP support. Connect it to your AI agent and query your Core Web Vitals data in natural language. No more clicking through dashboards.
See How It Works
