Verso una migliore metrica relativa alla reattività

Scopri le nostre opinioni sulla misurazione della reattività e inviaci il tuo feedback.

Nel team per le metriche di velocità di Chrome, stiamo lavorando per approfondire la nostra comprensione della velocità le pagine rispondono all'input dell'utente. Vorremmo condividere alcune idee per migliorare le metriche di reattività e ascolta il tuo feedback.

Questo post tratterà due argomenti principali:

1. Esamina la nostra attuale metrica di reattività, First Input Delay (FID) e spiega perché lo abbiamo scelto piuttosto che con alcune alternative.
2. Presenta alcuni miglioramenti che abbiamo preso in considerazione per comprendere meglio l'intero processo la latenza dei singoli eventi. Questi miglioramenti mirano anche a catturare quadro olistico dell'adattabilità complessiva di una pagina nel corso del suo ciclo di vita.

Che cos'è il First Input Delay?

La metrica First Input Delay (FID) misura il tempo impiegato dal browser per iniziare Elaborazione della prima interazione dell'utente su una pagina. In particolare, misura la differenza il tempo in cui l'utente interagisce con il dispositivo e l'ora in cui il browser è effettivamente in grado di e iniziare a elaborare i gestori di eventi. Il valore FID viene misurato solo per tocchi e pressioni dei tasti, il che significa che prende in considerazione solo la prima occorrenza dei seguenti eventi:

• click
• keydown
• mousedown
• pointerdown (solo se è seguito da pointerup)

Il seguente diagramma illustra il valore FID:

La metrica FID non include il tempo trascorso nell'esecuzione dei gestori di eventi né qualsiasi lavoro svolto dal browser per aggiornare la schermata. Misura per quanto tempo il thread principale è stato occupato prima e avere la possibilità di gestire un input. Questo tempo di blocco è causato di solito da lunghe attività JavaScript, poiché non possono essere interrotte in qualsiasi momento, quindi l'attività corrente deve essere completata prima che il browser possa inizia a elaborare l'input.

Perché abbiamo scelto la normativa FID?

Riteniamo che sia importante misurare l'esperienza utente effettiva per garantire che i miglioramenti la metrica offre vantaggi concreti per l'utente. Abbiamo scelto di misurare il FID perché rappresenta il parte dell'esperienza utente quando l'utente decide di interagire con un sito che è stato appena caricato. La metrica FID registra parte del tempo che l'utente deve attendere per ricevere una risposta dalla sua interazione con un sito. In altre parole, il valore FID è un limite inferiore relativo alla quantità di tempo di attesa di un utente dopo l'interazione.

Altre metriche come Total Block Time (TBT) e Time To Interactive (TTI) si basano su attività lunghe e, come per la FID, anche misurare il tempo di blocco dei thread principali durante il caricamento. Poiché queste metriche possono essere misurate sia sul campo e nel lab, molti sviluppatori ci hanno chiesto perché non preferiamo uno di questi metodi rispetto a FID.

Ciò per diversi motivi. Forse il motivo più importante è che queste metriche non di misurare direttamente l'esperienza utente. Tutte queste metriche misurano quanto JavaScript viene eseguito . Sebbene JavaScript a lunga esecuzione tende a causare problemi ai siti, queste attività influiscono necessariamente sull'esperienza utente se l'utente non interagisce con la pagina quando si verifica. Una pagina può avere un ottimo punteggio per TBT e TTI, ma essere lenta o avere un punteggio scarso se si sente rapidamente per gli utenti. In base alla nostra esperienza, queste misurazioni indirette si traducono in metriche particolarmente utili per per alcuni siti, ma non per la maggior parte dei siti. In breve, il fatto che le attività lunghe e il TTI non siano incentrati sugli utenti rende questi candidati più deboli.

Sebbene la misurazione di laboratorio sia sicuramente importante e inestimabile strumento di diagnostica, ciò che conta davvero è l'esperienza utente sui siti. Avendo un metrica incentrata sugli utenti che riflette le condizioni degli utenti reali, avrai la garanzia di acquisire qualcosa significativo nell'esperienza. Abbiamo deciso di iniziare con una piccola parte di quell'esperienza, anche se sappiamo che questa parte non è rappresentativa dell'esperienza completa. Per questo stiamo lavorando sull'acquisizione di una porzione più ampia del tempo in cui un utente attende che i suoi input vengano gestiti.

Quali miglioramenti stiamo prendendo in considerazione?

Vorremmo sviluppare una nuova metrica che estende le misure FID oggi, pur conservando le sue una connessione forte all'esperienza utente.

Vogliamo che la nuova metrica:

1. Considera la reattività di tutti gli input dell'utente (non solo del primo).
2. Acquisisci l'intera durata di ogni evento, non solo il ritardo.
3. Raggruppa gli eventi che si verificano come parte della stessa interazione logica dell'utente e definisci che la latenza dell'interazione come durata massima di tutti gli eventi.
4. Crea un punteggio aggregato per tutte le interazioni che si verificano su una pagina, per tutta la durata durante il ciclo di vita di attività.

Per avere successo, dovremmo essere in grado di affermare con sicurezza che se un sito ottiene un punteggio scarso nuova metrica, non risponde rapidamente alle interazioni degli utenti.

Acquisisci l'intera durata dell'evento

Il primo evidente miglioramento consiste nel cercare di acquisire una latenza end-to-end più ampia di un evento. Come sopra menzionato, il valore FID acquisisce solo la parte del ritardo dell'evento di input. Non tiene conto il tempo impiegato dal browser per elaborare effettivamente i gestori di eventi.

Il ciclo di vita di un evento è costituito da varie fasi, come illustrato in questo diagramma:

Di seguito sono riportati i passaggi seguiti da Chrome per elaborare un input:

1. L'input proviene dall'utente. L'ora in cui si verifica è l'timeStamp dell'evento.
2. Il browser esegue hit test per decidere quale frame HTML (frame principale o iframe) costituisce un evento. a cui appartiene. Quindi il browser invia l'evento al processo del renderer appropriato che si occupa di il frame HTML.
3. Il renderer riceve l'evento e lo accoda in modo che possa essere elaborato quando diventa disponibile farlo.
4. Il renderer elabora l'evento eseguendo i relativi gestori. Questi gestori possono aggiungere lavoro asincrono, come setTimeout e i recuperi, che fanno parte della gestione dell'input. Ma al questo punto, il lavoro sincrono è completato.
5. Sullo schermo viene dipinto un frame che riflette il risultato dell'esecuzione dei gestori di eventi. Tieni presente che eventuali attività asincrone in coda dai gestori di eventi potrebbero non essere ancora completate.

Il tempo che intercorre tra i passaggi (1) e (3) sopra riportato è il ritardo di un evento, ovvero quanto misura il FID.

Il tempo che intercorre tra i passaggi (1) e (5) sopra indicato è la durata di un evento. Ecco cosa la nuova metrica misurare.

La durata dell'evento include il ritardo, ma include anche il lavoro che si verifica nei gestori di eventi e il lavoro che il browser deve eseguire per visualizzare il frame successivo dopo l'esecuzione dei gestori. La di un evento è attualmente disponibile nell'API Event Timing tramite durata della voce .

Raggruppare gli eventi in interazioni

Estendere la misurazione della metrica da delay a duration è un buon primo passo, ma è comunque lascia una lacuna critica nella metrica: si concentra sui singoli eventi e non sull'esperienza utente di a interagire con la pagina.

Molti eventi diversi possono attivarsi in seguito a una singola interazione dell'utente e una misurazione separata ognuna delle quali non crea un'immagine chiara dell'esperienza utente. Vogliamo assicurarci che la nostra metrica acquisisce tutto il tempo a disposizione dell'utente per attendere una risposta quando tocca, preme i tasti scorrere e trascinare nel modo più preciso possibile. Stiamo quindi introducendo il concetto interazioni per misurare la latenza di ognuna.

Tipo di interazione

La tabella seguente elenca le quattro interazioni da definire insieme agli eventi DOM che a cui sono associati. Tieni presente che non è esattamente come l'insieme di tutti gli eventi che vengono viene inviato quando si verifica questa interazione dell'utente. Ad esempio, quando un utente scorre, viene generato un evento di scorrimento ma quando la schermata è stata aggiornata per riflettere lo scorrimento, la consideriamo parte della latenza dell'interazione.

Le prime tre interazioni elencate sopra (tastiera, tocco e trascinamento) sono attualmente coperte dalla metrica FID. Per la nostra nuova metrica relativa alla reattività, vogliamo includere anche lo scorrimento, dato che estremamente comune sul web ed è un aspetto fondamentale del livello di reattività di una pagina nei confronti degli utenti.

Tastiera

Un'interazione con la tastiera è composta da due parti: quando l'utente preme il tasto e quando lo rilascia. A questa interazione utente sono associati tre eventi: keydown, keyup e keypress. Il seguente diagramma illustra i ritardi e le durate di keydown e keyup per una tastiera interazione:

Nel diagramma in alto, le durate sono separate perché il frame degli aggiornamenti di keydown è presentati prima dell'evento keyup, ma non è sempre così. Inoltre, tieni presente per mostrare che un frame può essere presentato nel mezzo di un'attività nel processo del renderer a partire dagli ultimi passaggi. necessari per produrre il frame vengono eseguiti al di fuori del processo di rendering.

keydown e keypress si verificano quando l'utente preme il tasto, mentre keyup si verifica quando l'utente rilascia la chiave. In genere l'aggiornamento dei contenuti principali si verifica quando viene premuto il tasto: text appare sullo schermo o viene applicato l'effetto del modificatore. Detto questo, vogliamo acquisire più rari casi in cui keyup presenterebbe anche aggiornamenti interessanti dell'interfaccia utente, quindi vogliamo esaminare il tempo complessivo impiegato.

Per acquisire il tempo complessivo impiegato dall'interazione con la tastiera, possiamo calcolare il tempo massimo della durata degli eventi keydown e keyup.

Tocca

Un'altra interazione importante dell'utente si verifica quando l'utente tocca o fa clic su un sito web. Simile a keypress, alcuni eventi vengono attivati quando l'utente tiene premuto, mentre altri quando vengono rilasciati, come mostrato in nel diagramma in alto. Tieni presente che gli eventi associati a un tocco sono leggermente diversi su computer e computer mobile.

Per un tocco o un clic, l'uscita è in genere quella che attiva la maggior parte delle reazioni, ma come avviene per le interazioni da tastiera, vogliamo acquisire l'interazione completa. E in questo caso è più probabile è importante farlo perché avere aggiornamenti dell'interfaccia utente alla pressione del tocco non è così raro.

Vorremmo includere la durata degli eventi per tutti questi eventi, ma molti si sovrappongono dobbiamo misurare solo pointerdown, pointerup e click per coprire l'intero un'interazione.

Resistenza aerodinamica

Abbiamo deciso di includere anche il trascinamento poiché è associato a eventi simili e dato che in genere causa aggiornamenti importanti dell'interfaccia utente dei siti. Per la nostra metrica, tuttavia, intendiamo considerare solo l'inizio del trascinamento e la parte finale del trascinamento, ovvero le parti iniziale e finale della trascinamento. In questo modo è più facile ragionare e rendere le latenze comparabili con le altre interazioni prese in considerazione. Questo è in linea con la nostra decisione di escludere eventi continui come mouseover.

Inoltre, non stiamo prendendo in considerazione l'implementazione di drag and drop tramite la funzionalità dell'API perché funzionano solo su computer.

Scorrimento

Una delle forme più comuni di interazione con un sito è lo scorrimento. Per la nuova metrica, come misurare la latenza dell'interazione iniziale con lo scorrimento dell'utente. In particolare, interessarsi alla reazione iniziale del browser al fatto che l'utente ha richiesto uno scorrimento. Lo faremo non coprono l'intera esperienza di scorrimento. Ciò significa che lo scorrimento produce molti fotogrammi e ci concentreremo la nostra attenzione sul frame iniziale prodotto come reazione alla pergamena.

Perché solo il primo? Per prima cosa, i frame successivi possono essere acquisiti da un livello di fluidità separato proposta. Ciò significa che una volta che all'utente viene mostrato il primo risultato dello scorrimento, il resto deve essere misurato in termini di fluidità dell'esperienza di scorrimento. Pertanto, riteniamo che lo sforzo per ottenere risultati senza problemi per catturare meglio questo aspetto. Come per FID, scegliamo di adottare esperienze utente discrete: esperienze a cui sono associati punti temporali chiari e per i quali possiamo facilmente calcolare e la latenza. Lo scorrimento nel suo insieme è un'esperienza continua, quindi non intendiamo misurare tutti in questa metrica.

Dunque, perché misurare gli scorrimenti? Le prestazioni dello scorrimento che abbiamo raccolto in Chrome mostrano che lo scorrimento in genere è molto veloce. Detto questo, vogliamo comunque includere le latenze di scorrimento iniziali nella nuova metrica. per vari motivi. Innanzitutto, lo scorrimento è veloce solo perché è stato ottimizzato così tanto, è così importante. Ma esistono ancora modi per fare in modo che un sito web aggiri alcuni dei miglioramenti di rendimento che offerte dal browser. La più comune in Chrome è forzare lo scorrimento sulla pagina principale . La nostra metrica dovrebbe quindi essere in grado di indicare quando questo accade e causa prestazioni di scorrimento scarse. per gli utenti. Secondo, è troppo importante per ignorare lo scorrimento. Temiamo che se escludiamo lo scorrimento allora avremo un grande punto cieco e le prestazioni dello scorrimento potrebbero diminuire nel tempo senza il web. se gli sviluppatori lo notano correttamente.

Quando un utente scorre, vengono inviati diversi eventi, ad esempio touchstart, touchmove, e scroll. Ad eccezione dell'evento di scorrimento, questo dipende in gran parte dal dispositivo utilizzato scorrimento: gli eventi tocco vengono inviati quando si scorre con il dito sui dispositivi mobili, mentre la rotellina si verificano quando si scorre con la rotellina del mouse. Gli eventi di scorrimento vengono attivati dopo lo scorrimento iniziale viene completata. In generale, nessun evento DOM blocca lo scorrimento, a meno che il sito web non utilizzi metodi non passivi listener di eventi. Pensiamo quindi allo scorrimento come disaccoppiato dal DOM tutti gli eventi. Quello che vogliamo misurare è il tempo che intercorre tra il momento in cui l'utente si muove abbastanza da produrre un gesto di scorrimento fino al primo frame che mostra lo scorrimento.

Come si definisce la latenza di un'interazione?

Come abbiamo visto in precedenza, le interazioni con un e "su" dei componenti devono essere considerati separatamente per evitare di attribuire il tempo che l'utente ha trascorso tenendo premuto il dito.

Per questi tipi di interazioni, vorremmo che la latenza coinvolga la durata di tutti gli eventi. associate. Poiché le durate degli eventi per ogni "down" e "su" parte dell'interazione può di risposta, la definizione più semplice di latenza di interazione che raggiunge questo obiettivo è la durata massima di qualsiasi evento associato. Facendo riferimento al diagramma della tastiera di cui abbiamo parlato in precedenza, per la durata di keydown, perché è superiore alla durata di keyup:

Anche le durate keydown e keyup potrebbero sovrapporsi. Ciò può accadere, ad esempio, quando il frame presentati per entrambi gli eventi è lo stesso, come nel seguente diagramma:

Questo approccio offre pro e contro dell'uso del massimo e ci interessa ascoltare il tuo feedback:

• Pro: è in linea con il modo in cui intendiamo misurare lo scorrimento, in quanto misura solo una singola valore della durata.
• Pro: ha lo scopo di ridurre il rumore in casi come le interazioni con la tastiera, in cui keyup solitamente non fa nulla e l'utente può premere e rilasciare il tasto rapidamente o lentamente.
• Con: non consente di acquisire tutto il tempo di attesa dell'utente. Ad esempio, acquisirà l'inizio o la fine di un trascinamento, ma non entrambi.

Per lo scorrimento (a cui è associato un solo evento) vorremmo definire la latenza come tempo il browser produca il primo frame dopo lo scorrimento. cioè la latenza è il delta tra l'evento timeStamp del primo evento DOM (ad esempio touchmove, se utilizzi un dito) che sia abbastanza grande da attivare lo scorrimento e il primo colore che riflette lo scorrimento. che ha luogo.

Aggrega tutte le interazioni per pagina

Dopo aver definito la latenza di un'interazione, occorre calcolare un valore aggregato per un caricamento pagina, il che potrebbe comportare molte interazioni degli utenti. I valori aggregati ci consentono di:

• Creare correlazioni con le metriche aziendali.
• Valutare le correlazioni con altre metriche delle prestazioni. Idealmente, la nuova metrica sarà sufficientemente indipendentemente dal fatto che aggiunga valore alle metriche esistenti.
• Esponi facilmente i valori negli strumenti in modi facilmente comprensibili.

Per eseguire questa aggregazione, dobbiamo rispondere a due domande:

1. Quali numeri cerchiamo di aggregare?
2. Come li aggreghiamo?

Stiamo esaminando e valutando diverse opzioni. Siamo lieti di sapere cosa ne pensi di questa aggregazione.

Un'opzione è definire un budget per la latenza di un'interazione, che può dipendere dal tipo (scorrimento, tastiera, tocco o trascinamento). Ad esempio, se il budget per i tocchi è di 100 ms e la latenza di un tocco è di 150 ms, l'importo oltre il budget per quell'interazione sarebbe 50 ms. Poi potremmo calcolare la latenza massima che supera il budget per qualsiasi interazione dell'utente nella pagina.

Un'altra opzione è calcolare la latenza media o mediana delle interazioni nell'arco della vita della pagina. Pertanto, se la latenza fosse di 80 ms, 90 ms e 100 ms, la media per la pagina è di 90 ms. Potremmo anche considerare l'importo medio o mediano "al di sopra del budget" per tenere conto di aspettative diverse a seconda del tipo di interazione.

Come si presenta tutto questo nelle API per le prestazioni web?

Cosa manca nella sezione Tempi eventi?

Purtroppo non tutte le idee presentate in questo post possono essere acquisite utilizzando la funzionalità Tempi eventi tramite Google Cloud CLI o tramite l'API Compute Engine. In particolare, non esiste un modo semplice per conoscere gli eventi associati a un determinato utente interazione con l'API. A questo scopo, abbiamo proposto l'aggiunta di interactionID alla API.

Un altro difetto dell'API Event Timing è che non c'è modo di misurare lo scorrimento interazione, pertanto stiamo lavorando per abilitare queste misure (tramite Event Timing o un'API separata).

Cosa puoi provare subito?

Al momento è ancora possibile calcolare la latenza massima per tocchi/trascinamenti e per tastiera e interazioni. Il seguente snippet di codice produrrà queste due metriche.

let maxTapOrDragDuration = 0;
let maxKeyboardDuration = 0;
const observer = new PerformanceObserver(list => {
  list.getEntries().forEach(entry => {
    switch(entry.name) {
      case "keydown":
      case "keyup":
        maxKeyboardDuration = Math.max(maxKeyboardDuration,
            entry.duration);
        break;
      case "pointerdown":
      case "pointerup":
      case "click":
        maxTapOrDragDuration = Math.max(maxTapOrDragDuration,
            entry.duration);
        break;
    }
  });
});
observer.observe({type: "event", durationThreshold: 16, buffered: true});
// We can report maxTapDragDuration and maxKeyboardDuration when sending
// metrics to analytics.

Feedback

Facci sapere cosa pensi di queste idee inviando un'email a: web-vitals-feedback@googlegroups.com.