Interaction to Next Paint (INP): cos'è, come misurarlo e migliorarlo

L'Interaction to Next Paint (INP) è un Core Web Vital che misura la rapidità con cui una pagina web risponde alle interazioni dell'utente, come clic, tap e pressione dei tasti. L'INP rileva l'intera latenza, dall'input dell'utente all'elaborazione JavaScript fino all'aggiornamento visivo finale sullo schermo. Un buon punteggio INP è pari o inferiore a 200 millisecondi al 75° percentile. A marzo 2024, l'INP ha sostituito il First Input Delay (FID) come Core Web Vital.

Cos'è l'Interaction to Next Paint (INP)?

L'INP è il Core Web Vital per la reattività. Esamina ogni interazione durante la visita e restituisce un unico valore per la pagina.

A ogni clic, tap o pressione di un tasto, il browser misura il tempo che passa dall'input al frame successivo sullo schermo. L'interazione più lenta diventa l'INP di quella visita. Nelle pagine con molti clic, Chrome esclude un valore anomalo ogni 50 interazioni, attestandosi all'incirca al 98° percentile.

INP vs FID: cosa è cambiato e perché

A marzo 2024, l'INP ha sostituito ufficialmente il First Input Delay (FID) come Core Web Vital. Google ha ritirato il FID perché ignorava due aspetti.

Primo: il FID misurava solo la prima interazione sulla pagina. Se il primo clic dell'utente era veloce ma le interazioni successive erano lente, il FID dava esito positivo nonostante la cattiva esperienza. L'INP misura ogni interazione durante l'intera visita.

Secondo: il FID misurava soltanto la fase di input delay, ovvero registrava il tempo che il browser passava in attesa prima di iniziare a elaborare l'evento. Ignorava il tempo dedicato all'esecuzione degli event handler (processing time) e il tempo necessario per visualizzare il risultato sullo schermo (presentation delay). L'INP le misura tutte e tre.

Quasi tutti i siti superavano il FID. Molti falliscono l'INP, perché le interazioni successive o il lavoro dopo il primo clic sono lenti.

Quali interazioni misura l'INP?

L'INP misura solo interazioni discrete: un clic, un tap o la pressione di un tasto.

Interazioni considerate dall'INP

• Clic del mouse (inclusi i clic su pulsanti, link, caselle di controllo e controlli personalizzati)
• Tap su touchscreen (l'equivalente del clic su dispositivi mobili)
• Pressione di tasti su tastiera fisica o su schermo (inclusa la digitazione nei campi di testo, la pressione di Invio e l'uso di scorciatoie da tastiera)

Interazioni non considerate dall'INP

• Scrolling (vedi sotto)
• Hovering (mouseover)
• Dragging, anche se il pointerdown che avvia il trascinamento può essere misurato
• Transizioni e animazioni CSS eseguite senza input dell'utente

Lo scrolling in sé non conta. Il codice di scroll può comunque penalizzare l'INP in due modi. Un clic su un link che avvia un'animazione di scroll in JavaScript è un'interazione, e il codice di scroll viene eseguito al suo interno. Inoltre, gli scroll handler eseguiti a ogni evento di scroll tengono occupato il main thread, costringendo il clic successivo ad attendere. scroll-behavior: smooth in CSS evita entrambi i problemi.

Le tre fasi di un'interazione INP

Ogni interazione misurata dall'INP attraversa tre fasi consecutive (Google le definisce subpart). Il valore dell'INP è la somma di queste tre fasi, e ciascuna richiede un fix diverso.

1. Input delay

L'input delay è il tempo che passa tra il clic e l'avvio degli event handler. Il clic deve attendere il completamento di qualunque task stia occupando il main thread in quel momento: un tag manager, lo script di un banner di consenso o un framework ancora in fase di idratazione.

L'input delay tocca il punto peggiore mentre la pagina è ancora in fase di caricamento. Nei dati di CoreDash, i clic durante il caricamento sono oltre due volte più lenti rispetto ai clic dopo il caricamento (trovi i numeri più in basso).

2. Processing time

Il processing time è il tempo impiegato dagli event handler dell'interazione: validazione di un form, aggiornamento di stato, chiamata di analytics.

Se un event handler esegue operazioni pesanti sul DOM, chiamate API sincrone o cicli lenti, il processing time aumenta. Un classico: un dataLayer.push() nel click handler, che fa scattare ogni tag nel tag manager prima che lo schermo possa aggiornarsi. Il fix consiste nel fare yield prima del push.

3. Presentation delay

Il presentation delay è il tempo che trascorre tra la fine degli event handler e il frame successivo sullo schermo: style, layout, paint.

Le pagine con un DOM grande o con molti livelli di annidamento impiegano più tempo a ricalcolare gli stili ed eseguire il layout. Le single page application che re-renderizzano ampi alberi di componenti dopo una modifica di stato presentano spesso un presentation delay elevato.

Quali sono i punteggi INP buoni e scarsi?

Per superare la valutazione, l'INP delle visite alla pagina deve essere pari o inferiore a 200 millisecondi al p75:

• Un INP pari o inferiore a 200 millisecondi indica che la pagina ha una buona reattività.
• Un INP compreso tra 200 e 500 millisecondi indica che la reattività della pagina deve essere migliorata.
• Un INP superiore a 500 millisecondi indica che la pagina ha una reattività scarsa.

L'INP utilizza il 75° percentile: il 75% delle visite alla pagina deve quindi avere un INP inferiore a 200ms. Inclusi i visitatori con telefoni lenti.

Come misurare l'Interaction to Next Paint (INP)

L'INP ha bisogno di visitatori reali che facciano clic, tap e digitino: l'INP effettivo proviene quindi dai field data. Un test in lab che carica semplicemente la pagina non produce alcun INP. Lighthouse mostra invece il Total Blocking Time, che indica quanto è occupato il main thread durante il caricamento, ma non dice nulla sul clic nel menu dei filtri.

Ottieni le metriche INP ufficiali

L'INP ufficiale arriva da CrUX. PageSpeed Insights mostra il 75° percentile degli ultimi 28 giorni di dati Chrome per un URL o un'origine. CrUX Vis mostra come è cambiato nel corso degli ultimi mesi, mentre CrUX su BigQuery offre i dati mensili per ogni origine.

Google Search Console raggruppa gli URL nel report Core Web Vitals. Un gruppo con esito negativo viene segnalato come "INP issue: longer than 200ms (mobile)" o "INP issue: longer than 500ms (mobile)", con URL di esempio. I dati coprono gli ultimi 28 giorni: due settimane dopo il rilascio di un fix, metà di ciò che vedi riflette ancora la versione precedente del sito.

Monitora l'INP con il Real User Monitoring

CrUX ti dice che un gruppo di pagine fallisce. Non ti dice quale pulsante. Per questo serve il Real User Monitoring. Su CoreDash controllo prima l'INP al p75 su mobile, suddiviso per elemento cliccato e per stato di caricamento.

Misura l'INP per la sessione corrente

Apri il pannello Performance in Chrome DevTools. Mostra l'INP della sessione corrente mentre fai clic, con il log di ogni interazione e delle relative tre fasi. Registra una trace mentre clicchi per vedere cosa è stato eseguito sul main thread. L'estensione Core Web Vitals Visualizer mostra l'INP direttamente sulla pagina.

Per fare debugging pratico, usa la libreria JavaScript Web Vitals di Google per registrare le singole interazioni nella console:

Registra l'INP nella console con la libreria JavaScript Web Vitals

<script type="module">
 import {onINP}
 from 'https://unpkg.com/web-vitals@6/dist/web-vitals.attribution.js?module';
 onINP(console.log);
</script>

Come migliorare l'Interaction to Next Paint

Una sola interazione lenta può determinare l'INP dell'intera visita, anche se tutti gli altri clic sono veloci. Intervieni sulle tre fasi.

PageSpeed TIP: registra lo stato di caricamento della pagina a ogni interazione. Un clic lento durante il caricamento richiede un fix diverso rispetto a un clic lento a pagina già caricata.

1. Riduci al minimo l'input delay: evita i long task sul main thread

La maggior parte del lavoro sul main thread avviene all'avvio. Tienilo libero:

• Rimuovi il codice inutilizzato. Il pannello Coverage di DevTools mostra quale parte di ogni script non viene mai eseguita. Al resto ci pensano tree shaking e code splitting.
• Carica il codice non essenziale durante l'idle time del browser. Serve davvero un widget di chat durante i primi 500ms di caricamento della pagina? Pianifica gli script non critici con requestIdleCallback() per eseguirli solo quando il browser è inattivo.
• Individua il long task che blocca il clic. Registra una trace nel pannello Performance mentre fai clic durante il caricamento. Il task in esecuzione al momento del clic è quello da sistemare per primo.
• Usa async e defer sui tag script per evitare che JavaScript blocchi il parser HTML. Gli script che non servono a nessuno nei primi secondi possono aspettare di più: 14 metodi per posticipare JavaScript.
• Ignora il consiglio sui passive listener. { passive: true } viene spesso raccomandato per l'INP. Rende lo scrolling più fluido. All'INP non interessa.

Spezza i long task con scheduler.yield()

JavaScript viene eseguito sul main thread del browser secondo il modello "run to completion": una volta avviato, un task blocca il main thread finché non termina. I long task (superiori a 50ms) impediscono al browser di rispondere agli input dell'utente. Con scheduler.yield() lasci al browser il tempo di gestire un clic in attesa prima che il codice prosegua. Maggiori dettagli in yield al main thread.

async function yieldToMain() {
  if ('scheduler' in window && 'yield' in window.scheduler) {
    return await window.scheduler.yield();
  }
  // Fallback for browsers without scheduler.yield()
  return new Promise((resolve) => {
    setTimeout(resolve, 0);
  });
}

// Usage: break up a long task into smaller chunks
async function processLargeDataSet(items) {
  for (let i = 0; i < items.length; i++) {
    processItem(items[i]);

    // Yield every 5 items to let the browser handle user input
    if (i % 5 === 0) {
      await yieldToMain();
    }
  }
}

Posticipa il lavoro non critico con requestIdleCallback

Usa requestIdleCallback() per pianificare i task non essenziali (analytics, telemetria, prefetching) quando il browser è inattivo. In questo modo restano fuori dal processing time del clic.

// Instead of running analytics synchronously:
document.querySelector('.cta-button').addEventListener('click', (e) => {
  // Critical: update the UI immediately
  showConfirmation();

  // Non-critical: send analytics during idle time
  requestIdleCallback(() => {
    sendAnalyticsEvent('cta_clicked', { page: location.pathname });
  }, { timeout: 2000 });
});

2. Riduci al minimo il processing time: fornisci un feedback immediato

Quando un visitatore compie un'azione, come inviare un form o aggiungere un articolo al carrello, non aspettare la conferma del server prima di aggiornare la UI. Fornisci un feedback visivo immediato ("Invio del form in corso...", "Aggiunta al carrello...") e completa poi l'operazione in background.

Inoltre, fai yield al main thread il prima possibile dopo l'aggiornamento visivo critico. Poiché JavaScript segue un modello "run to completion", blocca il main thread finché tutto il codice nella callback non è stato eseguito. Puoi creare manualmente un punto di yield in cui il browser aggiorna il layout, per poi continuare l'esecuzione del restante codice non critico.

const formfeedbackEl = document.getElementById("formfeedback");
const formEl = document.getElementById("form");

formEl.addEventListener("submit", (evt) => {
  evt.preventDefault();
  formfeedbackEl.innerText = "Submitting form ... please hold on";

  let headers = new Headers({ Accept: "application/json" });
  let formData = new FormData(formEl);
  fetch("/form-endpoint", { method: "POST", headers, body: formData })
    .then(function (response) {
      return response.json();
    })
    .then(function (jsonData) {
      formEl.reset();
      formfeedbackEl.innerText = jsonData.message;
    });
   setTimeout(other_code_that_needs_to_run, 0);
});

3. Riduci al minimo il presentation delay: mantieni le cose semplici

Quando la pagina deve aggiornarsi dopo un'interazione, il browser deve ricalcolare gli stili, eseguire il layout, disegnare i pixel modificati e comporre il risultato. La complessità e le dimensioni del DOM determinano direttamente la durata di questo lavoro di rendering.

Alcune single page application re-renderizzano mezza pagina a ogni interazione, anche quando è cambiato solo un contatore. React DevTools e React Scan lo mostrano chiaramente. Spesso un context provider situato in alto nell'albero re-renderizza tutto ciò che si trova al di sotto.

Due regole per un rendering più rapido:

1. Mantieni il DOM piccolo e semplice. Un DOM compatto e lineare renderizza più rapidamente rispetto a uno grande e con molti livelli di annidamento. Lighthouse segnala le pagine con più di 1.400 elementi DOM o con una profondità di annidamento superiore a 32 livelli.
2. Usa content-visibility per il lazy-rendering dei contenuti fuori schermo. La proprietà CSS content-visibility: auto velocizza il rendering iniziale rimandando il rendering dei contenuti fuori schermo finché l'utente non vi si avvicina con lo scroll.

/* Apply content-visibility to off-screen sections */
.below-the-fold {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

Debug dell'INP con l'API Long Animation Frames (LoAF)

L'API Long Animation Frames (LoAF) fornisce dettagli sui frame che richiedono più di 50ms per il rendering, inclusi gli script eseguiti durante quel lasso di tempo.

A differenza della precedente Long Tasks API, LoAF rileva sia il tempo di rendering sia il tempo di esecuzione degli script, risultando particolarmente utile per diagnosticare i problemi di presentation delay. Ogni voce riporta la durata del frame e la durata del blocco. L'elenco degli script mostra, per ciascuno, l'URL di origine, il nome della funzione e il tempo di esecuzione.

// Observe Long Animation Frames to find INP bottlenecks
const observer = new PerformanceObserver((list) => {
  for (const entry of list.getEntries()) {
    // Only look at frames longer than 100ms
    if (entry.duration > 100) {
      console.log('Long frame:', entry.duration + 'ms');

      // Log each script that contributed
      for (const script of entry.scripts) {
        console.log(
          'Script:', script.sourceURL,
          'Function:', script.sourceFunctionName,
          'Duration:', script.duration + 'ms'
        );
      }
    }
  }
});

observer.observe({ type: 'long-animation-frame', buffered: true });

Gli strumenti RUM come CoreDash integrano automaticamente i dati LoAF, mettendo in correlazione i long animation frame con le specifiche interazioni dell'utente: così vedi subito quale script, su quale pagina, rallenta una determinata interazione.

INP e LCP: il legame con i long task

I long task sul main thread impattano sia sull'INP sia sul Largest Contentful Paint (LCP). Un task JavaScript che blocca il main thread per 200ms ritarda l'elaborazione dell'evento (peggiorando l'INP) e ritarda anche il rendering dell'elemento LCP da parte del browser (peggiorando il LCP). Quando ottimizzi il main thread spezzando i long task, posticipando il JavaScript non critico e riducendo il tempo di esecuzione degli script, li migliori entrambi.

Casi studio: miglioramenti dell'INP in produzione

redBus: INP ridotto del 72%, vendite aumentate del 7%

redBus, una piattaforma online per l'acquisto di biglietti dell'autobus, ha individuato nei dati RUM interazioni lente del tutto inattese. Nella pagina di ricerca, gli scroll handler scattavano a ogni evento di scroll tenendo occupato il main thread, quindi hanno applicato un debounce. Su un'altra pagina, ogni modifica in un campo di input eseguiva lo state reducer, che è stato quindi chiamato meno spesso. L'INP di quella pagina è migliorato del 72% e redBus ha registrato un aumento delle vendite di circa il 7%. (case study di redBus su web.dev)

Preply: INP da 250ms a 185ms su un sito Next.js

Preply, una piattaforma online di lezioni di lingua basata su Next.js, ha portato l'INP della home page da circa 250ms a 185ms e quello della pagina di ricerca a 175ms. Il tutto senza React Server Components. Hanno virtualizzato un lungo elenco, applicato il debounce agli eventi della tastiera, memoizzato i componenti pesanti, impedito a un tooltip di re-renderizzare l'intera pagina e corretto la gestione dello stato del banner della privacy. Prima di iniziare, avevano stimato che portare entrambe le pagine sotto i 200ms avrebbe potuto fruttare circa 200.000$ all'anno in traffico di ricerca. (blog engineering di Preply)

Cosa mostrano i dati di CoreDash sull'INP

Il divario dell'INP tra mobile e desktop

Nei dati di CoreDash, l'INP su mobile (131ms al p75) è 2,8 volte quello su desktop (48ms). I telefoni hanno CPU più lente. Lo stesso JavaScript blocca il main thread più a lungo. Su desktop il 95,6% delle interazioni è buono, contro l'88,0% su mobile. Inoltre, su mobile le interazioni scarse sono cinque volte di più (9,6% contro 1,9%).

Interazioni da tastiera vs puntatore

I dati di CoreDash mostrano che le interazioni da tastiera (75ms al p75) sono più lente del 56% rispetto a quelle da puntatore (49ms al p75). Gli eventi da tastiera registrano inoltre circa cinque volte più esperienze scarse: il 7,4% delle interazioni da tastiera produce un INP scarso, contro appena l'1,4% delle interazioni da puntatore. Gli eventi da tastiera, soprattutto nei campi dei form, innescano spesso validazione, completamento automatico e aggiornamenti di stato.

Interazioni durante il caricamento vs dopo il caricamento

Le interazioni durante il caricamento della pagina hanno un INP molto più alto rispetto a quelle successive. I dati di CoreDash mostrano che le interazioni nella fase di "loading" hanno un INP al p75 di 132ms, a fronte di appena 50ms per le interazioni post-caricamento. Una differenza di 2,6 volte. Perfino le interazioni nella fase "dom-content-loaded" (75ms) mostrano un INP elevato, perché gli script asincroni e le sotto-risorse sono ancora in elaborazione. La soluzione è ridurre JavaScript all'avvio: rimanda tutto ciò che può attendere.

L'INP sul web

Nella release CrUX di agosto 2026, l'85,3% delle origini registrava un INP buono, in calo rispetto all'87,2% di marzo. Nel frattempo l'INP è sceso ogni mese, ed è l'unico Core Web Vital peggiorato rispetto ad agosto 2025 (85,7%). Il team di Chrome lo definisce motivo di preoccupazione e non ha ancora una spiegazione.

Il Web Almanac 2025 mostra il divario tra i dispositivi: il 97% delle pagine desktop registra un INP buono, contro il 77% su mobile. I primi 1.000 siti sono quelli migliorati di più, passando dal 53% al 63% di esiti buoni su mobile. Nel frattempo, il Total Blocking Time mediano su mobile è aumentato del 58%, passando da 1.209 a 1.916 millisecondi.

Domande frequenti

Guide correlate

Ogni componente dell'INP ha una guida dedicata:

• <strong>Individuare e risolvere i problemi di INP</strong>: dal report di Search Console all'interazione lenta, con dati RUM e DevTools.
• <strong>Input delay dell'INP</strong>: i long task che fanno attendere il clic.
• <strong>Processing time dell'INP</strong>: gli event handler e cosa può essere eseguito dopo l'aggiornamento dello schermo.
• <strong>Presentation delay dell'INP</strong>: dimensioni del DOM, layout thrashing e re-render.

Guide PageSpeed correlate:

• Migliorare l'INP: abbandona lo scrolling in JavaScript
• Async vs defer: strategie di caricamento di JavaScript
• 14 metodi per posticipare JavaScript
• Widget di chat con Core Web Vitals perfetti
• Fix: evita dimensioni eccessive del DOM