Risolvere l'INP con un Agente IA: La Metrica che gli Strumenti di Laboratorio Non Possono Misurare

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

Ultima revisione a cura di Arjen Karel nel marzo 2026

Perché l'INP è diverso per gli agenti IA

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

Nessun strumento di laboratorio può riprodurre tutto questo. 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 la sessione. Una pagina con TBT pari a zero può comunque avere un INP terribile se un timer in background si attiva nel momento sbagliato. Un agente senza dati sul campo è cieco di fronte a questo. Ottimizza il TBT e dichiara vittoria mentre gli utenti reali aspettano 400 ms affinché i loro clic vengano registrati.

Tre fasi, tre soluzioni diverse

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

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

Processing: Il gestore di eventi stesso è troppo lento. Layout thrashing (lettura del DOM, scrittura del DOM, lettura del DOM in un ciclo), query DOM sincrone all'interno del gestore, re-rendering costosi o semplicemente l'esecuzione di troppo lavoro in una singola attività senza effettuare uno yielding.

Presentation: Il browser impiega troppo tempo per eseguire il paint dopo il completamento del gestore. Alberi DOM di grandi dimensioni (migliaia di nodi che richiedono il ricalcolo dello stile), mancanza di contenimento CSS (CSS containment) o operazioni di paint costose innescate dalle modifiche al DOM del gestore.

Quale script sta bloccando la tua pagina

CoreDash acquisisce l'attribuzione dei Long Animation Frames (LoAF) dalle sessioni utente reali. Questo è ciò che consente all'agente di risolvere effettivamente l'INP invece di tirare a indovinare.

I LoAF indicano l'esatto file JavaScript, la funzione e la durata. L'agente non tira a indovinare quale script sta bloccando il thread principale. CoreDash glielo dice: gtm-container.js ha bloccato il thread principale per 280 ms 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 450 ms e ti lascia capire quale dei tuoi 30 script lo ha causato.

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

Caricamento in corso o caricato: due problemi diversi

Il fatto che l'interazione sia avvenuta durante lo stato loading o complete cambia completamente la soluzione.

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

Se l'INP è pessimo allo stato completo, hai un problema di JavaScript a runtime. C'è qualcosa in esecuzione in background su una pagina completamente caricata. Script di terze parti che eseguono il polling per gli aggiornamenti, script di analisi 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 usa queste informazioni per escludere metà delle cause prima di esaminare gli script.

Ragionamento proporzionale per l'INP

L'INP è di 350 ms sulla pagina di checkout. La ripartizione per fasi in base ai dati sul campo:

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

La Presentation è il collo di bottiglia. 200 ms non sembrano allarmanti se presi isolatamente. Ma rappresentano il 57% del totale. Correggere la Presentation sposta l'ago della bilancia molto più dell'ottimizzazione combinata dell'Input Delay o del Processing.

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

Correzioni tipiche per fase

Input Delay in fase di caricamento: Differisci gli script non critici. Rimuovi il JavaScript inutilizzato. Suddividi il codice in modo che venga caricato solo il codice per la pagina corrente.

Input Delay a caricamento completato: Verifica gli script di terze parti in esecuzione dopo il caricamento della pagina. Usa i dati LOAF di CoreDash per trovare lo script incriminato. Differiscilo al tempo di inattività con requestIdleCallback.

Processing: Effettua uno yielding verso il thread principale con scheduler.yield() o setTimeout(0). Suddividi i gestori di eventi lunghi in task più piccoli. Evita layout forzati (leggere le proprietà di layout subito dopo aver scritto nel DOM).

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

Verifica con i dati sul campo

I miglioramenti dell'INP vengono visualizzati in CoreDash entro uno o due giorni di traffico reale. Esegui una query per la stessa pagina e lo stesso segmento di dispositivi. Il p75 dovrebbe scendere e la distribuzione delle fasi dovrebbe spostarsi.

Osserva anche la suddivisione dello stato di caricamento. Se la tua correzione era mirata all'INP dello stato di caricamento, verifica che i numeri relativi allo stato di caricamento siano migliorati senza causare regressioni in quelli allo stato completo. I dati sul campo ti offrono questa granularità. I dati di laboratorio no.