First Input Delay (FID)

Philip Walton

Sappiamo tutti quanto sia importante fare una buona prima impressione. È importante quando si incontrano nuove persone ed è importante anche quando si creano esperienze sul web.

Sul web, una buona prima impressione può fare la differenza tra un utente che diventa fedele e uno che se ne va e non torna più. La domanda è: cos'è una buona impressione e come fai a misurare il tipo di impressione che stai facendo sui tuoi utenti?

Sul web, le prime impressioni possono assumere molte forme diverse: si generano le prime impressioni del design e dell'aspetto visivo 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, non è facile misurare la sua velocità e reattività.

La prima impressione degli utenti della velocità di caricamento del sito può essere misurata con la funzionalità First Contentful Paint (FCP). Tuttavia, la velocità con cui il tuo sito può disegnare i pixel sullo schermo è solo un aspetto del problema. È altrettanto importante la reattività del tuo sito quando gli utenti cercano di interagire con questi pixel.

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

Che cos'è l'ID cliente?

La metrica 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) e il momento in cui il browser è effettivamente in grado di iniziare a elaborare i gestori di eventi in risposta a tale interazione.

Che cos'è un buon punteggio FID?

Per offrire una buona esperienza utente, i siti dovrebbero fare in modo che il ritardo di primo input sia di 100 millisecondi o inferiore. Per assicurarti di raggiungere questo target per la maggior parte degli utenti, una buona soglia da misurare è il 75° percentile dei caricamenti di pagine, segmentati per dispositivi mobili e computer.

FID in dettaglio

In qualità di sviluppatori che scrivono codice per rispondere agli eventi, spesso supponiamo che il codice venga eseguito immediatamente, non appena si verifica l'evento. Tuttavia, come utenti, abbiamo spesso riscontrato il contrario: abbiamo caricato una pagina web sul nostro smartphone, provato a interagire con essa e poi ci siamo sentiti frustrati quando non è successo nulla.

In generale, il ritardo dell'input (ovvero la 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 di questo problema è che il browser è impegnato ad analizzare ed eseguire un file JavaScript di grandi dimensioni caricato dalla tua app. Durante questa operazione, non può eseguire un listener di eventi perché il codice JavaScript che sta caricando potrebbe indicarlo a fare qualcos'altro.

Prendi in considerazione la seguente sequenza temporale di un tipico caricamento di una pagina web:

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

Ciò comporta periodi in cui il thread principale è temporaneamente occupato, il che è indicato dai blocchi di attività di colore beige.

In genere, ritardi prima interazione lunghi si verificano tra First Contentful Paint (FCP) e Tempo all'interattività (TTI) perché la pagina ha visualizzato alcuni dei suoi contenuti, ma non è ancora interattiva in modo affidabile. Per illustrare come ciò può accadere, FCP e TTI sono stati aggiunti alle tempistiche:

Avrai notato che c'è un bel po' di tempo (incluse tre attività lunghe) tra FCP e TTI: se un utente cerca di interagire con la pagina durante questo lasso di tempo (ad esempio, facendo clic su un link), si verificherà un ritardo tra la ricezione del clic e la risposta del thread principale.

Considera cosa succederebbe se un utente provasse a interagire con la pagina all'inizio dell'attività più lunga:

Poiché l'input avviene mentre il browser è nel mezzo di un'attività, deve attendere fino al completamento dell'attività prima di poter rispondere all'input. Il tempo di attesa è il valore FID per questo utente in questa pagina.

Cosa succede se un'interazione non ha un listener di eventi?

La metrica FID misura il delta tra il momento in cui viene ricevuto un evento di input e il momento in cui il thread principale è inattivo. Ciò significa che il valore FID viene misurato anche nei casi in cui non è stato registrato un listener di eventi. Il motivo è che molte interazioni utente non richiedono un gestore di eventi, ma richiedono che il thread principale sia inattivo per essere eseguite.

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

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

Perché prendere in considerazione solo il primo input?

Sebbene un ritardo di qualsiasi input possa comportare un'esperienza utente negativa, ti consigliamo principalmente di misurare il primo ritardo di 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 formare la nostra impressione complessiva sulla qualità e sull'affidabilità di un sito.
• I principali problemi di interattività che riscontriamo oggi sul web si verificano durante il caricamento delle pagine. Pertanto, riteniamo che l'obiettivo iniziale per migliorare l'interazione del primo utente con il sito avrà il maggiore impatto sul miglioramento dell'interattività generale del web.
• Le soluzioni consigliate per risolvere i ritardi di inserimento elevati dei siti (suddivisione del codice, caricamento di meno JavaScript in anteprima e così via) non sono necessariamente le stesse per risolvere i ritardi di inserimento lenti dopo il caricamento della pagina. Separando queste metriche saremo in grado di fornire agli sviluppatori web linee guida sul rendimento più specifiche.

Cosa viene considerato come primo input?

Il FID è una metrica che misura l'adattabilità di una pagina durante il caricamento. Di conseguenza, si concentra solo sugli eventi di input derivanti da azioni distinte come clic, tocchi e pressioni dei tasti.

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

In altre parole, l'FID si concentra sulla R (reattività) nel modello di rendimento RAIL, mentre lo scorrimento e lo zoom sono più correlati all'A (animazione) e le relative qualità di rendimento devono essere valutate separatamente.

Che cosa succede se un utente non interagisce mai 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 l'ID utente (come indicato nella sezione precedente). Inoltre, le prime interazioni di alcuni utenti avverranno in momenti inopportuni (quando il thread principale è occupato per un periodo di tempo prolungato) e le prime interazioni di altri utenti avverranno in 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, registri e analizzi l'ID utente sarà probabilmente molto diverso dall'approccio che utilizzi per le altre metriche. La sezione successiva spiega come eseguire al meglio questa operazione.

Perché considerare solo il ritardo dell'input?

Come indicato sopra, il FID misura solo il "ritardo" nell'elaborazione degli eventi. Non misura la durata totale dell'elaborazione degli eventi né il tempo necessario al browser per aggiornare l'UI dopo l'esecuzione dei gestori di eventi.

Anche se questo tempo è importante per l'utente e influisce sull'esperienza, non è incluso in questa metrica perché ciò potrebbe invogliare gli sviluppatori ad aggiungere soluzioni alternative che peggiorano l'esperienza, ovvero potrebbero racchiudere la logica del gestore eventi in un callback asincrono (tramite setTimeout() o requestAnimationFrame()) per separarla dalla task associata all'evento. Il risultato sarebbe un miglioramento del punteggio della metrica, ma una risposta più lenta per quanto riguarda la percezione dell'utente.

Tuttavia, mentre il FID misura solo la parte del "ritardo" della latenza degli eventi, gli sviluppatori che vogliono monitorare un maggior numero di questo ciclo di vita possono farlo utilizzando l'API Event Timing. Per ulteriori dettagli, consulta la guida sulle metriche personalizzate.

Come misurare il FID

La metrica FID è che può essere misurata solo sul campo, poiché richiede che un utente reale interagisca con la pagina. Puoi misurare il valore FID con i seguenti strumenti.

Strumenti sul campo

• Chrome User Experience Report
• PageSpeed Insights
• Search Console (report Core Web Vitals)
• Libreria JavaScript di web-vitals

Misurare il FID in JavaScript

Per misurare il valore FID in JavaScript, puoi utilizzare l'API Event Timing. L'esempio seguente mostra come creare un PerformanceObserver che ascolta le 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 tratta 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 creata in background prima del primo input, ma queste pagine dovrebbero essere ignorate nel calcolo del FID (gli input vengono presi in considerazione solo se la pagina è stata in primo piano per tutto il tempo).
• L'API non registra voci first-input quando la pagina viene ripristinata dalla cache back/forward, ma in questi casi il FID deve essere misurato poiché gli utenti le considerano visite di pagine distinte.
• L'API non registra gli input che si verificano all'interno degli iframe, ma la metrica lo fa poiché fanno parte dell'esperienza utente della pagina. Questo può mostrare una differenza tra CrUX e RUM. Per misurare correttamente la metrica FID, dovresti prendere in considerazione questi dati. I frame secondari possono utilizzare l'API per segnalare le proprie voci first-input al frame principale per l'aggregazione.

Analisi e generazione di report sui dati FID

A causa della varianza prevista nei valori FID, è fondamentale che, quando si esegue il report su FID, si esamini la distribuzione dei valori e si concentri sui percentili più elevati.

Sebbene la scelta percentile per tutte le soglie di Core Web Vitals sia il 75°, per FID in particolare consigliamo comunque vivamente 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 maggiori miglioramenti.

anche se segmenti i report in base alla categoria o al tipo di dispositivo. Ad esempio, se pubblichi report separati per computer e dispositivi mobili, il valore FID che ti interessa di più su computer deve essere compreso tra il 95° e il 99° percentile degli utenti di computer e il valore FID che ti interessa di più su dispositivo mobile deve essere compreso 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

A volte vengono scoperti bug nelle API utilizzate per misurare le metriche e talvolta nelle definizioni delle metriche stesse. Di conseguenza, a volte devono essere apportate delle modifiche che possono apparire come miglioramenti o regressioni nei report e nelle dashboard interni.

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

Se hai un feedback per queste metriche, puoi fornirlo nel gruppo Google web-vitals-feedback.