Sperimentazione con la misurazione delle navigazioni soft

Barry Pollard

Yoav Weiss

Aggiornamento di agosto 2024: il secondo monitoraggio delle origini di navigazione morbida è terminato il 29 maggio. Il team di Chrome si sta prendendo del tempo per esaminare i feedback dell'esperimento e valutare i passaggi successivi per questa API. Vogliamo risolvere alcuni problemi di accuratezza e riteniamo che sarà necessaria un'altra prova dell'origine prima che la funzionalità possa essere implementata. Nel frattempo, gli sviluppatori possono comunque fare esperimenti con la funzionalità attivando chrome://flags/#enable-experimental-web-platform-features.

Fin dal suo lancio, l'iniziativa Core Web Vitals ha cercato di misurare l'esperienza utente effettiva di un sito web, anziché i dettagli tecnici relativi alla creazione o al caricamento di un sito web. Le tre metriche Core Web Vitals sono state create come metriche incentrate sull'utente, un'evoluzione delle metriche tecniche esistenti come DOMContentLoaded o load che misuravano tempi spesso non correlati alla percezione degli utenti del rendimento della pagina. Per questo motivo, la tecnologia utilizzata per creare il sito non dovrebbe influire sul punteggio, a condizione che il sito funzioni bene.

La realtà è sempre un po' più complicata 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 nel sito, queste applicazioni web utilizzano le cosiddette "navigazioni soft", in cui i contenuti della pagina vengono modificati da JavaScript. In queste applicazioni, l'illusione di un'architettura di pagina web convenzionale viene mantenuta modificando l'URL e inserendo gli URL precedenti nella cronologia del browser per consentire il funzionamento dei pulsanti Indietro e Avanti come previsto dall'utente.

Molti framework JavaScript utilizzano questo modello, ma ognuno in modo diverso. Poiché non rientrano in ciò che il browser definisce tradizionalmente una "pagina", la misurazione è sempre stata difficile: dove si traccia la linea di demarcazione tra un'interazione nella pagina corrente e il fatto di considerarla una nuova pagina?

Il team di Chrome sta valutando questa sfida da un po' di tempo e sta cercando di standardizzare una definizione di "navigazione agevole" e di come misurare i Core Web Vitals per questo, in modo simile a come vengono misurati i siti web implementati nell'architettura multipagina (MPA) convenzionale. Anche se è ancora in una fase iniziale, il team è ora pronto a rendere più ampiamente disponibile ciò che è già stato implementato per consentire ai siti di eseguire esperimenti. In questo modo, i siti potranno fornire un feedback sull'approccio finora adottato.

Che cos'è la navigazione soft?

Abbiamo elaborato la seguente definizione di navigazione graduale:

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

Per alcuni siti, queste strategie possono portare a falsi positivi (in cui gli utenti non considerano realmente avvenuta una "navigazione ") o a falsi negativi (in cui l'utente considera avvenuta una "navigazione" nonostante non soddisfi questi criteri). Ti invitiamo a inviare un feedback sulle nostre strategie di navigazione nel repository delle specifiche di navigazione soft.

In che modo Chrome implementa le navigazioni agevoli?

Una volta attivate le heurismi di navigazione soft (maggiori dettagli nella sezione successiva), Chrome cambierà il modo in cui registra alcune metriche sul rendimento:

• Un evento soft-navigation PerformanceTiming viene emesso dopo ogni rilevamento di navigazione soft.
• L'API Performance fornirà l'accesso a una voce di temporizzazione soft-navigation, emessa dall'evento soft-navigation PerformanceTiming.
• Le metriche First Paint (FP), First Contentful Paint (FCP) e Largest Contentful Paint (LCP) verranno reimpostate e ritrasmesse alle successive occorrenze appropriate. (Nota: FP e FCP non sono implementati).
• A ogni tempo di rendimento (first-paint, first-contentful-paint, largest-contentful-paint, first-input-delay, event e layout-shift) verrà aggiunto un attributo navigationId corrispondente alla voce di navigazione a cui era correlato l'evento, in modo da poter calcolare Cumulative Layout Shift (CLS) e Interaction to Next Paint (INP).

Queste modifiche consentiranno di misurare i Core Web Vitals e alcune delle metriche di diagnostica associate per navigazione tra le pagine, anche se ci sono alcune sfumature da considerare.

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

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

• Per le navigazioni non dirette potrebbero essere emessi nuovamente eventi FP, FCP e LCP. Il Rapporto sull'esperienza utente di Chrome (CrUX) ignorerà questi valori aggiuntivi, ma ciò potrebbe influire sul monitoraggio della misurazione degli utenti reali (RUM) sul tuo sito. Se hai dubbi in merito all'impatto di questa operazione sulle misurazioni, rivolgiti al tuo fornitore RUM. Consulta la sezione relativa alla misurazione dei Core Web Vitals per le navigazioni agevoli.
• Il nuovo attributo (facoltativo) navigationID nelle voci sul rendimento potrebbe dover essere preso in considerazione nel codice dell'applicazione che le utilizza.
• Solo i browser basati su Chromium supporteranno questa nuova modalità. Sebbene molte delle metriche più recenti siano disponibili solo nei browser basati su Chromium, alcune (FCP, LCP) sono disponibili negli altri browser e non tutti potrebbero aver eseguito l'upgrade all'ultima versione dei browser basati su Chromium. Tieni presente che alcuni utenti potrebbero non registrare le metriche di navigazione soft.
• Poiché si tratta di una nuova funzionalità sperimentale non attivata per impostazione predefinita, i siti devono testarla per assicurarsi che non ci siano altri effetti collaterali indesiderati.

Per ulteriori informazioni su come misurare le metriche per le navigazioni non dirette, consulta la sezione Misurare Core Web Vitals per navigazione non diretta.

Come faccio ad attivare le navigazioni soft in Chrome?

Le navigazioni soft non sono attive per impostazione predefinita in Chrome, ma sono disponibili per la sperimentazione attivando esplicitamente questa funzionalità.

Per gli sviluppatori, questa opzione può essere attivata attivando il flag Funzionalità sperimentali della piattaforma web in 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 faccio a misurare le navigazioni soft?

Una volta attivato l'esperimento di navigazione agevolata, le metriche verranno registrate utilizzando l'API PerformanceObserver come di consueto. Tuttavia, per queste metriche è necessario prendere in considerazione alcune considerazioni aggiuntive.

Nota: tieni presente che FP e FCP non sono ancora registrati per le navigazioni soft.

Segnalare le navigazioni non dirette

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

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

Questo può essere utilizzato per finalizzare le metriche della pagina per l'intero ciclo di vita per la navigazione precedente.

Genera report sulle metriche relative all'URL appropriato

Poiché le navigazioni soft 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 rifletterà l'URL aggiornato della nuova pagina.

L'attributo navigationId dell'elemento PerformanceEntry appropriato può essere utilizzato per ricollegare l'evento all'URL corretto. Questo valore può essere cercato con 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 deve essere utilizzato per generare report sulle metriche in base all'URL corretto, anziché all'URL corrente che l'utente potrebbe aver utilizzato in passato.

Ottenere il startTime delle navigazioni non dirette

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;

startTime indica il momento dell'interazione iniziale (ad esempio un clic sul pulsante) che ha avviato la navigazione agevolata.

Tutti i tempi di rendimento, inclusi quelli per le navigazioni non forzate, vengono registrati come intervallo di tempo dal momento iniziale della navigazione "forzata" della pagina. Pertanto, l'ora di inizio della navigazione assistita è necessaria per stabilire la baseline dei tempi delle metriche di caricamento della navigazione assistita (ad esempio LCP), in base a questo momento.

Misurare i Core Web Vitals per la navigazione non forzata

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

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

Il flag includeSoftNavigationObservations aggiuntivo nel metodo observe è necessario oltre ad attivare la funzionalità di navigazione fluida in Chrome. Questa attivazione esplicita a livello di osservatore del rendimento serve a garantire che gli osservatori del rendimento esistenti non siano sorpresi da queste voci aggiuntive, in quanto è necessario prendere in considerazione alcune considerazioni aggiuntive quando si tenta di misurare Core Web Vitals per le navigazioni non attive.

I tempi verranno comunque restituiti in base all'ora di inizio della navigazione "rigida" originale. Pertanto, per calcolare il valore LCP per una navigazione graduale, ad esempio, devi prendere il tempo LCP e sottrarre il tempo di inizio della navigazione graduale appropriato, come descritto in precedenza, per ottenere un tempo relativo alla navigazione graduale. 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 sono state tradizionalmente misurate per tutta la durata della pagina: l'LCP, ad esempio, può cambiare fino a quando non si verifica un'interazione. CLS e INP possono essere aggiornati finché non si esce dalla pagina. Pertanto, ogni "navigazione" (inclusa quella originale) potrebbe dover finalizzare le metriche della pagina precedente a ogni nuova navigazione soft. Ciò significa che le metriche di navigazione "hard" iniziali potrebbero essere finalizzate prima del solito.

Analogamente, quando inizi a misurare le metriche per la nuova navigazione soft di queste metriche a lungo termine, le metriche devono essere "reimpostate" o "riinizializzate" e trattate come nuove metriche, senza memoria dei valori impostati per le "pagine" precedenti.

Come devono essere trattati i contenuti che rimangono invariati tra una navigazione e l'altra?

FP, FCP e LCP per le navigazioni non dirette misureranno solo i nuovi paint. Ciò può comportare un LCP diverso, ad esempio da un caricamento a freddo di questa navigazione graduale a un caricamento graduale.

Ad esempio, prendi una pagina che include un'immagine banner di grandi dimensioni che è l'elemento LCP, ma il testo sottostante cambia a ogni navigazione soft. Il caricamento iniziale della pagina segnalerà l'immagine del banner come elemento LCP e baserà il relativo tempo su questo. Per le successive navigazioni agevolate, il testo sottostante sarà l'elemento più grande visualizzato dopo la navigazione agevolata e sarà il nuovo elemento LCP. Tuttavia, se viene caricata una nuova pagina con un link diretto all'URL di navigazione flessibile, l'immagine del banner sarà una nuova pittura e, pertanto, potrà essere considerata come elemento LCP.

Come mostra questo esempio, l'elemento LCP per la navigazione agevolata può essere registrato in modo diverso a seconda di come viene caricata la pagina, nello stesso modo in cui il caricamento di una pagina con un link di ancoraggio più in basso può comportare un elemento LCP diverso.

Come misurare il TTFB?

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

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

Un metodo più semplice è registrare un TTFB pari a 0 per le navigazioni non dirette, in modo simile a quanto consigliato per i ripristini della cache back-forward. Questo è il metodo utilizzato dalla libreria web-vitals per le navigazioni non dirette.

In futuro, potremmo supportare metodi più precisi per sapere quale richiesta è la "richiesta di navigazione" della navigazione soft e potremo avere misurazioni TTFB più precise. Ma non fa parte dell'esperimento attuale.

Come misurare sia le vecchie che le nuove?

Durante questo esperimento, ti consigliamo di continuare a misurare i Core Web Vitals nel modo attuale, in base alle navigazioni "hard" delle pagine, in modo che corrispondano a ciò che CrUX misurerà e registrerà come set di dati ufficiale dell'iniziativa Core Web Vitals.

Le navigazioni non dirette devono essere misurate in aggiunta a queste per consentirti di vedere come potrebbero essere misurate in futuro e per darti l'opportunità di fornire un feedback al team di Chrome su come funziona questa implementazione nella pratica. In questo modo, tu e il team di Chrome potrete definire l'API in futuro.

Per misurare entrambe, devi essere consapevole dei nuovi eventi che potrebbero essere emessi in modalità di navigazione soft (ad esempio più eventi FCP e altri eventi LCP) e gestirli in modo appropriato finalizzando queste metriche al momento opportuno, ignorando al contempo gli eventi futuri che si applicano solo alle navigazioni soft.

Utilizza la libreria web-vitals per misurare i Core Web Vitals per le navigazioni non dirette

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

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 registra le seguenti metriche per le navigazioni agevoli:

Metrica	Dettagli
TTFB	Segnalato come 0.
FCP	Viene registrato solo il primo CPC per la pagina.
LCP	L'ora del successivo Largest Contentful Paint, rispetto all'ora di inizio della navigazione soft. Le vernici esistenti presenti dalla navigazione precedente non vengono prese in considerazione. Pertanto, il valore LCP sarà >= 0. Come di consueto, questo valore verrà registrato in seguito a un'interazione o quando la pagina è in background, poiché solo in questo caso è possibile finalizzare il valore LCP.
CLS	La finestra più grande di variazioni tra i tempi di navigazione. Come di consueto, questo accade quando la pagina è in background, perché solo in questo caso il CLS può essere finalizzato. Viene riportato un valore 0 se non sono presenti turni.
INP	L'INP tra i tempi di navigazione. Come di consueto, questo verrà registrato in seguito a un'interazione o quando la pagina viene messa in background, poiché solo in questo caso l'INP può essere finalizzato. Un valore 0 non viene registrato se non ci sono interazioni.

Avviso: l'implementazione di web-vitals è in fase di sviluppo attivo ed è soggetta a modifiche con le nuove modifiche pubblicate in quel branch. Non supporta il FCP nelle navigazioni soft, in quanto richiede più lavoro sottostante in Chrome. Chi utilizza la libreria JavaScript web-vitals deve tenere presente questo aspetto se intende utilizzarla sui siti di produzione, deve creare una copia locale e testare la versione, nonché monitorare il ramo per verificare la presenza di modifiche.

Queste modifiche faranno parte delle misurazioni di Core Web Vitals?

Questo esperimento sulla navigazione graduale è esattamente questo: un esperimento. Prima di decidere se queste verranno integrate nell'iniziativa Core Web Vitals, vogliamo valutare le strategie di ricerca e capire se riflettono in modo più accurato l'esperienza utente. Siamo molto entusiasti della possibilità di questo esperimento, ma non possiamo garantire se e quando sostituirà le misurazioni attuali.

Il feedback degli sviluppatori web sull'esperimento, sulle strategie di ricerca utilizzate e sul fatto che ritieni che l'esperimento rifletta più accuratamente l'esperienza è molto importante per noi. Il repository GitHub della navigazione fluida è il posto migliore per fornire questo feedback, anche se i singoli bug relativi all'implementazione di questa funzionalità in Chrome devono essere segnalati nel tracker dei problemi di Chrome.

Come verranno registrate le navigazioni soft in CrUX?

Non è ancora stato stabilito con esattezza in che modo le navigazioni non dirette verranno registrate in CrUX, se l'esperimento avrà esito positivo. Non è necessariamente scontato che verranno trattate nello stesso modo delle attuali navigazioni "rigide".

In alcune pagine web, le navigazioni soft sono quasi identiche ai caricamenti completi della pagina per quanto riguarda l'utente e l'utilizzo della tecnologia Single Page Application è solo un dettaglio di implementazione. In altri casi, potrebbero essere più simili a un caricamento parziale di contenuti aggiuntivi.

Pertanto, potremmo decidere di registrare queste navigazioni soft separatamente in CrUX o forse di attribuire loro un peso maggiore durante il calcolo dei Core Web Vitals per una determinata pagina o un determinato gruppo di pagine. Potremmo anche essere in grado di escludere completamente la navigazione soft con caricamento parziale, man mano che l'euristica si evolve.

Il team si sta concentrando sull'implementazione tecnica ed euristica, che ci consentirà di valutare l'efficacia di questo esperimento, pertanto non è stata presa alcuna decisione in merito.

Feedback

Stiamo cercando attivamente feedback su questo esperimento nei seguenti luoghi:

• Le strategie di navigazione soft e la standardizzazione.
• Problemi di implementazione di Chrome di queste heurismi.
• Feedback generali su Core Web Vitals all'indirizzo [e-mail].

Log delle modifiche

Poiché questa API è in fase di sperimentazione, sono in corso una serie di modifiche, più che con le API stabili. Per maggiori dettagli, consulta il log delle modifiche delle strategie di navigazione soft.

Conclusione

L'esperimento sulle navigazioni soft è un approccio interessante per capire in che modo l'iniziativa Core Web Vitals potrebbe evolversi per misurare uno schema comune sul web moderno che non è presente nelle nostre metriche. Anche se questo esperimento è ancora agli inizi e c'è ancora molto da fare, mettere a disposizione della community web più ampia i progressi finora ottenuti è un passo importante. La raccolta dei feedback di questo esperimento è un'altra parte fondamentale dell'esperimento, quindi invitiamo vivamente gli utenti interessati a questo sviluppo a cogliere l'opportunità di contribuire a definire l'API in modo che sia rappresentativa di ciò che speriamo di poter misurare.

Ringraziamenti

Immagine in miniatura di Jordan Madrid su Unsplash