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 gli utenti fedeli o che se ne vanno e non tornano più. La domanda è: che cosa determina una buona impressione e come si misura il tipo di impressione che stai ottenendo sui tuoi utenti?

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

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

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

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

Che cos'è la FID?

La metrica FID misura il tempo trascorso dalla prima interazione di un utente con una pagina (ossia, 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.

Che cos'è un buon punteggio FID?

Per offrire una buona esperienza utente, i siti devono fare in modo che il primo input sia inserito Ritardo di 100 millisecondi. Per assicurarti di raggiungere questo target per utenti, una buona soglia da misurare è il 75° percentile di caricamenti di pagine, segmentati tra dispositivi mobili e computer.

FID in dettaglio

In qualità di sviluppatori che scrivono codice in grado di rispondere agli eventi, spesso presupponiamo che il nostro codice verrà eseguito immediatamente, non appena si verifica l'evento. Ma in quanto utenti, abbiamo tutti sperimentato spesso il contrario: abbiamo caricato una pagina web il nostro smartphone, ha provato a interagire con il telefono e avevo provato frustrazione quando niente è successo.

In generale, il ritardo dell'input (ovvero la latenza di input) si verifica perché la il thread principale è impegnato in altre attività, quindi non può (ancora) rispondere all'utente. Un motivo comune di questo problema è che il browser è impegnato nell'analisi e nell'esecuzione a un file JavaScript di grandi dimensioni caricato dalla tua app. Mentre esegue questa operazione, non può eseguire alcun listener di eventi, perché il codice JavaScript che sta caricando potrebbe indicargli di eseguire altro.

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

La visualizzazione sopra mostra una pagina che sta effettuando un paio di richieste di rete per le risorse (molto probabilmente file CSS e JS) e, dopo queste risorse hanno terminato il download; vengono elaborati sul thread principale.

Ciò si verifica in periodi in cui il thread principale è temporaneamente occupato, indicato dal colore beige attività isolati.

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

Avrai notato che c'è una discreta quantità di tempo (inclusi tre lunghi attività) tra FCP e TTI, se un utente cerca di interagiscono con la pagina durante quel periodo (ad esempio facendo clic su un link), verrà visualizzata una ritardo tra la ricezione del clic e il momento in cui il thread principale riesce e rispondere.

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

Poiché l'input avviene mentre il browser sta eseguendo un'attività, ma deve attendere il completamento dell'attività prima di poter rispondere all'input. La "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 viene il thread è inattivo. Ciò significa che il valore FID viene misurato anche nei casi in cui un evento listener non è stato registrato. Il motivo è che molte interazioni degli utenti non richiedono un listener di eventi ma do richiedono che il thread principale sia inattivo per l'esecuzione.

Ad esempio, tutti i seguenti elementi HTML devono attendere attività in corso nel thread principale da completare prima di rispondere all'utente interazioni:

• 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?

Anche se un ritardo in un input può determinare un'esperienza utente negativa, consiglia di misurare il primo ritardo di input per alcuni motivi:

• Il primo ritardo nell'inserimento sarà la prima impressione dell'utente del la reattività e le prime impressioni sono fondamentali per dare forma al nostro un'impressione della qualità e dell'affidabilità di un sito.
• I principali problemi di interattività che vediamo oggi sul Web si verificano durante la caricamento. Pertanto, riteniamo che inizialmente il nostro obiettivo è migliorare il primo utente del sito l'interazione avrà un grande impatto sul miglioramento del rendimento globale e interattività con il web.
• Le soluzioni consigliate su come i siti devono correggere i ritardi elevati nella prima interazione (la suddivisione del codice, il caricamento iniziale di meno codice JavaScript e così via) non sono necessariamente le stesse soluzioni per correggere i ritardi di input lenti dopo il caricamento pagina. Separando queste metriche saremo in grado di fornire prestazioni più specifiche le linee guida per gli sviluppatori web.

Cosa viene considerato come primo input?

La metrica FID è una metrica che misura l'adattabilità di una pagina durante il caricamento. Di conseguenza, si concentra solo sugli eventi di input da azioni discrete come clic, tocchi e di pressione.

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

In altre parole, la metrica FID si concentra sulla R (reattività) nel RAIL. rendimento predefinito, mentre lo scorrimento e lo zoom sono più correlati alla funzione A (animazione) e alle sue prestazioni di qualità devono essere valutate separatamente.

Che 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. E non tutti le interazioni sono pertinenti per il FID (come indicato nella sezione precedente). Nella Inoltre, le prime interazioni di alcuni utenti avvengono in momenti difficili (quando la thread è occupato per un periodo di tempo prolungato) e il primo le interazioni avvengono in momenti opportuni (quando il thread principale è completamente inattivo).

Ciò significa che alcuni utenti non avranno valori FID, mentre altri avranno un valore FID basso. e alcuni utenti avranno probabilmente valori FID elevati.

Le modalità di monitoraggio, generazione di report e analisi dei dati FID saranno probabilmente molto diverse da altre metriche a cui sei abituato. La prossima sezione spiega come fare al meglio questo.

Perché considerare solo il ritardo dell'input?

Come accennato in precedenza, il FID misura solo il "ritardo" nell'elaborazione degli eventi. Non non misurano la durata totale dell'elaborazione degli eventi né il tempo necessario al browser per aggiornare la UI dopo aver eseguito i gestori di eventi.

Anche se questo periodo è importante per l'utente e influisce sull'esperienza, non è incluso in questa metrica perché così facendo potrebbe incentivare gli sviluppatori aggiungere soluzioni alternative che peggiorano l'esperienza, cioè può racchiudere la logica del gestore di eventi in un callback asincrono (tramite setTimeout() o requestAnimationFrame()) in modo da separarlo dalla associata all'evento. Il risultato sarebbe un miglioramento della metrica ma una risposta più lenta percepita dall'utente.

Tuttavia, mentre il FID misura solo il "ritardo" parte della latenza degli eventi, gli sviluppatori che desiderano monitorare maggiormente il ciclo di vita degli eventi possono farlo utilizzando la metrica Tempi eventi tramite Google Cloud. Consulta la guida sulle Metriche per ulteriori dettagli.

Come misurare il FID

La metrica FID è una metrica che può essere misurata solo nel campo, in quanto richiede un a interagire con la tua pagina. Puoi misurare il valore FID con i seguenti strumenti.

Strumenti sul campo

• Esperienza utente di Chrome Segnala
• PageSpeed Insights
• Search Console (Core Web Vitals report)
• Libreria JavaScript di web-vitals

Misurare il FID in JavaScript

Per misurare la metrica FID in JavaScript, puoi utilizzare la metrica Tempi eventi tramite Google Cloud. L'esempio seguente mostra come crea un PerformanceObserver che ascolta 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 startTime e processingStart della voce i timestamp. Nella maggior parte dei casi si tratta del valore FID; ma non tutte first-input voci sono valide per la misurazione del FID.

La sezione seguente 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à first-input voci per le pagine caricate in una scheda in background, ma queste pagine dovrebbero essere ignorate per il calcolo del valore FID.
• L'API invierà anche first-input voci se la pagina è stata riprodotta in background prima che avvenga il primo input, ma anche queste pagine dovrebbero essere ignorate durante il calcolo del FID (gli input vengono presi in considerazione solo se la pagina si trovava rimane in primo piano per l'intera durata).
• L'API non segnala le voci first-input quando la pagina viene ripristinata da la cache back/forward, ma il valore FID dovrebbe essere misurati in questi casi, poiché gli utenti le visualizzano come pagine distinte visite.
• L'API non segnala gli input che si verificano all'interno di iframe, ma la metrica poiché fanno parte dell'esperienza utente sulla pagina. Questo può viene visualizzato come 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 relative voci first-input al frame principale per l'aggregazione.

Anziché memorizzare tutte queste sottili differenze, gli sviluppatori possono usare web-vitals libreria JavaScript per misura il valore FID, che gestisce queste differenze per te (laddove possibile, tieni presente che il problema dell'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 per onFID() per un esempio completo di come misurare il FID in JavaScript.

Analisi e reporting sui dati FID

A causa della varianza prevista nei valori FID, è fondamentale che, quando si esegue un report La metrica FID esamina la distribuzione dei valori e ti concentri sui percentili più elevati.

Mentre la scelta di percentile per tutte Le soglie di Core Web Vitals sono il 75° posto, per FID in particolare consigliamo di osservare i percentili 95-99, poiché corrispondono le prime esperienze particolarmente negative degli utenti sul tuo sito. E lo sarà a indicare le aree da migliorare.

anche se segmenti i report in base alla categoria o al tipo di dispositivo. Per Ad esempio, se esegui report separati per computer e dispositivi mobili, il valore FID che più interessati su desktop dovrebbero essere il 95°-99° percentile di utenti desktop, e il valore FID che ti interessa di più sui dispositivi mobili deve essere il 95°-99° percentile di utenti di dispositivi mobili.

Come migliorare la metrica FID

È disponibile una guida completa all'ottimizzazione della metrica FID che illustra alcune 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 questa situazione, tutte le modifiche all'implementazione o alla definizione di queste metriche verranno riportate in questo Log delle modifiche.

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