First Input Delay (FID)

Sappiamo tutti quanto sia importante fare una buona prima impressione. È importante per conoscere nuove persone e anche per creare esperienze sul web.

Sul web, una buona prima impressione può fare la differenza se una persona diventa un utente fedele o se esce e non torna mai più. La domanda è: cosa produce una buona impressione e come si misura il tipo di impressione che stai probabilmente generando sui tuoi utenti?

Sul web, le prime impressioni possono assumere molte forme diverse: abbiamo le prime impressioni del design e dell'aspetto di un sito, nonché le prime impressioni della sua velocità e reattività.

Sebbene sia difficile misurare quanto gli utenti apprezzino il design di un sito con le API web, misurare la sua velocità e la sua reattività non lo è.

La prima impressione che gli utenti hanno della velocità di caricamento del tuo sito può essere misurata con First Contentful Paint (FCP). Tuttavia, la velocità di colorazione dei pixel sullo schermo è solo una parte del messaggio. È altrettanto importante il livello di reattività del sito quando gli utenti provano a interagire con questi pixel.

La metrica First Input Delay (FID) consente di misurare la prima impressione dell'utente circa l'interattività e la reattività del sito.

Che cos'è il FID?

FID misura il tempo che intercorre tra la prima interazione di un utente con una pagina (ovvero quando fa clic su un link, tocca un pulsante o utilizza un controllo personalizzato basato su JavaScript) al momento in cui il browser è effettivamente in grado di iniziare a elaborare i gestori di eventi in risposta a tale interazione.

Qual è un buon punteggio FID?

Per offrire una buona esperienza utente, i siti devono cercare di avere un First Input Delay pari o inferiore a 100 millisecondi. Per assicurarti di raggiungere questo target per la maggior parte dei tuoi utenti, un'ottima soglia da misurare è il 75° percentile di caricamenti pagine, segmentati su dispositivi mobili e computer.

FID nel dettaglio

Come sviluppatori che scrivono codice che risponde agli eventi, spesso presumiamo che il nostro codice venga eseguito immediatamente, non appena si verifica l'evento. Gli utenti, però, hanno spesso riscontrato il contrario: abbiamo caricato una pagina web sul nostro telefono, provato a interagirci e, dopo essere stato frustrato, non è successo nulla.

In generale, il ritardo nell'input (nota anche come latenza di input) si verifica perché il thread principale del browser è impegnato a fare qualcos'altro, quindi non può (ancora) rispondere all'utente. Un motivo comune per cui ciò può accadere è che il browser sia impegnato ad analizzare ed eseguire un file JavaScript di grandi dimensioni caricato dalla tua app. Nel frattempo, non può eseguire alcun listener di eventi perché il codice JavaScript che sta caricando potrebbe chiedergli di fare qualcos'altro.

Considera la seguente sequenza temporale di un caricamento tipico di una pagina web:

La visualizzazione sopra mostra una pagina che effettua un paio di richieste di rete per risorse (molto probabilmente file CSS e JS) e, al termine del download, le risorse vengono elaborate nel thread principale.

Ciò si traduce in periodi in cui il thread principale è temporaneamente occupato, come indicato dai blocchi task di colore beige.

In genere, i lunghi ritardi nella prima immissione si verificano tra First Contentful Paint (FCP) e Time to Interactive (TTI), perché la pagina ha eseguito il rendering di alcuni dei suoi contenuti, ma non è ancora interattiva in modo affidabile. Per illustrare come ciò può accadere, FCP e TTI sono stati aggiunti alla sequenza temporale:

Potresti aver notato un certo periodo di tempo (incluse tre attività lunghe) tra FCP e TTI: se un utente cerca di interagire con la pagina in quel lasso di tempo (ad esempio facendo clic su un link), si verifica un ritardo tra il momento in cui viene ricevuto il clic e il momento in cui il thread principale può rispondere.

Considera cosa accadrebbe se un utente tentasse di interagire con la pagina verso l'inizio dell'attività più lunga:

Poiché l'input si verifica mentre il browser sta eseguendo un'attività, deve attendere il completamento dell'attività prima di poter rispondere all'input. Il tempo di attesa è il valore FID per l'utente in questa pagina.

Che cosa succede se un'interazione non ha un listener di eventi?

FID misura il delta tra la ricezione di un evento di input e il momento in cui il thread principale è inattivo. Ciò significa che il FID viene misurato anche nei casi in cui non è stato registrato un listener di eventi. Il motivo è che molte interazioni degli utenti non richiedono un listener di eventi, ma per essere eseguito il thread principale deve essere inattivo.

Ad esempio, tutti i seguenti elementi HTML devono attendere il completamento delle attività in corso sul thread principale prima di rispondere alle interazioni dell'utente:

• Campi di testo, caselle di controllo e pulsanti di opzione (<input>, <textarea>)
• Seleziona menu a discesa (<select>)
• link (<a>)

Perché prendere in considerazione solo il primo input?

Sebbene un ritardo dovuto a qualsiasi input possa causare un'esperienza utente negativa, ti consigliamo principalmente di misurare il ritardo del primo input per alcuni motivi:

• Il primo ritardo di input sarà la prima impressione dell'utente sulla reattività del tuo sito e le prime impressioni sono fondamentali per dare forma alla nostra impressione generale della qualità e dell'affidabilità di un sito.
• I maggiori problemi di interattività che oggi riscontriamo sul web si verificano durante il caricamento della pagina. Pertanto, riteniamo che all'inizio concentrarsi sul miglioramento dell'interazione del primo 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 nella prima interazione (suddivisione del codice, caricamento iniziale di codice JavaScript e così via) non sono necessariamente le stesse per correggere i ritardi lenti nell'input dopo il caricamento della pagina. Separando queste metriche saremo in grado di fornire linee guida più specifiche sul rendimento agli sviluppatori web.

Cosa viene conteggiato come primo input?

Il valore FID è una metrica che misura l'adattabilità di una pagina durante il caricamento. Pertanto, si concentra solo sugli eventi di input di azioni discrete come clic, tocchi e pressione dei tasti.

Altre interazioni, come lo scorrimento e lo zoom, sono azioni continue e hanno vincoli di prestazioni completamente diversi (anche i browser sono spesso in grado di nascondere la propria latenza eseguendoli in un thread separato).

In altre parole, il FID si concentra sull'R (reattività) nel modello di prestazioni RAIL, mentre lo scorrimento e lo zoom sono più correlati ad A (animazione) e le loro qualità di prestazioni dovrebbero essere valutate separatamente.

Che cosa succede se un utente non interagisce con il tuo sito?

Non tutti gli utenti interagiranno con il tuo sito ogni volta che lo visitano. Inoltre, non tutte le interazioni sono pertinenti per il FID (come menzionato nella sezione precedente). Inoltre, le prime interazioni di alcuni utenti saranno in momenti negativi (quando il thread principale è occupato per un periodo di tempo prolungato) e le prime interazioni di alcuni utenti saranno nei momenti opportuni (quando il thread principale è completamente inattivo).

Ciò significa che alcuni utenti non avranno valori FID, altri avranno valori FID bassi e alcuni utenti avranno probabilmente valori FID elevati.

Il modo in cui monitori, generi report e analizzi il FID sarà probabilmente un po' diverso da altre metriche a cui potresti essere abituato. La prossima sezione spiega come procedere al meglio.

Perché considerare solo il ritardo di input?

Come accennato in precedenza, FID misura solo il "ritardo" nell'elaborazione degli eventi. Non misura il tempo di elaborazione degli eventi né il tempo impiegato dal browser per aggiornare l'interfaccia utente dopo l'esecuzione dei gestori di eventi.

Anche se questo periodo di tempo è importante per l'utente e influisce sull'esperienza, non è incluso in questa metrica perché ciò potrebbe spingere gli sviluppatori ad aggiungere soluzioni alternative che peggiorano effettivamente l'esperienza. In altre parole, potrebbero includere la logica del gestore di eventi in un callback asincrono (tramite setTimeout() o requestAnimationFrame()) per separarla dall'attività associata all'evento. Il risultato sarebbe un miglioramento del punteggio della metrica, ma una risposta più lenta percepita dall'utente.

Tuttavia, mentre FID misura solo la parte "ritardata" della latenza degli eventi, gli sviluppatori che vogliono monitorare una parte maggiore del ciclo di vita degli eventi possono farlo utilizzando l'API Event Timing. Per ulteriori dettagli, consulta la guida alle metriche personalizzate.

Come misurare il FID

Il FID è una metrica che può essere misurata solo sul campo, in quanto richiede un utente reale per interagire con la pagina. Puoi misurare il FID con i seguenti strumenti.

Strumenti da campo

• Report sull'esperienza utente di Chrome
• PageSpeed Insights
• Search Console (report Segnali web essenziali)
• Libreria JavaScript di web-vitals

Misura FID in JavaScript

Per misurare FID in JavaScript, puoi utilizzare l'API Event Timing. L'esempio seguente mostra come creare un elemento PerformanceObserver che rimane in ascolto delle voci first-input e le registra nella console:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const delay = entry.processingStart - entry.startTime;
    console.log('FID candidate:', delay, entry);
  }
}).observe({type: 'first-input', buffered: true});

Nell'esempio precedente, il valore di ritardo della voce first-input viene misurato prendendo il delta tra i timestamp startTime e processingStart della voce. Nella maggior parte dei casi, si tratterà del valore FID; tuttavia, non tutte le voci first-input sono valide per la misurazione del FID.

La seguente sezione elenca le differenze tra i report dell'API e il modo in cui viene calcolata la metrica.

Differenze tra la metrica e l'API

• L'API invierà le voci first-input per le pagine caricate in una scheda in background, ma queste pagine devono essere ignorate durante il calcolo del FID.
• L'API invierà anche le voci first-input se la pagina è stata sottoposta a background prima del primo input, ma queste pagine devono essere ignorate anche durante il calcolo del FID (gli input vengono presi in considerazione solo se la pagina è rimasta in primo piano per tutto il tempo).
• L'API non segnala le voci first-input quando la pagina viene ripristinata dalla cache back/forward, ma in questi casi il FID dovrebbe essere misurato in quanto gli utenti le percepiscono come visite di pagine distinte.
• L'API non segnala gli input che si verificano all'interno degli iframe, ma la metrica sì poiché fanno parte dell'esperienza utente della pagina. Potrebbe essere visualizzata come differenza tra CrUX e RUM. Per misurare correttamente il FID, dovresti prendere in considerazione questa opzione. I frame secondari possono utilizzare l'API per segnalare le voci first-input al frame principale per l'aggregazione.

Anziché memorizzare tutte queste sottili differenze, gli sviluppatori possono utilizzare la libreria JavaScript di web-vitals per misurare il FID, che le gestisce per te (ove possibile, tieni presente che il problema relativo all'iframe non è coperto):

import {onFID} from 'web-vitals';

// Measure and log FID as soon as it's available.
onFID(console.log);

Puoi fare riferimento al codice sorgente di onFID() per un esempio completo di come misurare FID in JavaScript.

Analisi e report sui dati del FID

A causa della varianza prevista nei valori FID, è fondamentale che quando generi report sul FID esamini la distribuzione dei valori e ti concentri sui percentili più alti.

Mentre la scelta del percentile per tutte le soglie di Segnali web essenziali è la 75a, per FID in particolare consigliamo ancora di considerare il 95°-99° percentile, in quanto corrisponderanno alle prime esperienze particolarmente negative che gli utenti hanno con il tuo sito. e ti mostrerà le aree che richiedono il maggiore miglioramento.

anche se suddividi i report per categoria o tipo di dispositivo. Ad esempio, se esegui report separati per computer e dispositivi mobili, il valore FID che ti interessa di più sui computer desktop dovrebbe essere compreso tra il 95° e il 99° percentile degli utenti di computer e il valore FID che ti interessa di più sui dispositivi mobili dovrebbe essere tra il 95° e il 99° percentile degli utenti di dispositivi mobili.

Come migliorare il FID

È disponibile una guida completa sull'ottimizzazione del FID che illustra le tecniche per migliorare questa metrica.

Log delle modifiche

Occasionalmente, i bug vengono scoperti nelle API utilizzate per misurare le metriche e talvolta nelle definizioni delle metriche stesse. Di conseguenza, è necessario apportare talvolta delle modifiche, che possono apparire come miglioramenti o regressioni nei report e nelle dashboard interni.

Per aiutarti a gestire questa situazione, tutte le modifiche all'implementazione o alla definizione di queste metriche verranno visualizzate in questo log delle modifiche.

Se hai feedback su queste metriche, puoi fornirle nel gruppo Google web-vitals-feedback.