Sperimentazione con la misurazione delle navigazioni soft

Barry Pollard

Yoav Weiss

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 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ù 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, viene mantenuta l'illusione di un'architettura convenzionale di pagine web 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.

Molti framework JavaScript utilizzano questo modello, ma ognuno in modo diverso. Poiché non rientra 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 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 un feedback sull'approccio finora adottato.

Che cos'è una 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 Prima visualizzazione con contenuti (FP), Prima visualizzazione con contenuti (FCP) e Visualizzazione con contenuti più grandi (LCP) verranno reimpostate e riemesse di nuovo 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 altri 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. Pertanto, tieni presente che alcuni utenti potrebbero non segnalare le metriche di navigazione temporanea.
• 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 soft, consulta la sezione Misurazione di Core Web Vitals per navigazione non attiva.

Come faccio ad attivare le navigazioni soft in Chrome?

Le navigazioni soft non sono attivate 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.

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.

Segnala le metriche in base 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. 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 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.

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;

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

Tutti i tempi delle prestazioni, inclusi quelli per le navigazioni semplici, vengono indicati come tempi del tempo di navigazione iniziale "inflessibile" nelle pagine. 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.

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});

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 delle prestazioni ha lo scopo di garantire che gli attuali osservatori delle prestazioni non vengano sorpresi da queste voci aggiuntive, in quanto è necessario prendere in considerazione alcune considerazioni aggiuntive quando si cerca di misurare Core Web Vitals per navigazione non problematica.

I tempi verranno comunque restituiti in base all'ora di inizio della navigazione "rigida" originale. Di conseguenza, per calcolare l'LCP per una navigazione non lineare, ad esempio, dovrai prendere il tempo LCP e sottrarre l'ora di inizio della navigazione soft appropriata come descritto 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 sono state tradizionalmente misurate per tutta la durata della pagina: l'LCP, ad esempio, può cambiare fino a quando non si verifica un'interazione. I valori CLS e INP possono essere aggiornati finché la pagina non viene chiusa. 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 iniziali "hardcore" possono 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 memorizzare i 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 agevoli 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 una grande immagine banner che è l'elemento LCP, ma il testo sotto di essa cambia con ogni navigazione soft. Il caricamento iniziale della pagina sposterà l'immagine del banner come elemento LCP e baserà il tempo LCP su questo. 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 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? Che cosa succede se una richiesta non correlata alla navigazione temporanea dal punto di vista dell'utente (ad esempio, è 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 l'esperimento, ti consigliamo di continuare a misurare i Core Web Vitals nel modo attuale, in base a navigazioni nelle pagine "difficili", in modo da corrispondere ai dati che verranno misurati e utilizzati da CrUX 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 entrambi, devi essere consapevole dei nuovi eventi che potrebbero essere emessi in modalità di navigazione agevolata (ad esempio più eventi FCP ed eventi LCP aggiuntivi) e gestirli in modo appropriato finalizzando queste metriche al momento opportuno, ignorando al contempo gli eventi futuri che si applicano solo alle navigazioni agevolate.

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:

Questi cambiamenti diventeranno 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 entusiasti all'idea di questo esperimento, ma non possiamo offrire garanzie sulla sostituzione delle misurazioni correnti o sulla sua data/ora.

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?

Anche il modo in cui le navigazioni non dirette verranno registrate in CrUX, se l'esperimento avrà esito positivo, è ancora da stabilire. 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. 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 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 generale sui segnali web vitals all'indirizzo web-vitals-feedback@googlegrouops.com.

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 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. 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