First Input Delay (FID)

Philip Walton

Sappiamo tutti quanto sia importante fare una buona prima impressione. È importante quando si conoscono nuove persone, ma 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 abbandona il sito e non torna più. La domanda è: che cosa rende un'impressione positiva e come si misura il tipo di impressione che probabilmente stai facendo sui tuoi utenti?

Sul web, le prime impressioni possono assumere molte forme diverse: abbiamo le prime impressioni sul design e sull'appeal visivo di un sito, nonché le prime impressioni sulla sua velocità e reattività.

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

La prima impressione che gli utenti hanno della velocità di caricamento del tuo sito può essere misurata con la metrica First Contentful Paint (FCP). Ma la velocità con cui il tuo sito può disegnare i pixel sullo schermo è solo una parte della storia. Altrettanto importante è la reattività del tuo sito quando gli utenti tentano di interagire con questi pixel.

La metrica First Input Delay (FID) consente di misurare la prima impressione degli utenti sull'interattività e sulla reattività del tuo sito.

Che cos'è FID?

FID misura il tempo trascorso tra la prima interazione di un utente con una pagina (ovvero quando fa clic su un link, tocca un pulsante o utilizza un controllo JavaScript personalizzato) e il 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 dovrebbero fare in modo che il First Input Delay sia pari o inferiore a 100 millisecondi. Per assicurarvi di raggiungere questo target per la maggior parte degli utenti, una buona soglia da misurare è il 75° percentile dei caricamenti delle pagine, segmentato tra dispositivi mobili e computer fissi.

FID in dettaglio

In qualità di sviluppatori che scrivono codice che risponde agli eventi, spesso diamo per scontato che il nostro codice verrà eseguito immediatamente, non appena si verifica l'evento. Tuttavia, in qualità di utenti, abbiamo spesso sperimentato il contrario: abbiamo caricato una pagina web sul nostro smartphone, abbiamo provato a interagire con essa e poi siamo rimasti frustrati quando non è successo nulla.

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

Considera la seguente sequenza temporale di un tipico caricamento pagina:

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

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

I ritardi lunghi della prima interazione si verificano in genere tra First Contentful Paint (FCP) e Time to Interactive (TTI) perché la pagina ha visualizzato alcuni dei suoi contenuti, ma non è ancora interattiva in modo affidabile. Per illustrare come può accadere, FCP e TTI sono stati aggiunti alla sequenza temporale:

Potresti aver notato che tra FCP e TTI trascorre un periodo di tempo piuttosto lungo (incluse tre attività lunghe). Se un utente tenta di interagire con la pagina durante questo periodo (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 è in grado di rispondere.

Considera cosa succederebbe se un utente provasse a interagire con la pagina all'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 questo utente in questa pagina.

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

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 FID viene misurato anche nei casi in cui non è stato registrato un listener di eventi. Il motivo è che molte interazioni utente non richiedono un listener 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 sul 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, 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 plasmare la nostra impressione complessiva della qualità e dell'affidabilità di un sito.
• I maggiori problemi di interattività che riscontriamo oggi sul web si verificano durante il caricamento della pagina. Pertanto, riteniamo che concentrarsi inizialmente sul miglioramento della prima interazione dell'utente con il sito avrà il maggiore impatto sul miglioramento dell'interattività complessiva del web.
• Le soluzioni consigliate per risolvere i problemi di ritardo del primo input elevato (suddivisione del codice, caricamento anticipato di meno JavaScript e così via) non sono necessariamente le stesse per risolvere i problemi di ritardo dell'input lento dopo il caricamento della pagina. Separando queste metriche, potremo fornire indicazioni più specifiche sul rendimento agli sviluppatori web.

Che cosa viene considerato come primo input?

FID è una metrica che misura la reattività di una pagina durante il caricamento. Pertanto, si concentra solo sugli eventi di input provenienti da azioni discrete 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 sono spesso in grado di nascondere la latenza eseguendole su un thread separato).

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

Cosa succede se un utente non interagisce mai con il tuo sito?

Non tutti gli utenti interagiscono con il tuo sito ogni volta che lo visitano. Inoltre, non tutte le interazioni sono pertinenti al FID (come indicato nella sezione precedente). Inoltre, alcune prime interazioni degli utenti avvengono in momenti sfavorevoli (quando il thread principale è occupato per un periodo di tempo prolungato), mentre altre avvengono in momenti favorevoli (quando il thread principale è completamente inattivo).

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

Il modo in cui monitori, generi report e analizzi FID sarà probabilmente molto diverso rispetto ad altre metriche che potresti essere abituato a utilizzare. La sezione successiva spiega come eseguire al meglio questa operazione.

Perché considerare solo il ritardo di input?

Come accennato in precedenza, 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 la 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 incentivare gli sviluppatori ad aggiungere soluzioni alternative che peggiorano l'esperienza, ovvero potrebbero racchiudere 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 di "ritardo" 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 sulle metriche personalizzate.

Come misurare l'FID

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

Strumenti per i campi

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

Misurare FID in JavaScript

Per misurare l'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 del ritardo della voce first-input viene misurato calcolando la differenza tra i timestamp startTime e processingStart della voce. Nella maggior parte dei casi, questo sarà il valore FID; tuttavia, non tutte le voci first-input sono valide per la misurazione del FID.

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

Differenze tra la metrica e l'API

• L'API invierà first-input voci per le pagine caricate in una scheda in background, ma queste pagine devono essere ignorate durante il calcolo del FID.
• L'API invierà anche voci first-input se la pagina è stata messa in background prima del primo input, ma queste pagine devono essere ignorate quando si calcola 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 il FID deve essere misurato in questi casi, poiché gli utenti le considerano visite di pagine distinte.
• L'API non segnala gli input che si verificano all'interno degli iframe, ma la metrica sì, in quanto fanno parte dell'esperienza utente della pagina. Ciò può essere visualizzato come una differenza tra CrUX e RUM. Per misurare correttamente l'FID, devi prenderli in considerazione. I subframe possono utilizzare l'API per segnalare le proprie voci first-input al frame principale per l'aggregazione.

Analisi e reporting sui dati FID

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

Sebbene la scelta del percentile per tutte le soglie di Core Web Vitals sia il 75°, per FID in particolare consigliamo vivamente di esaminare i percentili dal 95° al 99°, in quanto corrispondono alle prime esperienze particolarmente negative che gli utenti hanno con il tuo sito. e ti mostrerà le aree che richiedono il maggior miglioramento.

Ciò vale anche se segmenti i report in base alla categoria o al tipo di dispositivo. Ad esempio, se generi report separati per computer e dispositivi mobili, il valore FID che ti interessa di più sul computer dovrebbe essere il percentile 95-99 degli utenti di computer, mentre il valore FID che ti interessa di più sui dispositivi mobili dovrebbe essere il percentile 95-99 degli utenti di dispositivi mobili.

Come migliorare FID

È disponibile una guida completa all'ottimizzazione di FID che ti illustra le tecniche per migliorare questa metrica.

Log delle modifiche

Di tanto in tanto, vengono rilevati bug nelle API utilizzate per misurare le metriche e a volte nelle definizioni delle metriche stesse. Di conseguenza, a volte è necessario apportare modifiche, che possono essere visualizzate 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 changelog.

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