Sperimentazione con la misurazione delle navigazioni soft

Barry Pollard
Yoav Weiss
Yoav Weiss
X GitHub

Sin dal suo lancio, l'iniziativa Core Web Vitals ha cercato di misurare l'esperienza utente effettiva di un sito web, anziché fornire dettagli tecnici alla base di come questo viene creato o caricato. Le tre metriche di Core Web Vitals sono state create come metriche incentrate sugli utenti, un'evoluzione rispetto alle metriche tecniche esistenti, comeDOMContentLoaded o load, in cui vengono misurati tempi spesso non correlati alla percezione del rendimento della pagina da parte degli utenti. Per questo motivo, la tecnologia utilizzata per realizzare il sito non dovrebbe influire sul punteggio se il sito ha un buon rendimento.

La realtà è sempre un po' più complessa dell'ideale e la popolare architettura delle applicazioni a pagina singola non è mai stata completamente supportata dalle metriche Core Web Vitals. Anziché caricare singole pagine web distinte mentre l'utente naviga all'interno di un sito, queste applicazioni web utilizzano le cosiddette "navigazioni leggere", in cui i contenuti della pagina vengono modificati da JavaScript. In queste applicazioni, l'illusione di un'architettura convenzionale di pagine web viene mantenuta modificando l'URL e inserendo gli URL precedenti nella cronologia del browser per consentire ai pulsanti Avanti e Indietro di funzionare come previsto dall'utente.

Questo modello viene utilizzato da molti framework JavaScript, ma ognuno in modo diverso. Poiché questo non rientra in ciò che il browser interpreta tradizionalmente come una "pagina", la misurazione è sempre stata difficile: qual è la linea da tracciare tra un'interazione sulla pagina corrente e la sua valutazione come pagina nuova?

Il team di Chrome sta prendendo in considerazione questa sfida ormai da un po' di tempo e sta cercando di standardizzare una definizione di cos'è una "navigazione semplice" e il modo in cui è possibile misurare i Core Web Vitals, in modo simile a come vengono misurati i siti web implementati nell'architettura multi-page convenzionale (MPA). Mentre è ancora nelle fasi iniziali, il team è pronto a rendere disponibile su larga scala ciò che è già stato implementato per consentire ai siti di sperimentare. In questo modo, i siti potranno fornire feedback sull'approccio adottato finora.

Che cos'è una navigazione soft?

Abbiamo elaborato la seguente definizione di navigazione soft:

  • La navigazione viene avviata da un'azione dell'utente.
  • La navigazione comporta una modifica visibile all'URL per l'utente e una modifica della cronologia.
  • La navigazione determina una modifica del DOM.

Per alcuni siti, queste euristiche possono generare falsi positivi (per cui gli utenti non considererebbero davvero avvenuta una "navigazione") o falsi negativi (in cui l'utente considera avvenuta una "navigazione" nonostante non soddisfi questi criteri). Siamo felici di ricevere feedback sull'euristica nel repository delle specifiche di navigazione soft.

In che modo Chrome implementa le navigazioni leggere?

Una volta attivata l'euristica di navigazione soft (ulteriori informazioni nella sezione successiva), Chrome modificherà la modalità di segnalazione di alcune metriche sul rendimento:

Queste modifiche consentiranno di misurare i Core Web Vitals (e alcune delle metriche diagnostiche associate) in base alla navigazione nelle pagine, anche se è necessario tenere conto di alcune sfumature.

Quali sono le implicazioni dell'attivazione delle navigazioni software in Chrome?

Di seguito sono riportate alcune delle modifiche che i proprietari dei siti devono prendere in considerazione dopo aver abilitato questa funzionalità:

  • Ulteriori eventi FP, FCP e LCP possono essere emessi per le navigazioni non semplici. Questi valori aggiuntivi verranno ignorati dal Report sull'esperienza utente di Chrome (CrUX), ma ciò potrebbe influire sul monitoraggio della misurazione degli utenti reali (RUM) sul tuo sito. Consulta il tuo provider di RUM se hai dubbi sull'impatto su queste misurazioni. Consulta la sezione sulla misurazione di Core Web Vitals per navigazione non fluida.
  • È possibile che il nuovo (e facoltativo) attributo navigationID nelle voci relative alle prestazioni debba essere considerato nel codice dell'applicazione utilizzando queste voci.
  • Solo i browser basati su Chromium supporteranno questa nuova modalità. Molte delle metriche più recenti sono disponibili solo nei browser basati su Chromium, mentre alcune (FCP, LCP) sono disponibili in altri browser e non tutti potrebbero aver eseguito l'upgrade all'ultima versione dei browser basati su Chromium. Pertanto, tieni presente che alcuni utenti potrebbero non segnalare le metriche di navigazione temporanea.
  • Trattandosi di una nuova funzionalità sperimentale che non è attiva per impostazione predefinita, i siti dovrebbero testarla per assicurarsi che non ci siano altri effetti collaterali indesiderati.

Per ulteriori informazioni su come misurare le metriche per le navigazioni soft, consulta la sezione Misurazione di Core Web Vitals per navigazione non attiva.

Come faccio ad attivare le navigazioni leggere in Chrome?

Le navigazioni leggere non sono attivate per impostazione predefinita in Chrome, ma sono disponibili per la sperimentazione abilitando esplicitamente questa funzionalità.

Per gli sviluppatori, questa funzionalità può essere attivata attivando il flag Funzionalità sperimentali della piattaforma web all'indirizzo chrome://flags/#enable-experimental-web-platform-features o utilizzando l'argomento della riga di comando --enable-experimental-web-platform-features all'avvio di Chrome.

Come posso misurare le navigazioni leggere?

Una volta abilitato l'esperimento sulle navigazioni leggere, le metriche verranno registrate utilizzando l'API PerformanceObserver come di consueto. Tuttavia, ci sono alcune considerazioni aggiuntive che devono essere prese in considerazione per queste metriche.

Segnala navigazioni secondarie

Puoi utilizzare un PerformanceObserver per osservare le navigazioni leggere. Di seguito è riportato un esempio di snippet di codice che registra le voci di navigazione soft nella console, incluse le navigazioni soft precedenti su questa pagina utilizzando l'opzione buffered:

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

Questa opzione può essere utilizzata per finalizzare le metriche delle pagine relative all'intera pagina per la navigazione precedente.

Segnala le metriche in base all'URL appropriato

Poiché le navigazioni non possono essere visualizzate solo dopo che si sono verificate, alcune metriche dovranno essere finalizzate in base a questo evento e poi registrate per l'URL precedente, poiché l'URL corrente ora rifletterà quello aggiornato per la nuova pagina.

L'attributo navigationId dell'elemento PerformanceEntry appropriato può essere utilizzato per collegare l'evento all'URL corretto. Per verificare questi dati, utilizza l'API PerformanceEntry:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

Questo pageUrl dovrebbe essere utilizzato per segnalare le metriche in base all'URL corretto, anziché all'URL corrente che potrebbero aver utilizzato in passato.

Recupero di startTime di navigazioni leggere

L'ora di inizio della navigazione può essere ottenuta in modo simile:

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (entry) => entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;

Il startTime indica l'ora dell'interazione iniziale (ad esempio un clic su un pulsante) che ha avviato la navigazione soft.

Tutti i tempi delle prestazioni, inclusi quelli per le navigazioni morbide, vengono indicati come un intervallo a partire dal valore "hard" iniziale tempo di navigazione nelle pagine. Di conseguenza, il tempo di avvio della navigazione soft è necessario per fare riferimento ai tempi della metrica di caricamento della navigazione soft (ad esempio LCP) rispetto a questo tempo di navigazione flessibile.

Misura Core Web Vitals per navigazione soft

Per includere le voci delle metriche di navigazione soft, devi includere includeSoftNavigationObservations: true nella chiamata observe dell'osservatore delle prestazioni.

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

È necessario il flag includeSoftNavigationObservations aggiuntivo per il metodo observe oltre ad attivare la funzionalità di navigazione soft in Chrome. Questa attivazione esplicita a livello di osservatore delle prestazioni ha lo scopo di garantire che gli osservatori esistenti non siano sorpresi da queste voci aggiuntive, in quanto è necessario prendere in considerazione alcune considerazioni aggiuntive quando si cerca di misurare Core Web Vitals per navigazioni non semplici.

I tempi verranno comunque restituiti per quanto riguarda l'elemento "hard" originale all'ora di inizio della navigazione. Di conseguenza, per calcolare l'LCP per una navigazione non lineare, ad esempio, dovrai prendere i tempi LCP e sottrarre l'ora di inizio della navigazione soft appropriata come dettagliata in precedenza per ottenere un tempo relativo alla navigazione soft. Ad esempio, per LCP:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

Alcune metriche vengono tradizionalmente misurate per tutta la durata della pagina: il valore LCP, ad esempio, può cambiare finché non si verifica un'interazione. I valori CLS e INP possono essere aggiornati finché la pagina non viene chiusa. Pertanto, ogni "navigazione" (compresa la navigazione originale) potrebbe essere necessario finalizzare le metriche della pagina precedente man mano che viene eseguita ogni nuova navigazione soft. Ciò significa che l'iniziale le metriche di navigazione possono essere finalizzate prima del solito.

Allo stesso modo, quando inizi a misurare le metriche per la nuova navigazione non lineare di queste metriche di lunga durata, le metriche dovranno essere "reimpostate" o "reinizializzato" e trattate come nuove metriche, senza memoria dei valori impostati per le "pagine" precedenti.

Come dovrebbero essere trattati i contenuti che rimangono gli stessi tra una navigazione e l'altra?

FP, FCP e LCP per le navigazioni morbide misureranno solo i nuovi colori. Ciò può comportare un diverso LCP, ad esempio, da un caricamento a freddo della navigazione soft a un caricamento soft.

Ad esempio, prendi una pagina che include una grande immagine banner che è l'elemento LCP, ma il testo sotto di essa cambia con ogni navigazione soft. Il caricamento iniziale della pagina contrassegnerà l'immagine del banner come elemento LCP e baserà i tempi LCP su questo valore. Per le navigazioni soft successive, il testo sottostante sarà l'elemento più grande visualizzato dopo la navigazione soft e sarà il nuovo elemento LCP. Tuttavia, se viene caricata una nuova pagina con un link diretto nell'URL di navigazione soft, l'immagine del banner verrà visualizzata in una nuova versione e sarà quindi idonea a essere considerata come elemento LCP.

Come mostrato in questo esempio, l'elemento LCP per la navigazione soft può essere riportato in modo diverso a seconda di come viene caricata la pagina: così come caricare una pagina con un link di ancoraggio più in basso nella pagina, può risultare un elemento LCP diverso.

Come si misura il TTFB?

Il tempo per il primo byte (TTFB) per un caricamento pagina convenzionale rappresenta il tempo in cui vengono restituiti i primi byte della richiesta originale.

Per una navigazione soft questa è una domanda più complessa. Dovremmo misurare la prima richiesta effettuata per la nuova pagina? Cosa succede se tutti i contenuti esistono già nell'app e non ci sono richieste aggiuntive? Cosa succede se la richiesta viene effettuata in anticipo con un precaricamento? Che cosa succede se una richiesta non correlata alla navigazione software dal punto di vista dell'utente (ad esempio, è una richiesta di analisi)?

Un metodo più semplice consiste nel segnalare un TTFB pari a 0 per le navigazioni semplici, in modo simile a quanto consigliamo per i ripristini della cache back/forward. Questo è il metodo utilizzato dalla libreria web-vitals per le navigazioni leggere.

In futuro, potremmo supportare modalità più precise per sapere quale richiesta è la "richiesta di navigazione" della navigazione non limitata. e potrà avere misurazioni TTFB più precise. Tuttavia, questo non fa parte dell'esperimento corrente.

Come si misurano sia i vecchi che i nuovi?

Durante l'esperimento, ti consigliamo di continuare a misurare i Core Web Vitals nel modo attuale, in base a dati "hard" navigazioni nelle pagine per corrispondere a ciò che CrUX misurerà e su cui farà riferimento come set di dati ufficiale dell'iniziativa Core Web Vitals.

Oltre a queste, occorre misurare le navigazioni leggere per permetterti di vedere come potrebbero essere misurate in futuro e per darti la possibilità di fornire al team di Chrome un feedback sul funzionamento pratico di questa implementazione. Questo aiuterà te e il team di Chrome a dare forma all'API in futuro.

Per misurare entrambi, devi essere a conoscenza dei nuovi eventi che possono essere generati in modalità di navigazione non lineare (ad esempio, più eventi FCP e LCP aggiuntivi) e gestirli in modo appropriato finalizzando queste metriche al momento opportuno, ignorando anche gli eventi futuri che si applicano solo alle navigazioni non trattate.

Usa la libreria web-vitals per misurare Core Web Vitals per navigazioni non semplici

Il modo più semplice per tenere conto di tutte le sfumature è utilizzare la libreria JavaScript web-vitals, che offre un supporto sperimentale per le navigazioni semplici in un file soft-navs branch separato (disponibile anche su npm e unpkg). Questo valore può essere misurato nel seguente modo (sostituendo doTraditionalProcessing e doSoftNavProcessing in base alle esigenze):

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

Assicurati che le metriche vengano registrate in base all'URL corretto come indicato in precedenza.

La libreria web-vitals genera report sulle seguenti metriche per le navigazioni leggere:

Metrica Dettagli
TTFB Segnalato come 0.
FCP Viene registrato solo il primo FCP della pagina.
LCP L'ora della successiva visualizzazione con contenuti più grande, relativa all'ora di inizio della navigazione soft. Le pitture esistenti presenti dalla navigazione precedente non vengono considerate. Di conseguenza, l'LCP sarà >= 0. Come di consueto, questo viene segnalato a seguito di un'interazione o quando la pagina viene visualizzata in background, poiché solo in questo caso l'LCP può essere finalizzato.
CLS La finestra più grande di spostamenti tra i tempi di navigazione. Come al solito, questo quando la pagina è in background, solo allora la CLS può essere finalizzata. Se non ci sono variazioni, viene riportato un valore 0.
INP L'INP tra i tempi di navigazione. Come di consueto, questi dati verranno riportati in seguito a un'interazione o quando la pagina viene visualizzata in background, solo in questo caso è possibile finalizzare l'INP. Se non ci sono interazioni, non viene registrato il valore 0.

Questi cambiamenti diventeranno parte delle misurazioni di Core Web Vitals?

Questo esperimento di navigazione morbida è esattamente questo: un esperimento. Prima di decidere se integrare questa iniziativa nell'iniziativa Core Web Vitals, vogliamo valutare le euristiche per capire se riflettono in modo più accurato l'esperienza utente. Siamo entusiasti all'idea di questo esperimento, ma non possiamo offrire garanzie sulla sostituzione delle misurazioni correnti o sulla sua data/ora.

Apprezziamo il fatto che gli sviluppatori web feedback sull'esperimento, l'euristica utilizzata e se ritieni che rifletta in modo più accurato l'esperienza. Il repository GitHub di navigazione morbida è il posto migliore per fornire questo feedback, anche se i singoli bug relativi all'implementazione di Chrome devono essere segnalati nell'Issue Tracker di Chrome.

Come verranno segnalate le navigazioni non chiare in CrUX?

È ancora da determinare il modo esatto in cui le navigazioni morbide verranno riportate in CrUX, in caso di esito positivo di questo esperimento. Non è detto che vengano trattati allo stesso modo degli attuali "hard" le navigazioni vengono trattate.

In alcune pagine web, per quanto riguarda l'utente le navigazioni semplici sono quasi identiche ai caricamenti delle pagine complete e l'utilizzo della tecnologia dell'applicazione a pagina singola è solo un dettaglio dell'implementazione. In altri casi, potrebbero essere più simili a un caricamento parziale di contenuti aggiuntivi.

Pertanto, potremmo decidere di segnalare queste navigazioni non pertinenti separatamente in CrUX o magari di ponderarle durante il calcolo dei Core Web Vitals per una determinata pagina o un determinato gruppo di pagine. Con l'evoluzione dell'euristica, potremmo anche essere in grado di escludere del tutto la navigazione soft a carico parziale.

Il team si sta concentrando sull'implementazione euristica e tecnica, che ci consentirà di valutare il successo dell'esperimento, quindi non è stata presa alcuna decisione su questi fronti.

Feedback

Stiamo attivamente cercando feedback su questo esperimento nelle seguenti sezioni:

Log delle modifiche

Poiché questa API è in fase di sperimentazione, vengono apportate diverse modifiche, più che con le API stabili. Per ulteriori dettagli, puoi consultare il log delle modifiche euristiche di navigazione morbida.

Conclusione

L'esperimento di navigazione soft è un approccio interessante all'evoluzione dell'iniziativa Core Web Vitals per misurare un modello comune sul web moderno che non è presente nelle nostre metriche. Sebbene questo esperimento sia ancora agli inizi e c'è ancora molto da fare, rendere i progressi disponibili finora per la community del web in generale per gli esperimenti è un passo importante. La raccolta dei feedback da questo esperimento è un'altra parte fondamentale dell'esperimento, pertanto consigliamo vivamente a coloro che sono interessati a questo sviluppo di sfruttare questa opportunità per modellare l'API e fare in modo che sia rappresentativa di ciò che speriamo di poter misurare con questo.

Ringraziamenti

Immagine in miniatura di Jordan Madrid su Unsplash