Correggi l'INP con un agente AI: la metrica che i tool di laboratorio non possono misurare

L'Interaction to Next Paint è il Core Web Vitals più difficile per gli agenti AI. Non può essere simulato. Lighthouse non ha un punteggio INP. Un agente AI senza dati reali degli utenti non può dirti quale interazione è lenta, chi la subisce o quando si verifica nel ciclo di vita della pagina. Ecco come correggere l'INP quando hai i dati sul campo.

Ultima revisione di Arjen Karel a marzo 2026

Perché l'INP è diverso per gli agenti AI

L'INP misura la velocità con cui il tuo sito risponde alle interazioni degli utenti: clic, tocchi, pressioni di tasti. Sceglie la singola interazione peggiore dell'intera sessione. La parola chiave è reale. Un utente fa clic su un menu a discesa per filtrare nella pagina del prodotto mentre è in esecuzione uno script di analisi di terze parti. Quel ritardo di 380ms diventa l'INP per quella sessione.

Nessun tool di laboratorio può riprodurlo. Lighthouse utilizza il Total Blocking Time come proxy, ma il TBT misura il blocco del thread principale durante il caricamento della pagina. L'INP misura il tempo di risposta alle interazioni che avvengono in momenti imprevedibili durante l'intera sessione. Una pagina con TBT pari a zero può comunque avere un INP terribile se un timer in background scatta nel momento sbagliato. Un agente senza dati sul campo è cieco di fronte a questo. Ottimizza il TBT e canta vittoria mentre gli utenti reali aspettano 400ms affinché i loro clic vengano registrati.

Tre fasi, tre correzioni diverse

L'INP si divide in tre fasi. Ognuna richiede una correzione diversa.

Input Delay: Il thread principale era occupato quando l'utente ha interagito. Durante lo stato di caricamento (loading), le cause abituali sono l'esecuzione di grandi bundle JavaScript, l'inizializzazione di script di analisi o l'hydration del framework. Nello stato completo (pagina completamente caricata), la colpa è dei timer in background, degli script di terze parti che effettuano il polling per gli aggiornamenti o dell'attività dei service worker.

Processing: L'event handler stesso è troppo lento. Layout thrashing (lettura del DOM, scrittura del DOM, lettura del DOM in loop), query sincrone al DOM all'interno dell'handler, re-render costosi o semplicemente l'esecuzione di troppo lavoro in una singola attività senza effettuare lo yielding.

Presentation: Il browser impiega troppo tempo per eseguire il paint dopo che l'handler ha terminato. Alberi DOM di grandi dimensioni (migliaia di nodi che richiedono il ricalcolo degli stili), mancanza di CSS containment o operazioni di paint costose attivate dalle modifiche al DOM dell'handler.

Quale script sta bloccando la tua pagina

CoreDash cattura l'attribuzione dei Long Animation Frames (LoAF) dalle sessioni degli utenti reali. Questo è ciò che permette all'agente di correggere effettivamente l'INP invece di tirare a indovinare.

Il LoAF nomina l'esatto file JavaScript, la funzione e la durata. L'agente non indovina quale script sta bloccando il thread principale. CoreDash glielo dice: gtm-container.js ha bloccato il thread principale per 280ms durante l'interazione sul filtro della pagina di checkout.

Invece di "la tua pagina è lenta" ottieni "questo file, questa funzione, questa durata". Confrontalo con Lighthouse, che ti dice che il Total Blocking Time è di 450ms e ti lascia capire quale dei tuoi 30 script lo ha causato.

L'agente apre il file, legge il codice e scrive la correzione: differirlo, dividerlo in attività più piccole o rimuoverlo se non serve a nessuno.

In caricamento vs caricato: due problemi diversi

A seconda che l'interazione sia avvenuta durante lo stato loading o complete, la correzione cambia completamente.

Se l'INP è pessimo solo durante lo stato di caricamento, il problema è l'ordine di caricamento degli script. Troppo JavaScript in esecuzione prima che la pagina diventi interattiva. La soluzione è nel differimento degli script: differire gli script non critici, effettuare il code-splitting, ridurre il JavaScript che blocca il parser.

Se l'INP è pessimo nello stato completo, hai un problema di JavaScript in runtime. Qualcosa è in esecuzione in background su una pagina completamente caricata. Script di terze parti che effettuano il polling per gli aggiornamenti, analytics che inviano beacon o il tuo stesso codice che esegue operazioni costose su un timer.

CoreDash traccia lo stato di caricamento della pagina per ogni misurazione dell'INP. CWV Superpowers lo usa per escludere metà delle cause prima di guardare gli script.

Ragionamento proporzionale per l'INP

L'INP è di 350ms sulla pagina di checkout. La ripartizione delle fasi dai dati sul campo:

• Input Delay: 70ms (20%)
• Processing: 80ms (23%)
• Presentation: 200ms (57%)

La Presentation è il collo di bottiglia. 200ms non sembrano allarmanti di per sé. Ma rappresentano il 57% del totale. Correggere la Presentation sposta l'ago della bilancia più dell'ottimizzazione dell'Input Delay o del Processing combinati.

Senza le percentuali, un agente insegue l'Input Delay perché 70ms superano una certa soglia. Mostragli la ripartizione e andrà dritto al 57%. Il risultato: una singola correzione che fa scendere l'INP sotto i 200ms contro tre correzioni sparse che lo muovono a malapena.

Correzioni tipiche per fase

Input Delay durante il caricamento: Differire gli script non critici. Rimuovere il JavaScript inutilizzato. Effettuare il code-splitting in modo che venga caricato solo il codice per la pagina corrente.

Input Delay a caricamento completo: Controllare gli script di terze parti in esecuzione dopo il caricamento della pagina. Usa i dati LOAF di CoreDash per trovare lo script colpevole. Differiscilo nei momenti di inattività con requestIdleCallback.

Processing: Effettuare lo yielding al thread principale con scheduler.yield() o setTimeout(0). Dividere gli event handler lunghi in attività più piccole. Evitare i layout forzati (leggere le proprietà di layout immediatamente dopo aver scritto nel DOM).

Presentation: Usa content-visibility: auto per ampie sezioni del DOM below the fold (supportato in tutti i principali browser da settembre 2025). Riduci il numero di nodi del DOM interessati dalle modifiche dell'handler. Usa il CSS containment per isolare il repaint a un'area più piccola.

Verifica con i dati sul campo

I miglioramenti dell'INP compaiono in CoreDash entro un giorno o due di traffico reale. Interroga la stessa pagina e lo stesso segmento di dispositivo. Il p75 dovrebbe scendere e la distribuzione delle fasi dovrebbe spostarsi.

Osserva anche la divisione dello stato di caricamento. Se la tua correzione era mirata all'INP in stato di caricamento, conferma che i numeri dello stato di caricamento siano migliorati senza far regredire i numeri dello stato completo. I dati sul campo ti danno questa granularità. I dati di laboratorio no.