Non avremo mai “una seconda possibilità di fare una prima impressione”, e per questo “perfezionare il first input delay è la chiave per una grande esperienza in pagina”: si apre con queste parole, semplici e chiare, il video con cui Patrick Kettner di Google ci accompagna verso l’approfondimento su come misurare e migliorare il FID, metrica che come sappiamo fa parte del pacchetto Page Experience di Google e, quindi, è un fattore di ranking sul motore di ricerca.

I ritardi sul sito creano frustrazione e cattiva esperienza

Dal punto di vista tecnico, First Input Delay è un’API che misura quanto tempo impiega il nostro sito a reagire dopo che un utente ha compiuto un’interazione con esso.

Patrick Kettner spiega come misurare FID

Nel suo intervento su YouTube, Kettner spiega che è importante assicurarsi che le persone che usano il nostro sito subiscano e avvertano meno ritardi possibile, perché i ritardi (delay in inglese) “ci interrompono, interrompono il nostro processo di pensiero e rendono più difficile concentrarsi o completare i nostri obiettivi”, creando di fatto un’esperienza frustante quando cerchiamo di navigare in un sito, usare un’app o semplicemente guardare un video.

La metrica FID, per valutare i tempi di interattività

Proprio per rafforzare questo concetto, all’interno del complesso dei fattori della esperienza sulle pagine è stata inserita la metrica del first input delay (FID o ritardo della prima interazione), un’api web che fa parte anche del gruppo inaugurale di Core Web Vitals individuati da Google nello scorso anno.

Il First Input Delay in grafica

In particolare, il FID “misura quanto tempo in millisecondi serve al tuo sito per reagire dopo che qualcuno interagisce con esso”, ovvero il tempo che passa da quando un utente fa clic su un pulsante o tocca un input di testo fino a quando il browser inizia effettivamente a rispondere. Con questa metrica, quindi, “misuriamo il ritardo nell’elaborazione dei dati e delle interazioni, non il tempo effettivamente necessario per elaborare quei dati“.

Secondo il Developer Advocate di Google, possiamo pensare al first input delay come dato su “quanto tempo ci vuole perché la tua pagina sembri essere interattiva e sia reattiva per l’utente la prima volta che la usa”.

La misurazione del First Input Delay

Proprio come ogni parte del Page Experience, ogni singolo url del sito è valutato in base al FID indipendentemente, basandosi direttamente su dati di veri utenti che il vostro sito. Qualunque sia il punteggio delle pagine, quindi, possiamo essere certi che i numeri che leggiamo riflettono ciò che gli utenti stanno effettivamente sperimentando, perché i punteggi FID provengono dal rapporto mensile sull’esperienza utente di Chrome, come già dicevamo in questo articolo sulle misurazioni dei Core Web Vitals.

Un altro aspetto su cui Kettner ci invita a riflettere è che “la homepage potrebbe avere valori fantastici, ma la pagina prodotto o gli articoli potrebbero essere un po’ lontani dalla perfezione”, ma il risultato prestazionale di una pagina – indipendentemente da quale sia, positivo o negativo – non impatta su quello di un’altra pagina perché nella page experience “ogni URL è un’isola”.

Come trovare e leggere i valori di First Input Delay

Essendo una metrica intrinsecamente costruita sul tempo in cui un sito reagisce alle interazioni, per ottenere una misurazione accurata del First Input Delay possiamo fare affidamento solo su user measurements (misurazioni degli utenti) che provengono da utenti del mondo reale, analytics interni e privati e dati che possiamo visualizzare all’interno del rapporto Segnali Essenziali Web della Search Console.

È inoltre possibile controllare rapidamente le performance delle nostre pagine con il tool Pagespeed insights – una versione online ospitata dello stesso strumento di Lighthouse, che fa parte dei Chrome dev tools – che mostra le prestazioni delle pagine in un ambiente di test configurato per avvicinarsi alla velocità di connessione e alle prestazioni del dispositivo di un utente medio odierno del Web.

Se un url è online da più di un mese, infine, può essere incluso nel Chrome user experience report, che indica direttamente i risultati effettivi per i tre parametri Core Web Vitals.

Quali sono i punteggi del FID

Ora abbiamo quindi il valore del First Input Delay delle pagine del nostro sito, ma come dobbiamo interpretare questo numero? Lo spiega sempre Kettner, che ricorda come per i Core Web Vitals all’interno della Page Experience “non esiste una cosa come passare o non passare”, perché questi parametri sono tutti utilizzati come guide che la Ricerca Google usa per creare “relative differenze di prestazioni tra gli URL, così da verificare come si comportano l’uno rispetto all’altro”.

In generale, comunque, ci sono dei valori a cui far riferimento: “Un buon obiettivo è quello di avere circa il 75% dei visitatori del tuo sito visitatori che sperimentano un ritardo nel primo input di inferiore a 100 millisecondi“; questo intervallo temporale di 100 millisecondi è stato a lungo considerato il punto in cui le persone percepiscono le interfacce utente come se si comportassero istantaneamente.

Le situazioni iniziano a diventare problematiche quando il ritardo si prolunga tra i 100 e i 300 millisecondi, mentre “qualsiasi cosa oltre i 300 millisecondi è un ritardo notevole e probabilmente causerà un’esperienza peggiore per i vostri utenti”.

Inoltre, è bene chiarire che per avere un valore FID è necessario che la pagina preveda una interazione dell’utente: in caso contrario, se la vostra pagina non offre niente con cui interagire o se le persone non cliccano mai su pulsanti o input, non esisterà un valore FID registrato.

Come calcolare il First Input Delay manualmente

Se vogliamo calcolare il first input delay di pagine nuove o di URL non inclusi all’interno del Chrome User Experience Report serve solo “un po’ di sforzo in più”, perché è possibile “capire il FID da soli usando le stesse API, in quanto tutti i dati di campo della Page Experience provengono dai tuoi utenti reali del mondo reale”.

API per misurare il FID

Più in generale, tutti noi possiamo calcolare manualmente il FID “aggiungendo un po’ di JavaScript alla nostra pagina”: tutti i segnali Web essenziali sono infatti disponibili tramite API JavaScript e, specificamente, attraverso PerformanceObserver. Questi osservatori ci danno un evento o una lista di eventi che corrispondono al tipo di eventi di performance che ci interessano.

Quando il browser determina che è avvenuto un primo input, eseguirà la funzione che abbiamo impostato, passandoci l’elenco di eventi che corrispondono a ciò che abbiamo richiesto; anche se il primo input avrà probabilmente un solo evento, il PerformanceObserver ci passerà sempre una lista di eventi al nostro callback, quindi il nostro codice itera sulle risposte chiamando getEntries.

Per ogni voce, guardiamo l’inizio dell’elaborazione e sottraiamo il tempo di inizio: la differenza ci permette di quantificare il ritardo del primo input. Possiamo prendere questi numeri e inviarli alla nostra infrastruttura di analytics per iniziare ad avere una buona idea di come saranno i nostri risultati di FID.

Utilizzare strumenti di analisi ci permette di eseguire un monitoraggio dei dati molto più dettagliato, facendo emergere ad esempio dei pattern come la posizione dell’utente, il tipo di dispositivo usato o altre informazioni che potrebbero non essere così evidenti attraverso gli strumenti ufficiali della Page Experience.

Problemi comuni con il FID e soluzioni pratiche

Il video di Google ci accompagna anche alla scoperta di alcuni problemi comuni con il First Input Delay, fornendoci indicazioni pratiche per la risoluzione positiva di tali situazioni, che spesso si traduce in un intervento per velocizzare JavaScript.

  1. Defer, delay o delete JavaScript

Per definizione, ci dice infatti Kettner, “qualsiasi ritardo che si sta verificando è legato al codice JavaScript che è in esecuzione sulla tua pagina”, perché tutto il codice della pagina viene eseguito nello stesso thread per impostazione predefinita e il browser può fare una sola cosa alla volta. Quindi, basta un po’ di codice che impieghi più tempo del previsto per bloccare tutto, anche azioni che le persone che usano il sito potrebbero cercare di compiere.

Questo potrebbe dipendere da “un grande pezzo di JavaScript che viene analizzato o caricato quando la pagina è inizialmente caricata su un event handler, da un event handler bloccato da qualcosa di pesante o semplicemente lento, o ancora da un eccesso di codice che sta cercando di eseguire in una volta sola”, e provoca un rallentamento complessivo del sito.

Se pertanto abbiamo dei problemi con il First Input Delay, il primo suggerimento è di controllare se stiamo caricando troppo JavaScript – il riferimento quantitativo è “qualsiasi cosa più grande di 200 kilobyte” – e procedere poi verificando il code splitting, la suddivisione del codice, che è una caratteristica incorporata in tutti i moderni JavaScript bundler, che permettono appunto di suddividere il codice in pezzi più piccoli per evitare di bloccare il resto della pagina dal reagire all’input dell’utente.

Dopo la suddivisione, qualsiasi codice che non sia essenziale per il caricamento della pagina dovrebbe essere caricato usando gli attributi async o defer sul loro tag script: usando defer diciamo al browser che lo script non cambierà il layout della pagina, quindi non dovrebbe bloccare il rendering della pagina mentre viene caricata o analizzata. L’attributo async è molto simile a defer, solo che lo porta un passo avanti, perché segnala di non aspettare qualsiasi altro script: usando async diciamo al browser di eseguire il codice senza bloccare in anticipo qualsiasi altro script.

Trovandoci già a scavare nel codice sorgente, il Developer Advocate ci consiglia di metterci alla ricerca di “codice che può essere semplicemente cancellato“, perché può essere facile includere accidentalmente polyfill o workaround molto tempo dopo che siano effettivamente necessari.

  1. Cercare UI pesanti

Spesso, la prima interazione che un utente ha con una pagina è qualcosa posizionato nella parte alta della pagina, cose come un pulsante di menu o l’input di ricerca; se riscontriamo problemi con il FID ma non riusciamo a comprendere cosa stia causando quel punteggio, è una “buona idea iniziare a tracciare gli elementi della tua pagina i cui ritardi sono misurati”.

Elementi che rallentano l'interazione

Possiamo usare lo snippet di codice su cui stavamo lavorando prima, da cui possiamo avere accesso alle API della stessa entryobject, e in particolare entry.target, che ci permette di sapere effettivamente qual è il ritardo misurato dell’elemento con cui stavamo interagendo.

Questo passaggio può essere davvero utile se abbiamo sulla pagina un gran numero di link, pulsanti o altri elementi cliccabili o tappabili e non siamo del tutto sicuri di quale sia quello che sta trascinando i punteggi prestazionali verso il basso.

Dopo aver individuato quale obiettivo è spesso associato con le persone che hanno un FID elevato, possiamo “iniziare a scavare nel codice del sito” per capire quali eventi vi sono legati e ogni listener eventualmente collegato.

  1. Interrompere i task lunghi

Il terzo aspetto da prendere in considerazione è la suddivisione di compiti lunghi (già al centro di questi consigli per ottimizzare la Page Experience del sito): anche se il nostro codice non ha bisogno di essere diviso, potrebbe comunque essere utile intervenire sui task, che sono “solo cose che il tuo codice sta facendo, come la stesura della tua web app, downloading di stati o reazioni all’input  dell’utente”.

Istruzioni per individuare i long task

Un task è lungo quando “richiede più di 50 millisecondi per essere completato”, dice Kettner, e se abbiamo problemi con il First Input Delay “guardare i task lunghi è un ottimo punto di partenza per vedere dove si potrebbero potenzialmente apportare miglioramenti“. Inoltre, ricorda, i long task sono evidenziati negli strumenti di Chrome Dev.

Se vogliamo cercare i compiti lunghi “sui dispositivi degli utenti per costruire una correlazione tra i risultati dell’esperienza sulla pagina e attività lunghe sul campo, possiamo programmaticamente accedervi nel modo visto prima per il first input event”.

In termini pratici, dobbiamo prima creare un PerformanceObserver e poi osservare il tipo di long task; dopo, possiamo ripetere l’operazione su ogni istanza per esaminare ogni attribuzione, così da ottenere “un po’ di informazioni sulle funzioni che possono essere di lunga durata“.

Come individuare i long task

Come sottolinea il Googler, “devtools è sicuramente uno strumento migliore, ma questa api permette di raccogliere tali informazioni dai tuoi utenti e dai tuoi strumenti di analytics, in modo da poter rintracciare correlazioni che possono essere difficili da trovare nel tuo setup locale di devtools”.

Quando troviamo un task di lunga durata, il passo successivo è quello di provare a suddividerlo in funzioni asincrone più piccole: “questo può essere semplice come avvolgere il codice in timeout impostati o richiedere frame di animazione, ma le specifiche dipendono sempre dalla situazione specifica”.

First Input Delay, l’occasione per ottimizzare il codice JavaScript sul sito

Di solito, il miglioramento del first input delay “si riduce a ottimizzare il quando, dove e perché del codice JavaScript sul tuo sito“: l’obiettivo dovrebbe essere “limitare l’uso di JS al minimo necessario per massimizzare il potenziale del sito”.

L’esperienza della pagina è nuova, ma le idee che sono dietro sono “solide e focalizzate sull’utente: se possiamo ottenere grandi risultati, allora i visitatori del sito saranno tutti più felici“.