Identificare e risolvere i problemi di Interaction to Next Paint (INP): Guida passo dopo passo

Passaggio 1: Controlla l'INP in Search Console

Il primo passo è confermare di avere effettivamente un problema di INP. Prima di apportare modifiche al codice, verifica il problema in Google Search Console in modo da lavorare su dati reali del campo piuttosto che su supposizioni.

Accedi alla tua Google Search Console. Nel menu a sinistra clicca su Core Web Vitals e seleziona Mobile o Desktop (consiglio: la maggior parte delle volte i problemi di INP emergono prima su mobile, quindi inizia da lì).

Qui vedrai una panoramica di tutti i problemi relativi ai Core Web Vitals attualmente presenti sul tuo sito. Se uno di questi problemi è relativo all'INP, hai la conferma che c'è un problema.

Passaggio 2: Identifica i problemi di Interaction to Next Paint

Google Search Console non fornisce alcuna informazione, a parte i gruppi di URL, per capire cosa stia 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 frazionare il thread principale (anch'essa un'ottima idea), ma questo raramente risolve completamente l'INP.

Ecco perché, per migliorare 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? In genere un punteggio INP scadente non è causato da un singolo elemento ma da una combinazione di problemi. Dobbiamo affrontarli uno per uno, partendo dai peggiori e procedendo verso l'alto.
Quando avvengono queste interazioni? Avvengono durante la fase di avvio del caricamento della pagina o accadono anche quando la pagina principale è stata completamente caricata?
Dove avvengono queste interazioni? Avvengono su ogni pagina o accadono solo su alcune pagine selezionate?
Come possiamo replicare queste interazioni? Potresti aver scoperto che è difficile replicare i problemi di INP. Ecco perché dobbiamo metterci nelle condizioni di avere successo imitando le caratteristiche dei dispositivi con un punteggio INP scadente.

Configura il tracciamento RUM

Per rispondere a tutte queste domande dobbiamo iniziare a tracciare gli utenti reali e loggare qualsiasi problema che potrebbe verificarsi con l'Interaction to Next Paint. Esistono diversi modi per abilitare il tracciamento RUM. Il primo consiste nell'utilizzare la libreria Web Vitals e inviare i risultati al proprio backend di analytics. Il vantaggio di questo metodo è che è economico e flessibile. Lo svantaggio è che potrebbe richiedere molto lavoro extra.

Una valida alternativa all'invio dei dati dei Core Web Vitals al proprio backend è l'utilizzo di uno dei numerosi strumenti RUM disponibili. Abbiamo sviluppato [url=https:\/\/coredash.app]CoreDash[\/url] proprio per questi casi d'uso. CoreDash è uno strumento RUM economico, veloce ed efficace che fa il suo dovere. Naturalmente esistono molte soluzioni RUM sul mercato e anche queste faranno il loro lavoro (anche se a un prezzo più elevato).

Trova le interazioni lente per elemento che causano un INP elevato

Inizia trovando le interazioni più lente che causano i peggiori punteggi INP. Elenca le tue pagine per "INP metric by Elements" in CoreDash e otterrai le interazioni più lente. Clicca sulla prima riga per filtrare le tue metriche in base a queste interazioni.

Scopri quando si verificano interazioni INP scadenti

Successivamente, ordina gli URL filtrati per stato di caricamento (load state). 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 i componenti asincroni e le sottorisorse della pagina non sono ancora stati caricati. In questo caso l'INP è causato da clic precoci quando il caricamento della pagina non è terminato completamente.

Continua cliccando sullo stato di caricamento con l'impatto più elevato per creare un altro filtro.

Trova gli URL responsabili di punteggi INP elevati

Infine, dopo aver filtrato per gli elementi con l'interazione più lenta e lo stato di caricamento corretto, daremo un'occhiata agli URL dove l'INP è al suo peggio. In questo caso ciò accade chiaramente su un set specifico di pagine.

Trova le caratteristiche del dispositivo

Una volta identificati le interazioni lente, lo stato di caricamento e gli URL che causano un Interaction to Next Paint elevato, osserveremo quali tipi di visitatori causano i peggiori punteggi INP. Esamineremo la memoria del dispositivo, la larghezza di banda, le dimensioni dello schermo e altre caratteristiche hardware. Una volta identificate queste caratteristiche, possiamo passare alla replica e al log del problema.

Utilizzo dell'API Long Animation Frames (LoAF) per la diagnostica INP

L'API Long Animation Frames (LoAF) indica esattamente quali script e funzioni causano interazioni lente. A differenza della vecchia API Long Tasks, LoAF fornisce URL degli script, nomi delle funzioni e analisi dei tempi per frame. È particolarmente utile se combinata con i dati RUM di uno strumento come [url=https:\/\/coredash.app]CoreDash[\/url].

Questo osservatore raccoglie le voci LoAF per i frame più lunghi di 50 ms, catturando l'attribuzione dello script, la durata e il tempo di blocco:

\/\/ Osserva i Long Animation Frames per l'attribuzione INP
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    \/\/ Logga solo i frame più lunghi di 50 ms
    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 indica il file sorgente esatto e il nome della funzione, mentre renderStart e styleAndLayoutStart aiutano a separare il tempo di elaborazione dal ritardo di presentazione. Al momento LoAF è disponibile solo su Chromium (Chrome 123+), quindi per il debug su Firefox e Safari, affidati invece alla traccia del pannello Performance e ai dati RUM. Per saperne di più su come il caricamento [url=\/pagespeed\/async-vs-defer-javascript-and-core-web-vitals]JavaScript asincrono rispetto a quello differito (defer) influisce su questi tempi, consulta la nostra guida dedicata.

            

                Passaggio 3: Replica ed esegui il debug delle interazioni che causano un punteggio INP elevato
            

            
Con questi dati in mano, possiamo iniziare a correggere le cause principali.
            
Preparati al successo: replica le circostanze del fallimento dell'INP
            
La prossima cosa da fare è cercare di ricreare l'INP fallimentare. Lo facciamo imitando le circostanze in cui l'INP potrebbe fallire.
            
Usa il pannello Performance di Chrome: apri gli strumenti per sviluppatori di Chrome (Ctrl+Shift+I) e seleziona il pannello Performance. Nella barra in alto puoi selezionare il CPU Throttle (impostalo su un rallentamento di 4x per emulare un normale dispositivo mobile), il Network Throttle (seleziona il preset "Fast 3G" per imitare un dispositivo mobile medio) e imposta la hardware concurrency a 4 o 8 per imitare un dispositivo mobile medio.
Per caricare Chrome con meno memoria disponibile (anche se abbassare le impostazioni di rete e CPU spesso è sufficiente), avvia Chrome in un container Docker e assegna meno memoria.
Ricarica la pagina, interagisci e controlla l'INP con il visualizzatore Core Web Vitals
            
Ora simula le condizioni e conferma che i punteggi INP corrispondano a quanto riportato dai tuoi dati RUM.
Ricarica la pagina e clicca sull'elemento giusto al momento giusto
Esegui il debug dell'INP con una traccia delle prestazioni
            
Questo è il momento che hai preparato nei passaggi precedenti. È tempo di scoprire perché una certa interazione sta causando il cattivo punteggio di Interaction to Next Paint.
            
Apri la console per sviluppatori di Chrome (Ctrl+Shift+I), naviga nel pannello Performance e questa volta clicca sull'icona della freccia circolare per ricaricare la pagina e avviare la registrazione (o usa la scorciatoia Ctrl+Shift+E). Mentre la registrazione è in corso, interagisci con l'elemento che causa il cattivo INP. Dopo alcuni secondi, ferma 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 Performance di Chrome, l'interazione apparirà come una barra colorata nella traccia "Interactions". Cliccaci sopra per vedere la durata totale dell'INP e la sua scomposizione. Sotto, nella traccia "Main", puoi vedere le singole attività eseguite durante l'interazione. Presta attenzione a:
            
Attività prima dell'event handler: queste contribuiscono al ritardo di input (input delay)
                
L'event handler stesso: questo è il tempo di elaborazione (processing time)
                
Lavoro di rendering dopo il completamento dell'handler: questo è il ritardo di presentazione (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 [url=\/pagespeed\/improve-inp-ditch-javascript-scrolling]scroll handler JavaScript[\/url] stiano contribuendo al problema.

            

                Passaggio 4: Risolvi i problemi di INP
            

            
Sai quale interazione è lenta e perché. È ora di risolverla. L'Interaction to Next Paint può essere scomposto in 3 fasi: [url=\/core-web-vitals\/interaction-to-next-paint\/input-delay]input delay[\/url], [url=\/core-web-vitals\/interaction-to-next-paint\/processing-time]processing time[\/url] e [url=\/core-web-vitals\/interaction-to-next-paint\/presentation-delay]presentation delay[\/url].
            
Ogni fase richiede un approccio diverso. Ecco un riepilogo. Segui i link per le guide complete all'ottimizzazione.

            
Ridurre al minimo il ritardo di input (Input Delay):
Il [url=\/core-web-vitals\/interaction-to-next-paint\/input-delay]ritardo di input[\/url] è il tempo che intercorre tra l'interazione con la pagina e il momento in cui la callback dell'evento inizia a essere eseguita. Sebbene un certo ritardo di input sia inevitabile (i browser hanno bisogno di tempo per programmare le callback), puoi ridurlo al minimo:
            
Evita i Long Tasks. Ogni volta che un'attività è in esecuzione, bloccherà il thread principale e lascerà le callback degli eventi in attesa. Questo è particolarmente importante quando si ottimizzano i clic precoci (poiché la maggior parte degli script sarà in esecuzione in quel momento). Per strategie su come ridurre il blocco JavaScript, consulta la nostra guida su [url=\/pagespeed\/async-vs-defer-javascript-and-core-web-vitals]JavaScript asincrono rispetto a differito[\/url].
                
Fai attenzione quando crei nuove attività. Ad esempio, attività ricorrenti tramite setTimeout() o attività che probabilmente si verificheranno prima dell'evento INP come le callback sull'evento mouseover.
                
Misura e valuta l'interazione precoce. Quando un elemento interattivo viene presentato presto (ad esempio un elemento di ricerca nel sito) ed è controllato da JavaScript che viene caricato successivamente, qualsiasi interazione con l'elemento non innescherà un aggiornamento immediato del layout. Dai priorità alla funzionalità oppure nascondi\/disabilita l'elemento prima che funzioni correttamente.
                
Usa i web worker per eseguire JavaScript al di fuori del thread principale del browser. I web worker consentono di eseguire gli script al di fuori del thread principale. Ciò eviterà che il thread principale si blocchi e causi problemi di ritardo di input INP.
                
Carica gli script di terze parti non essenziali durante il tempo di inattività del browser. Alcuni script sono più critici di altri. Ha senso dare priorità a questi script e caricare quelli meno importanti durante il tempo di inattività del browser. Ad esempio, uno script di chat. Consulta la nostra guida su [url=\/pagespeed\/14-methods-to-defer-javascript]14 metodi per differire JavaScript[\/url] per tecniche pratiche.
            

            
Ridurre al minimo il tempo di elaborazione (Processing Time)
            
Il [url=\/core-web-vitals\/interaction-to-next-paint\/processing-time]tempo di elaborazione[\/url] è il tempo necessario al browser per eseguire tutte le funzioni di callback per l'evento.
            
Rimuovi il codice non necessario. Il codice non necessario è codice vecchio che viene ancora eseguito oppure codice nuovo che non serve su questa pagina specifica ma occupa comunque tempo di CPU. Questo è di gran lunga il modo più semplice per migliorare immediatamente l'INP.
                
Differisci il codice che non deve essere eseguito prima del paint successivo. Suddividi il codice in codice critico che deve essere eseguito prima dell'INP e codice non critico (ad esempio l'invio di dati analitici) e programmalo dopo l'evento di paint con il metodo requestIdleCallback().
                
Ottimizza il codice che deve essere eseguito prima del paint. Controlla il tuo codice e riscrivi le parti lente o inefficaci.
                
Fornisci un feedback immediato. Per attività complicate o potenzialmente lente, fornisci un feedback immediato prima di eseguire il codice principale.
            

            
Ridurre al minimo il ritardo di presentazione (Presentation Delay)
            
Il [url=\/core-web-vitals\/interaction-to-next-paint\/presentation-delay]ritardo di presentazione[\/url] rappresenta il tempo impiegato dal browser per renderizzare gli aggiornamenti visivi che seguono l'interazione. Quando la pagina deve essere aggiornata, il browser prima esegue nuovamente il rendering della parte interessata della pagina, quindi dipinge il nuovo contenuto e lo invia al compositor (GPU e Raster).
Mantieni il DOM piccolo e semplice. Sarà molto più facile per un browser renderizzare una pagina con pochi e semplici elementi DOM non annidati (nodi HTML) rispetto a una pagina con molti nodi DOM annidati. Maggiori informazioni su come [url=\/pagespeed\/fix-avoid-excessive-dom-size-lighthouse]risolvere le dimensioni eccessive del DOM[\/url].
Usa content-visibility per il rendering differito dei contenuti fuori dallo schermo. Content-visibility velocizzerà il rendering delle parti visibili della pagina ritardando il rendering dei contenuti fuori dallo schermo ed eseguendolo solo al momento opportuno.
            
            

            
Soluzione rapida: rendere la mano al thread principale con scheduler.yield()
            
Rendere la mano al thread principale tra il lavoro critico e quello non critico migliora tutte e tre le fasi dell'INP in una volta sola. L'API scheduler.yield() fornisce un modo pulito per farlo. Ecco una funzione helper riutilizzabile con una soluzione di ripiego 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);
  });
}

\/\/ Utilizzo in un gestore di eventi
async function handleButtonClick() {
  \/\/ Lavoro critico: aggiorna l'interfaccia utente
  updateVisualFeedback();

  \/\/ Rendi la mano per consentire al browser di dipingere
  await yieldToMain();

  \/\/ Lavoro non critico: analytics, logging
  sendAnalyticsEvent('button_click');
  logInteraction();
}

            
Ogni fase dell'INP in dettaglio
            
Ogni fase ha le proprie strategie di ottimizzazione:
            
[url=\/core-web-vitals\/interaction-to-next-paint\/input-delay]Input Delay[\/url]: scopri come ridurre al minimo il tempo che intercorre tra l'interazione dell'utente e l'inizio dell'elaborazione dell'evento. Il ritardo di input è in genere la più piccola delle tre fasi, ma presenta picchi durante l'avvio della pagina quando il thread principale è occupato con l'esecuzione degli script.
                
[url=\/core-web-vitals\/interaction-to-next-paint\/processing-time]Processing Time[\/url]: ottimizza il codice dell'event handler eseguito durante l'interazione. Nella maggior parte delle pagine, è qui che si concentra la maggior parte degli sforzi di ottimizzazione.
                
[url=\/core-web-vitals\/interaction-to-next-paint\/presentation-delay]Presentation Delay[\/url]: riduci il lavoro di rendering e painting che segue l'elaborazione dell'evento. Sulle pagine complesse con DOM di grandi dimensioni, questa è spesso la fase più lunga.
            
            
Per ulteriori strategie trasversali a tutte e tre le fasi, consulta le nostre guide su come [url=\/pagespeed\/improve-inp-ditch-javascript-scrolling]migliorare l'INP eliminando lo scorrimento JavaScript[\/url] e su come [url=\/pagespeed\/async-vs-defer-javascript-and-core-web-vitals]scegliere tra asincrono e differito per il proprio JavaScript[\/url].

        
        
[include]sidebarcwv.html[\/include] 
    

 [include]blogfooter.html[\/include]