First Input Delay (FID)

Philip Walton

Supporto dei browser

• 76
• 79
• 89
• x

Origine

Avviso: il First Input Delay (FID) non è più una metrica Core Web Vital ed è stato sostituito dalla metrica Interaction to Next Paint (INP). Di conseguenza, il supporto per l'ID utente è terminato il 9 settembre 2024. Ora dovresti concentrarti sull'INP.

Sappiamo tutti quanto sia importante fare una buona prima impressione. È importante quando conosci nuove persone ed è importante anche quando crei 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: abbiamo le prime impressioni sul design e sull'aspetto visivo di un sito, nonché le prime impressioni sulla sua velocità e adattabilità.

Sebbene sia difficile misurare quanto piaccia agli utenti il design di un sito con le API web, la misurazione della velocità e della reattività non è un problema.

La prima impressione che gli utenti hanno della velocità di caricamento del tuo sito può essere misurata con il 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 FID (First Input Delay) consente di misurare la prima impressione degli utenti sull'interattività e sull'adattabilità del tuo sito.

Che cos'è l'ID cliente?

FID misura il tempo che intercorre tra la prima interazione di un utente con una pagina (ad es. 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 eventi in risposta a quell'interazione.

Che cos'è un buon punteggio FID?

Per offrire una buona esperienza utente, i siti dovrebbero fare in modo che il valore del ritardo del primo input sia pari o inferiore a 100 millisecondi. 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.

Nota: per scoprire di più sulla ricerca e sulla metodologia alla base di questo consiglio, consulta Definire le soglie delle metriche Core Web Vitals

FID in dettaglio

In qualità di sviluppatori che scrivono codice che risponde agli eventi, spesso assumiamo che il nostro codice verrà 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 di input (noto anche come latenza di input) si verifica perché il thread principale del browser è impegnato a svolgere qualcos'altro, quindi non può (ancora) rispondere all'utente. Un motivo comune per cui ciò potrebbe accadere è che il browser è impegnato a eseguire l'analisi e l'esecuzione di un file JavaScript di grandi dimensioni caricato dalla tua app. Durante questa operazione, non può eseguire alcun ascoltatore di eventi perché il codice JavaScript che sta caricando potrebbe chiedergli di fare qualcos'altro.

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'interfaccia utente dopo l'esecuzione dei gestori di eventi. Sebbene questo tempo influisca sull'esperienza utente, includerlo nell'FID incentiverebbe gli sviluppatori a rispondere agli eventi in modo asincrono, il che migliorerebbe la metrica, ma probabilmente peggiorerebbe l'esperienza. Per ulteriori dettagli, vedi Perché prendere in considerazione solo il ritardo di inserimento di seguito.

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.

I ritardi prima interazione lunghi si verificano in genere 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 può accadere, sono stati aggiunti alla sequenza temporale il tempo di caricamento della prima pagina (FCP) e il tempo di visualizzazione della prima pagina (TTI):

Potresti aver notato che esiste un tempo considerevole (incluse tre attività lunghe) tra FCP e TTI. Se un utente tenta di interagire con la pagina durante questo periodo di tempo (ad esempio facendo clic su un link), si verificherà 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 avviene 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.

Nota: in questo esempio l'utente ha interagito con la pagina all'inizio del periodo di maggiore attività del thread principale. Se l'utente avesse interagito con la pagina solo un istante prima (durante il periodo di inattività), il browser avrebbe potuto rispondere immediatamente. Questa varianza nel ritardo di inserimento sottolinea l'importanza di esaminare la distribuzione dei valori FID quando si generano report sulla metrica. Scopri di più nella sezione seguente sull'analisi e la generazione di report sui dati FID.

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

L'FID misura il delta tra il momento in cui viene ricevuto un evento di input e il successivo tempo di inattività del thread principale. 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 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?

Anche se un ritardo da qualsiasi input può 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 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 della pagina. Pertanto, riteniamo che inizialmente concentrarsi sul miglioramento della prima interazione dell'utente con il sito avrà l'impatto maggiore sul miglioramento dell'interattività complessiva 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, potremo fornire linee guida sul rendimento più specifiche agli sviluppatori web.

Che 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 sono spesso in grado di nascondere la latenza eseguendoli in 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.

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 altri probabilmente avranno 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é prendere in considerazione solo il ritardo di inserimento?

Come accennato in precedenza, l'ID cliente 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'interfaccia utente 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 voto della metrica, ma una risposta più lenta percepita dall'utente.

Tuttavia, mentre l'ID utente misura solo la parte di "ritardo" della latenza dell'evento, gli sviluppatori che vogliono monitorare una parte maggiore del ciclo di vita dell'evento possono farlo utilizzando l'API Event Timing. Per ulteriori dettagli, consulta la guida sulle 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 tua pagina. Puoi misurare il FID con i seguenti strumenti.

Nota: il FID richiede un utente reale e pertanto non può essere misurato in laboratorio. Tuttavia, la metrica Total Blocking Time (TBT) è misurabile in laboratorio, ha una buona correlazione con il FID sul campo e rileva anche i problemi che influiscono sull'interattività. Le ottimizzazioni che migliorano il TBT in laboratorio dovrebbero migliorare anche il FID per i tuoi utenti.

Strumenti sul campo

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

Misurare il FID in JavaScript

Per misurare il 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});

Avviso: questo codice mostra come registrare le voci first-input nella console e calcolare il relativo ritardo. Tuttavia, la misurazione dell'FID in JavaScript è più complicata. Per maggiori dettagli, consulta quanto riportato di seguito:

Nell'esempio precedente, il valore del ritardo della voce first-input viene misurato calcolando il delta tra i timestamp startTime e processingStart della voce. Nella maggior parte dei casi si tratta del valore FID. Tuttavia, non tutte le vocifirst-input sono valide per la misurazione del FID.

La sezione seguente 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à 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 voci first-input se la pagina è stata messa in background prima dell'inserimento del primo input, ma anche queste pagine devono essere ignorate durante il calcolo del FID (gli input vengono presi in considerazione solo se la pagina è stata in foreground 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. Ciò può mostrarsi come una differenza tra CrUX e RUM. Per misurare correttamente l'ID utente, devi tenerli in considerazione. I frame secondari possono utilizzare l'API per segnalare le proprie voci first-input al frame principale per l'aggregazione.

Nota: in alcuni casi (ad esempio con gli iframe cross-origin) non è possibile misurare il FID in JavaScript.

Analisi e generazione di report sui dati 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 percentile più elevati.

Sebbene la scelta del percentile per tutte le soglie di Core Web Vitals sia il 75°, per il FID in particolare consigliamo vivamente di esaminare i percentile tra il 95° e il 99°, in quanto corrispondono alle prime esperienze particolarmente negative degli utenti sul tuo sito. Inoltre, ti mostrerà le aree che richiedono il maggiore miglioramento.

Questo vale 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 maggiormente su computer deve essere compreso tra il 95° e il 99° percentile degli utenti di computer e il valore FID che ti interessa maggiormente 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 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 nelle dashboard e nei report 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 feedback su queste metriche, puoi fornirli nel gruppo Google web-vitals-feedback.