Prosegue il nostro percorso di avvicinamento alla partenza della Google Page Experience, che dal prossimo maggio introdurrà una serie di nuovi fattori di ranking su Google, a cominciare dai Core Web Vitals, i tre Segnali Web Essenziali che rappresentano le metriche basilari che definiscono l’esperienza di un utente sulle nostre pagine. Oggi ci concentriamo proprio su uno di questi aspetti, ovvero sul First Input Delay, l’elemento che misura l’interattività della pagina: ecco cos’è e come ottimizzare tale parametro.

Che cos’è il First Input Delay (FID)

Il First Input Delay (FID) o in italiano ritardo prima interazione è una metrica incentrata sull’utente che misura la reattività del caricamento e quantifica l’esperienza che gli utenti provano quando tentano di interagire con pagine che non rispondono.

Come spiegano la guida di Google e l’approfondimento su web.dev, FID misura il tempo trascorso tra la prima interazione di un utente con una pagina (clic su un link, tocco di un pulsante, uso di un controllo personalizzato basato su JavaScript) e il momento in cui il browser risponde effettivamente all’interazione.

La rappresentazione del FID

È il tempo, espresso in millisecondi, che intercorre tra la prima interazione dell’utente su una pagina web e la risposta del browser a tale interazione, non includendo lo scorrimento e lo zoom in tale valutazione.

Volendo usare una similitudine, il FID è come misurare il tempo che intercorre tra il momento in cui qualcuno suona il campanello e la risposta alla porta. Potrebbero esserci molte ragioni per il ritardo: ad esempio, “forse la persona è lontana dalla porta o non può muoversi rapidamente”. Allo stesso modo, le pagine web potrebbero essere occupate in altri lavori o il dispositivo dell’utente potrebbe essere lento.

Inoltre, bisogna chiarire che FID misura solo il “ritardo” nell’elaborazione degli eventi e non il tempo di elaborazione dell’evento stesso né il tempo impiegato dal browser per aggiornare l’interfaccia utente dopo aver eseguito i gestori di eventi – fattori che influiscono sull’esperienza dell’utente, ma che, se inclusi, potrebbero “incentivare gli sviluppatori a rispondere agli eventi in modo asincrono, il che migliorerebbe la metrica ma probabilmente peggiorerebbe l’esperienza”.

La metrica della interattività

Semplificando, un FID basso significa che la pagina è più facilmente utilizzabile e maggiore è il ritardo, peggiore sarà l’esperienza dell’utente.

La misurazione del ritardo prima interazione viene derivata da qualsiasi elemento interattivo cliccato per primo da un utente ed è un valore importante per le pagine in cui l’utente deve eseguire un’azione.

Il tempo che intercorre tra il momento in cui il contenuto viene dipinto sulla pagina e il momento in cui tutte le funzionalità diventano reattive all’interazione umana spesso varia in base alle dimensioni e alla complessità del codice JavaScript che deve essere scaricato, analizzato ed eseguito sul thread principale e sulla velocità del dispositivo o la sua mancanza (ad esempio, sui dispositivi mobili di fascia bassa), ci spiegano gli sviluppatori di Mozilla.

Ridurre il tempo di inizializzazione del sito ed eliminare le attività lunghe può aiutare a eliminare i primi ritardi di input.

L’importanza del ritardo prima interazione

Possiamo pensare al First Input Delay come alla “prima impressione” che il sito fornisce agli utenti: è vero che – tecnicamente – il primo impatto di un visitatore con la pagina è rappresentato dal First Contentful Paint (FCP), ma “dipingere i pixel sullo schermo è solo una parte della storia e altrettanto importante è quanto sia reattivo il tuo sito quando gli utenti cercano di interagire con quei pixel”, dice Philip Walton, ingegnere presso Google.

Sul Web, una buona prima impressione può fare la differenza tra un visitatore che diventa un utente fedele o che se ne vada e non torni più, e a breve sarà una metrica ufficiale per stabilire se il sito sta creando delle buone esperienze, e in particolare per misurare la prima impressione dell’utente sull’interattività e la reattività del sito.

Lavorare sul First Input Delay ci permette di affrontare la sensazione di fastidio che gli utenti potrebbero provare durante il caricamento della pagina, e la sua ottimizzazione avrà anche un impatto positivo su vari altri aspetti delle prestazioni web – oltre che sulle possibilità di posizionamento su Google, a breve.

Il punteggio per un buon First Input Delay

Per fornire una buona esperienza utente, i siti dovrebbero sforzarsi di avere un ritardo prima interazione inferiore a 100 millisecondi.

Per essere sicuri di raggiungere questo obiettivo per la maggior parte dei nostri utenti, una buona soglia da misurare è il 75esimo percentile dei caricamenti di pagina, sia da dispositivi mobili che da desktop.

Le spiegazioni sul FID

Il lungo articolo di Walton si sofferma anche sulle motivazioni che hanno spinto Google a dare priorità al First Input Delay come segnale web essenziale – sulla scia delle considerazioni già espresse nei mesi passati su questo set di metriche.

Il ritardo prima interazione misura il delta tra “quando viene ricevuto un evento di input e quando il thread principale è inattivo”, e quindi il FID viene misurato anche nei casi in cui un listener di eventi non è stato registrato, perché “molte interazioni degli utenti non hanno bisogno di un listener di eventi, ma richiedono che il thread principale sia inattivo per lanciare l’esecuzione”.

In qualità di sviluppatori che scrivono codice che risponde agli eventi, dice il Googler, “spesso presumiamo che il nostro codice verrà eseguito immediatamente, non appena si verifica l’evento”. Ma come utenti, tutti abbiamo spesso sperimentato il contrario: abbiamo caricato una pagina Web sul nostro telefono, abbiamo provato a interagire con essa e poi non è successo nulla, causandoci un senso di frustrazione.

Quando si verifica il ritardo

In generale, il ritardo di input (ovvero la latenza di input) si verifica “perché il thread principale del browser è impegnato in qualcos’altro, quindi non può (ancora) rispondere all’utente”. Un motivo comune per cui ciò potrebbe accadere è che il browser è impegnato “nell’analisi ed esecuzione di un file JavaScript di grandi dimensioni caricato dalla tua app; mentre lo fa, non può eseguire alcun listener di eventi perché il JavaScript che sta caricando potrebbe dirgli di fare qualcos’altro”.

Sequenza temporale di un tipico caricamento di una pagina web

Questa immagine (da web.dev, come tutte le altre in pagina) rappresenta la sequenza temporale di un tipico caricamento di una pagina web: una pagina sta effettuando un paio di richieste di rete per le risorse (molto probabilmente file CSS e JS) e, al termine del download di tali risorse, vengono elaborate sul thread principale. Ciò si traduce in periodi in cui il thread principale è momentaneamente occupato, il che è indicato dai blocchi di attività di colore beige.

Ritardi con FCP e TTI

In genere, si verificano lunghi ritardi nel primo input tra First Contentful Paint (FCP) e Time to Interactive (TTI) “perché la pagina ha reso parte del suo contenuto ma non è ancora interattivo in modo affidabile”, e quest’altra illustrazione con l’aggiunta alla timeline di FCP e TTI lo mostra chiaramente. Si vede infatti che “c’è una discreta quantità di tempo (incluse tre attività lunghe) tra FCP e TTI, e se un utente cerca di interagire con la pagina durante quel periodo (ad esempio, facendo clic su un collegamento), ci sarà un ritardo tra il clic viene ricevuto e quando il thread principale è in grado di rispondere”.

FID e interazione dell'utenteQuest’altra immagine indica cosa succede se un utente tenta di interagire con la pagina vicino all’inizio dell’attività più lunga: poiché l’input si verifica mentre il browser sta eseguendo un’attività, deve attendere il completamento del task prima di poter rispondere all’input.

Il tempo che deve attendere è il valore FID per questo utente in questa pagina.

Quali sono i first input e perché si considera la prima reazione

Essendo una metrica che misura la reattività di una pagina durante il caricamento, FID si concentra solo sugli eventi di input da azioni discrete come clic, tocchi e pressioni di tasti, mentre altre interazioni, come lo scrolling e lo zoom, sono “azioni continue e hanno vincoli di prestazioni completamente diversi” (e, inoltre, i browser sono spesso in grado di nascondere la loro latenza eseguendoli su un thread separato).

In termini più tecnici, “FID si concentra sulla R (reattività) nel modello di prestazioni RAIL, mentre lo scorrimento e lo zoom sono più correlati ad A (animazione) e le loro qualità di prestazione dovrebbero essere valutate separatamente”, spiega l’ingegnere di Google.

In realtà, il ritardo di qualsiasi input può portare a una cattiva esperienza utente, ma Google consiglia primariamente di misurare il first input delay per alcuni motivi:

  • Il FID sarà la prima impressione dell’utente sulla reattività del sito, e le prime impressioni sono fondamentali per plasmare la nostra impressione generale sulla qualità e l’affidabilità di un sito.
  • I maggiori problemi di interattività che “vediamo oggi sul Web si verificano durante il caricamento della pagina: pertanto, riteniamo che concentrarsi inizialmente sul miglioramento della prima interazione dell’utente del sito avrà il maggiore impatto sul miglioramento dell’interattività complessiva del web”.
  • Le soluzioni consigliate su come i siti dovrebbero correggere i ritardi elevati del primo input non sono necessariamente le stesse soluzioni per correggere i ritardi di input lenti dopo il caricamento della pagina, e separando queste metriche “saremo in grado di fornire linee guida più specifiche sulle prestazioni agli sviluppatori web”.

Riassumendo, non tutte le interazioni sono rilevanti per FID; inoltre, non tutti gli utenti interagiranno con il sito ogni volta che lo visitano e “le prime interazioni di alcuni utenti avverranno in momenti difficili (quando il thread principale è occupato per un periodo di tempo prolungato) mentre quelle di altri utenti saranno in momenti buoni (quando il thread principale è completamente inattivo)”.

Ciò significa che alcuni utenti non avranno valori FID, alcuni utenti avranno valori FID bassi e alcuni utenti avranno probabilmente valori FID alti, e per questo motivo è importante imparare a monitorare e analizzare il first input delay con specifiche modalità e strumenti appositi.

Come misurare il First Input Delay

Anche il FID è una metrica che si può misurare solo sul campo – ne parlavamo già a proposito di come misurare i Web Vitals – perché “richiede che un utente reale interagisca con la tua pagina” e quindi non può essere misurato in laboratorio.

In realtà, rivela la guida, la metrica del Total Blocking Time (TBT, tempo di blocco totale) “è misurabile in laboratorio, si correla bene con il FID sul campo e cattura anche i problemi che influenzano l’interattività”, e “le ottimizzazioni che migliorano TBT in laboratorio dovrebbero anche migliorare il FID per i tuoi utenti”.

Ad ogni modo, possiamo misurare il FID con quattro strumenti:

  • Chrome User Experience Report, il Rapporto sull’esperienza utente di Chrome
  • PageSpeed ​​Insights
  • Search Console (rapporto Segnali Essenziali Web)
  • Libreria JavaScript web-vitals

A causa della varianza prevista nei valori FID, è fondamentale che “in un report su FID si guardi la distribuzione dei valori e ci si concentri sui percentili più alti”.

Sebbene la scelta del percentile per tutte le soglie di dati vitali fondamentali sia il 75°, infatti, per FID in particolare Google “consiglia vivamente di considerare il 95° e il 99° percentile, poiché corrisponderanno alle prime esperienze particolarmente negative che gli utenti hanno con il tuo sito e ti mostreranno le aree che necessitano di maggiori miglioramenti”.

Come migliorare il First Input Delay

Tra i vari interventi che possono consentirci di ridurre il tempo del ritardo della prima interazione ci sono:

  • La riduzione dell’impatto del codice di terze parti.
  • La riduzione del tempo di esecuzione di JavaScript.
  • La riduzione al minimo del lavoro sul thread principale.
  • La minimizzazione del numero di richieste e la riduzione delle dimensioni di trasferimento.

In genere, la causa principale di un FID scadente è l’esecuzione pesante di JavaScript, e quindi l’ottimizzazione del modo in cui JavaScript analizza, compila ed esegue sulla tua pagina web ridurrà direttamente il FID.

Per ottimizzare questo aspetto e ridurre l’occupazione del thread principale (che impedisce al browser di rispondere alle interazioni dell’utente) possiamo seguire alcune best practices, come ad esempio:

  • Spezzare i compiti lunghi in attività più piccole e asincrone.
  • Ottimizzare la pagina per la disponibilità all’interazione.
  • Usare un web worker, che consente di eseguire JavaScript su un thread in background.
  • Ridurre il tempo di esecuzione di JavaScript, rimandando JavaScript inutilizzato e riducendo al minimo i polyfill inutilizzati.