L'INP Punisce l'Analytics Pesante: Perché il Tuo Tracker È sul Thread Principale
Interaction to Next Paint è il Core Web Vital che la maggior parte dei siti non supera, e i dati sul campo mostrano che gli script di tracciamento comportamentale sono una delle cause principali. La soluzione è inviare meno lavoro al thread principale.
Interaction to Next Paint (INP) è il Core Web Vital che gli sviluppatori non superano più spesso, e il motivo si trova nel tuo <head>. L'INP è diventato un Core Web Vital stabile nel 2024, sostituendo il First Input Delay, e misura qualcosa che il FID non ha mai potuto: quanto una pagina resta reattiva a ogni clic, tap e pressione di tasto per tutto il suo ciclo di vita.
La metrica è spietata verso il tipo di JavaScript che carica l'analytics di sorveglianza. Se il tuo tracker svolge lavoro significativo sul thread principale, ogni interazione dei tuoi utenti eredita quel costo.
Cosa Misura Davvero l'INP
L'INP riporta la latenza delle interazioni al 75° percentile di tutti i clic, tap e pressioni di tasto su una pagina. Un punteggio di 200 ms o meno è "buono"; da 200 a 500 ms "da migliorare"; oltre 500 ms "scarso".
Ogni interazione si suddivide in tre fasi:
- Ritardo di input (input delay) — il tempo prima che i tuoi event handler possano anche solo iniziare, perché il thread principale è occupato.
- Durata di elaborazione — il tempo che i callback dei tuoi event handler impiegano per essere eseguiti.
- Ritardo di presentazione (presentation delay) — il tempo dalla fine del callback fino a quando il browser disegna il frame successivo.
L'analytics pesante danneggia tutte e tre le fasi. Un tracker che fa il parsing di un bundle grande, valuta logica di consenso, raggruppa una coda di tag manager o legge il layout per costruire un fingerprint occupa il thread principale proprio quando l'utente cerca di interagire.
I Long Task Sono il Meccanismo
Il browser non può elaborare un'interazione mentre un task è in esecuzione. Qualsiasi task che dura più di 50 ms è un long task, e la porzione oltre i 50 ms è tempo morto durante il quale i clic si accumulano in coda.
Un tag manager che carica ed esegue in modo sincrono una dozzina di script di fornitori produce una cascata di long task. L'utente clicca, non succede nulla, clicca di nuovo — e quando il thread principale si libera finalmente, gli input in coda scattano tutti insieme.
Non è teorico. Il Web Almanac 2024 di HTTP Archive ha rilevato che le pagine con script di comportamento utente — session replay, mappe di calore, analytics comportamentale — raggiungevano un buon INP solo nel 37% dei casi su mobile, contro il 60% su desktop. Gli script di gestione del consenso, i banner che questi strumenti richiedono, superavano l'INP solo sul 53% delle pagine mobili. La strumentazione pensata per "capire gli utenti" sta degradando attivamente la loro esperienza.
L'Architettura Che Lo Evita
La soluzione è strutturale, non un flag da attivare. Invia meno codice e tienilo fuori dal percorso critico.
Un tracker privacy-first può essere abbastanza piccolo da far sì che il suo parsing ed esecuzione non vengano mai registrati come long task. Il tracker di Monoid pesa circa 2 KB, non ha dipendenze, non imposta cookie e non legge il layout — quindi non c'è nulla da fingerprintare e nulla di pesante da eseguire. Registra una pageview con una singola richiesta keepalive e per il resto resta inattivo:
fetch('/collect', {
method: 'POST',
keepalive: true,
body: JSON.stringify({ site_id, path: location.pathname })
})
keepalive: true permette alla richiesta di sopravvivere alla pagina senza trattenere il thread principale, così navigazione e unload non restano mai bloccati in attesa di un beacon.
Quando esegui i tuoi script, cedi il thread principale tra blocchi di lavoro affinché le interazioni in coda possano essere eseguite:
async function processQueue(items) {
for (const item of items) {
handle(item)
if (navigator.scheduling?.isInputPending?.()) {
await scheduler.yield()
}
}
}
scheduler.yield() suddivide un long task in pezzi e riprende con priorità, così uno script di terze parti non può scavalcare la tua continuazione nella coda.
Misuralo sul Campo, Non in Laboratorio
Lighthouse non può riportare l'INP, perché l'INP esiste solo quando una persona reale interagisce. Gli strumenti di laboratorio stimano; non misurano la reattività.
Usa i dati sul campo. Il Chrome User Experience Report (CrUX) aggrega interazioni reali di utenti Chrome che hanno acconsentito, e il report Core Web Vitals di Search Console mostra gli stessi dati per gruppo di URL. Se il tuo INP su CrUX è buono ma il Total Blocking Time di laboratorio è alto, hai margine; se l'INP su CrUX è scarso, i tuoi utenti lo stanno già percependo.
L'argomento sulla privacy e quello sulle prestazioni convergono qui. Un tracker che non legge storage, non costruisce fingerprint e non carica una cascata di fornitori non ha quasi nulla da fare sul thread principale — ed è esattamente per questo che non compare mai nel tuo INP. La sorveglianza è costosa in millisecondi, non solo in fiducia.
Comments
Loading comments…