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

Interaction to Next Paint è il Core Web Vital più difficile per gli agenti AI. Non si può simulare. Lighthouse non ha un punteggio INP. Senza dati reali degli utenti, un agente AI non può dirti quale interazione è lenta, chi ne è colpito o in quale momento del ciclo di vita della pagina si verifica. Ecco come correggere l'INP quando hai i field data.

Ultima revisione di Arjen Karel a marzo 2026

Perché l'INP è diverso per gli agenti AI

L'INP misura la rapidità di risposta del sito alle interazioni dell'utente: clic, tap, pressione dei tasti. Prende la peggiore singola interazione dell'intera sessione. La parola chiave è reale. Un utente clicca sul menu a tendina dei filtri nella pagina prodotto mentre uno script di analytics di terze parti è in esecuzione. Quel ritardo di 380ms diventa l'INP di quella sessione.

Nessun lab tool può riprodurlo. Lighthouse usa il Total Blocking Time come proxy, ma il TBT misura il blocco del main thread durante il caricamento della pagina. L'INP misura il tempo di risposta a interazioni che avvengono in momenti imprevedibili durante la sessione. Una pagina con zero TBT può avere comunque un INP disastroso se un timer in background scatta al momento sbagliato. Un agente senza field data è cieco di fronte a questo. Ottimizza il TBT e canta vittoria, mentre gli utenti reali aspettano 400ms che il clic venga registrato.

Tre fasi, tre fix diversi

L'INP si scompone in tre fasi. Ciascuna richiede un fix diverso.

Input Delay: Il main thread era occupato quando l'utente ha interagito. Durante lo stato loading, le cause tipiche sono l'esecuzione di bundle JavaScript pesanti, l'inizializzazione di script di analytics o l'hydration del framework. Nello stato complete (a pagina del tutto caricata), la colpa è di timer in background, script di terze parti che fanno polling per aggiornamenti o attività del 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 dentro l'handler, re-render costosi o semplicemente troppo lavoro in un singolo task senza fare yielding.

Presentation: Il browser impiega troppo tempo a eseguire il paint dopo che l'handler ha terminato. DOM tree enormi (migliaia di nodi che richiedono il ricalcolo degli stili), assenza di CSS containment o operazioni di paint pesanti innescate dalle modifiche al DOM apportate dall'handler.

Quale script blocca la pagina

CoreDash cattura l'attribuzione dei Long Animation Frames (LoAF) dalle sessioni degli utenti reali. È questo che permette all'agente di correggere davvero l'INP invece di tirare a indovinare.

LoAF indica con esattezza il file JavaScript, la funzione e la durata. L'agente non deve indovinare quale script sta bloccando il main thread. Glielo dice CoreDash: gtm-container.js ha bloccato il main thread per 280ms durante l'interazione con il filtro nella pagina di checkout.

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

L'agente apre il file, legge il codice e scrive il fix: differirlo, spezzarlo in task più piccoli o rimuoverlo se non serve a nessuno.

Loading vs loaded: due problemi diversi

Che l'interazione sia avvenuta nello stato loading o complete cambia completamente il fix.

Se l'INP è pessimo solo durante lo stato loading, il problema è l'ordine di caricamento degli script. Troppo JavaScript in esecuzione prima che la pagina sia interattiva. Il fix sta nel defer degli script: differire gli script non critici, fare code-splitting, ridurre il JavaScript che blocca il parser.

Se l'INP è pessimo nello stato complete, il problema è il JavaScript a runtime. C'è qualcosa che gira in background su una pagina già del tutto caricata. Script di terze parti che fanno polling per aggiornamenti, analytics che inviano beacon, o codice proprietario che esegue operazioni pesanti con un timer.

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

Ragionamento proporzionale per l'INP

L'INP è di 350ms nella pagina di checkout. La scomposizione delle fasi dai field data:

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

La Presentation è il collo di bottiglia. Presi da soli, 200ms non sembrano allarmanti. Ma rappresentano il 57% del totale. Risolvere la Presentation fa molta più differenza rispetto a ottimizzare Input Delay e Processing messi insieme.

Senza le percentuali, un agente si concentra sull'Input Delay solo perché 70ms superano una certa soglia. Mostragli la scomposizione e punterà dritto al 57%. Risultato: un solo fix che porta l'INP sotto i 200ms, invece di tre interventi sparsi che a malapena lo scalfiscono.

Fix tipici per fase

Input Delay durante il loading: Differisci gli script non critici. Rimuovi il JavaScript non utilizzato. Fai code-splitting per caricare solo il codice necessario alla pagina corrente.

Input Delay nello stato complete: Analizza gli script di terze parti in esecuzione dopo il caricamento della pagina. Usa i dati LoAF di CoreDash per individuare lo script responsabile. Rimandane l'esecuzione all'idle time con requestIdleCallback.

Processing: Fai yield al main thread con scheduler.yield() o setTimeout(0). Spezza gli event handler lunghi in task più piccoli. Evita i forced layout (leggere le proprietà di layout subito dopo aver scritto nel DOM).

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

Verifica con i field data

I miglioramenti dell'INP compaiono su CoreDash nel giro di uno o due giorni di traffico reale. Filtra per la stessa pagina e per lo stesso segmento di dispositivi. Il p75 dovrebbe scendere e la distribuzione delle fasi dovrebbe cambiare.

Tieni d'occhio anche la suddivisione per load state. Se il fix mirava all'INP nello stato loading, verifica che i valori in loading siano migliorati senza causare regressioni su quelli nello stato complete. I field data ti danno questa granularità. I lab data no.