Quando l’INP di un sito è scarso, la domanda che segue è sempre la stessa: quale script blocca le interazioni? In laboratorio, con il pannello Performance, la risposta si trova registrando l’interazione lenta. Ma le interazioni lente dei visitatori reali avvengono su dispositivi, pagine e momenti diversi, e spesso non si riesce a riprodurle. Per anni gli strumenti a disposizione nel browser dicevano solo che il main thread era rimasto occupato a lungo, non da chi. La Long Animation Frames API, disponibile in Chrome dal 2024, colma questa lacuna: indica quali script hanno occupato i fotogrammi lenti, con file, funzione e durata.
In questo articolo vediamo cosa misura, in cosa è diversa dalla vecchia Long Tasks API, come raccogliere i suoi dati dagli utenti reali e come usarli per trovare i responsabili di un INP scarso.
Il limite dei task lunghi
Come abbiamo visto a proposito del main thread, un task lungo è un’attività che occupa il thread principale per più di 50 millisecondi, impedendo al browser di rispondere all’utente. La Long Tasks API permette da tempo di osservarli dal codice della pagina, ma con due limiti importanti. Il primo è l’attribuzione: la voce di un task lungo indica al massimo il contesto, per esempio la finestra o un iframe, e non lo script responsabile. Sapere che il main thread è rimasto bloccato per 180 millisecondi senza sapere da cosa serve a poco. Il secondo limite è che il task lungo non include il lavoro di rendering che segue: il ricalcolo degli stili, il layout e il disegno, che spesso sono una parte consistente del ritardo percepito.
Cosa misura un Long Animation Frame
La nuova API cambia punto di vista: invece dei singoli task, osserva i fotogrammi. Un fotogramma lungo è un aggiornamento dello schermo che ha richiesto più di 50 millisecondi, comprendendo tutto il lavoro necessario a produrlo: gli script eseguiti, anche in più task, e il rendering. È una misura più vicina a ciò che l’utente percepisce, perché l’INP misura proprio il tempo tra un’interazione e il fotogramma successivo.
Ogni voce di un fotogramma lungo contiene i tempi principali, come la durata complessiva, il momento in cui è iniziato il rendering e quello in cui sono iniziati stili e layout, e un elenco degli script che hanno contribuito per più di pochi millisecondi. Per ciascuno script sono indicati:
- il file da cui proviene, con la posizione nel codice e, quando disponibile, il nome della funzione;
- il tipo di chiamata: un gestore di eventi, un timer, la risoluzione di una promessa, la valutazione iniziale di uno script, un callback di animazione;
- chi lo ha chiamato: per esempio il gestore del clic di un certo elemento, o un timer impostato con un certo metodo;
- la durata, insieme al tempo speso in ricalcoli forzati di stili e layout, cioè il layout forzato descritto nell’articolo sulle animazioni, e al tempo passato in operazioni sincrone bloccanti.
Come si usa
L’API si usa con un PerformanceObserver, come le altre API di misura del browser. Il codice seguente registra nella console i fotogrammi lunghi e gli script che li hanno occupati:
new PerformanceObserver( ( elenco ) => {
for ( const fotogramma of elenco.getEntries() ) {
for ( const script of fotogramma.scripts ) {
console.log(
Math.round( fotogramma.duration ),
script.invoker,
script.sourceURL,
Math.round( script.duration )
);
}
}
} ).observe( { type: 'long-animation-frame', buffered: true } );Incollato nella console dei DevTools su una pagina, permette già una diagnosi rapida: si interagisce con la pagina e si osserva quali script compaiono nei fotogrammi lenti. Ma il valore vero dell’API emerge quando i dati vengono raccolti dagli utenti reali.
Raccogliere i dati reali
La libreria web-vitals di Google, nella versione con attribuzione, associa a ogni misura dell’INP i fotogrammi lunghi che si sovrappongono all’interazione. È il collegamento che mancava: per l’interazione che determina l’INP di una visita, si sa quali script hanno occupato i fotogrammi coinvolti. Molti sistemi di monitoraggio degli utenti reali hanno integrato questi dati, e chi usa una soluzione propria può inviarli insieme alle metriche.
Non conviene inviare tutti i dati grezzi: i fotogrammi lunghi possono essere molti, e le voci degli script contengono indirizzi completi. Una buona pratica è inviare, per l’interazione peggiore di ogni visita, i pochi script con la durata maggiore, con l’origine del file, il tipo di chiamata e la durata. Aggregando migliaia di visite, emerge un quadro chiaro di chi occupa il main thread quando gli utenti interagiscono.
Leggere i risultati
I dati aggregati rispondono a domande che prima richiedevano lunghe indagini. Quale quota del tempo bloccato viene da script di terze parti e quale dal codice del sito? Quale servizio esterno pesa di più? Il problema è nei gestori degli eventi, cioè nel codice che risponde al clic, o in timer e attività che occupano il main thread proprio mentre l’utente interagisce? Il secondo caso, che si traduce in un lungo ritardo di input, è frequente con widget di chat, strumenti di analisi del comportamento e tag manager che eseguono lavoro periodico.
Il tipo di chiamata dà indicazioni utili sul rimedio. Se lo script responsabile viene eseguito per la sua valutazione iniziale, il problema è il caricamento, e si risolve rimandandolo o caricandolo solo quando serve. Se è un timer ricorrente, va ridotta la frequenza o spezzato il lavoro. Se è il gestore dell’evento stesso, va alleggerito il codice che risponde all’interazione, rimandando ciò che non serve a mostrare il risultato. Se il tempo di layout forzato è alto, il codice alterna letture e scritture delle proprietà geometriche.
Il tempo di blocco
Oltre alla durata, ogni fotogramma lungo riporta un tempo di blocco, cioè la parte del fotogramma durante la quale il browser non avrebbe potuto rispondere prontamente a un’interazione. È un dato utile anche indipendentemente dalle interazioni: sommando il tempo di blocco dei fotogrammi lunghi durante il caricamento si ottiene una stima, sugli utenti reali, di quanto il main thread è stato congestionato, simile nello spirito al Total Blocking Time misurato in laboratorio. Una pagina con molto tempo di blocco nei primi secondi avrà facilmente interazioni lente per chi prova a usarla subito, anche se l’INP registrato per quella visita dipende dal momento preciso in cui l’utente ha toccato lo schermo.
Privacy e volume dei dati
I dati dei fotogrammi lunghi contengono indirizzi di file e, a volte, parti degli indirizzi delle pagine. Prima di inviarli a un sistema di raccolta conviene ridurli all’essenziale: l’origine o il percorso del file senza parametri, il tipo di chiamata, la durata arrotondata. Così si evitano sia la raccolta di dati non necessari, sia volumi di traffico eccessivi: inviare poche voci per visita, legate all’interazione peggiore, è più che sufficiente per le analisi aggregate. Come per ogni raccolta di dati sugli utenti, anche questa va considerata nella documentazione sulla privacy del sito, insieme agli altri strumenti di analisi.
Gli errori più comuni
- Guardare tutti i fotogrammi lunghi, invece di quelli legati alle interazioni: molti fotogrammi lunghi avvengono durante il caricamento, quando l’utente non sta interagendo, e possono portare a ottimizzare la cosa sbagliata;
- attribuire tutto al gestore dell’evento: spesso il colpevole non è il codice che risponde al clic, ma uno script estraneo che occupava il main thread in quel momento;
- fermarsi al primo script: un fotogramma lungo è spesso la somma di più contributi medi, e togliere solo il più grande può non bastare;
- dimenticare il rendering: se gli script occupano poco e il fotogramma è comunque lungo, il problema è negli stili, nel layout o nel disegno, cioè nella dimensione del DOM e nelle modifiche che provocano.
I limiti
L’API è supportata dai browser basati su Chromium, come Chrome ed Edge, e non da Safari e Firefox. Per l’INP non è un problema grave, perché anche i dati del Chrome UX Report vengono dagli utenti di Chrome, ma va ricordato che l’esperienza degli utenti di altri browser resta non osservata. Gli script eseguiti in iframe di altre origini non sono attribuiti nel dettaglio, e alcune informazioni, come il nome della funzione, possono mancare per il codice compresso o generato dinamicamente. Infine, le voci indicano dove è stato speso il tempo, non perché: se un gestore del clic richiede 150 millisecondi, bisogna comunque aprire il codice, o registrare l’interazione nel pannello Performance, per capire cosa fa.
Nel laboratorio
I dati reali indicano dove guardare; il laboratorio permette di capire. Una volta individuato lo script responsabile, conviene riprodurre l’interazione con la CPU rallentata e osservarla nel pannello Performance, dove il grafico a fiamma mostra le singole funzioni. Il codice di osservazione visto sopra è utile anche qui: incollato nella console durante le prove, conferma se l’intervento ha eliminato i fotogrammi lunghi o se ne sono comparsi altri. È un ciclo che si ripete: raccolta dei dati reali, identificazione del responsabile, diagnosi in laboratorio, intervento, verifica sui dati reali nelle settimane successive.
In WordPress
Nei siti WordPress i responsabili più frequenti di un INP scarso sono gli script caricati da plugin e temi: slider, costruttori di pagine, chat, pop-up promozionali, strumenti di analisi, banner dei cookie, come discusso nell’articolo sul banner del consenso. Con i dati dei fotogrammi lunghi, il percorso del file indica spesso direttamente il plugin, perché gli script dei plugin si trovano in cartelle con il loro nome. Per le terze parti l’origine del file indica il servizio. È un vantaggio notevole rispetto alla disattivazione dei plugin uno alla volta, che resta utile come verifica ma non dice nulla sulle condizioni reali degli utenti.
Un esempio concreto
Un portale di annunci ha un INP scarso da smartphone, ma i test in laboratorio non riproducono il problema: i filtri e i pulsanti rispondono rapidamente. Il sito aggiunge al proprio monitoraggio reale i dati dei fotogrammi lunghi associati all’interazione peggiore di ogni visita. Dopo una settimana, i dati mostrano che quasi il 40% del tempo di script nei fotogrammi lenti viene da un widget di chat, attraverso un timer che controlla ogni pochi secondi la presenza di operatori disponibili, e un altro quarto da un tag manager che esegue lavoro ogni volta che l’utente scorre. Gli utenti colpiti sono quelli che interagiscono mentre questi timer sono in esecuzione, un caso che in laboratorio capitava raramente. Caricato il widget solo all’apertura della chat e ridotti gli eventi di scorrimento osservati dal tag manager, l’INP da smartphone rientra nella soglia buona in meno di un mese.
In sintesi
La Long Animation Frames API misura i fotogrammi che richiedono più di 50 millisecondi, comprendendo script e rendering, e indica quali script li hanno occupati, con file, tipo di chiamata, durata e layout forzato. È il collegamento che mancava tra l’INP misurato sugli utenti reali e le sue cause. Raccolta insieme alle metriche con la libreria web-vitals o con un sistema di monitoraggio, e aggregata per origine, rivela quali terze parti e quali parti del codice bloccano le interazioni. Non sostituisce il laboratorio, ma gli dice dove guardare, e trasforma la ricerca dei colpevoli di un INP scarso da un’indagine per tentativi a una lettura di dati.
