Sperimentazione con la misurazione delle navigazioni soft

Pubblicato: 1° febbraio 2023, ultimo aggiornamento: 31 luglio 2025

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

La realtà è sempre un po' più complicata dell'ideale e la popolare architettura Single Page Application non è mai stata completamente supportata dalle metriche Core Web Vitals. Anziché caricare pagine web distinte e individuali mentre l'utente naviga nel sito, queste applicazioni web utilizzano le cosiddette "navigazioni soft", in cui il contenuto della pagina viene modificato da JavaScript. In queste applicazioni, l'illusione di un'architettura di pagine web convenzionale viene mantenuta modificando l'URL e inserendo gli URL precedenti nella cronologia del browser per consentire ai pulsanti Indietro e Avanti di funzionare come previsto dall'utente.

Molti framework JavaScript utilizzano questo modello, ma ognuno in modo diverso. Poiché questo tipo di interazione non rientra in ciò che il browser considera tradizionalmente una "pagina", la misurazione è sempre stata difficile: dove deve essere tracciata la linea di demarcazione tra un'interazione nella pagina corrente e una pagina nuova?

Il team di Chrome sta valutando questa sfida da un po' di tempo e sta cercando di standardizzare una definizione di "navigazione soft" e di come i Segnali web essenziali possono essere misurati per questo, in modo simile a come vengono misurati i siti web implementati nell'architettura convenzionale multi-pagina (MPA).

Abbiamo lavorato duramente per migliorare l'API dall'ultima prova dell'origine e ora chiediamo agli sviluppatori di provare l'ultima iterazione e fornire feedback sull'approccio prima del lancio.

Che cos'è una navigazione soft?

Abbiamo elaborato la seguente definizione di navigazione soft:

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

Per alcuni siti, queste euristiche possono portare a falsi positivi (che gli utenti non considererebbero realmente una "navigazione ") o falsi negativi (in cui l'utente considera una "navigazione" nonostante non soddisfi questi criteri). Accettiamo feedback sull'euristica nel repository delle specifiche di navigazione soft.

In che modo Chrome implementa le navigazioni soft?

Una volta attivata l'euristica di navigazione soft (maggiori dettagli nella sezione successiva), Chrome cambierà il modo in cui vengono registrate alcune metriche sul rendimento:

  • Un evento soft-navigation PerformanceTiming verrà generato dopo ogni navigazione temporanea rilevata.
  • Verrà emesso un nuovo interaction-contentful-paint dopo le interazioni che causano un paint significativo. Può essere utilizzato per misurare la metrica Largest Contentful Paint (LCP) per le navigazioni soft quando una pittura di questo tipo si estende su una navigazione soft. Tieni presente che l'implementazione originale di questo ripristino reimpostava la metrica largest-contentful-paint, consentendone la riemissione, ma abbiamo optato per questo approccio alternativo per semplicità e per una maggiore portata futura.
  • A ciascuna delle tempistiche di rendimento (first-paint, first-contentful-paint, largest-contentful-paint, interaction-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, consentendo di calcolare e attribuire Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS) e Interaction to Next Paint (INP) all'URL corretto.

Queste modifiche consentiranno di misurare i Segnali web essenziali e alcune delle metriche diagnostiche associate per ogni navigazione della pagina, anche se è necessario considerare alcune sfumature.

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

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

  • Le metriche CLS e INP possono essere suddivise in base all'URL di navigazione soft, anziché essere misurate per tutta la durata del ciclo di vita della pagina.
  • La voce largest-contentul-paint è già finalizzata in un'interazione, quindi viene utilizzata solo per misurare l'LCP di navigazione "hard" iniziale, pertanto non è necessaria alcuna logica aggiuntiva per modificare la modalità di misurazione.
  • La nuova metrica interaction-contentful-paint verrà emessa dalle interazioni, che possono essere utilizzate per misurare LCP per le navigazioni temporanee.
  • Per attribuire le navigazioni soft all'URL corretto, potrebbe essere necessario prendere in considerazione il nuovo attributo navigationID nelle voci di rendimento nel codice dell'applicazione utilizzando queste voci.
  • Non tutti gli utenti supporteranno questa API di navigazione soft, in particolare per le versioni precedenti di Chrome e per chi utilizza altri browser. Tieni presente che alcuni utenti potrebbero non segnalare le metriche di navigazione soft, anche se segnalano le metriche di Core Web Vitals.
  • In quanto nuova funzionalità sperimentale non attivata per impostazione predefinita, i siti devono testarla per verificare la presenza di effetti collaterali indesiderati.

Verifica con il tuo fornitore di RUM se supporta la misurazione dei Segnali web essenziali tramite la navigazione soft. Molti prevedono di testare questo nuovo standard e terranno conto delle considerazioni precedenti. Nel frattempo, alcuni fornitori consentono anche misurazioni limitate delle metriche sul rendimento in base alle proprie euristiche.

Per saperne di più su come misurare le metriche per le navigazioni soft, consulta la sezione Misurazione di Core Web Vitals per navigazione soft.

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 funzionalità può essere attivata impostando il flag su chrome://flags/#soft-navigation-heuristics. L'opzione "Enabled Advanced Paint Attribution (Eager Cached Pre-Paint Walk)" è quella consigliata e diventerà presto l'opzione predefinita. In alternativa, può essere attivato utilizzando gli argomenti della riga di comando --enable-features=SoftNavigationHeuristics:mode/advanced_paint_attribution all'avvio di Chrome.

Per un sito web che vuole attivare questa funzionalità per tutti i suoi visitatori per vedere l'impatto, verrà eseguita una prova dell'origine a partire da Chrome 139, che può essere attivata registrandosi alla prova e includendo un elemento meta con il token di prova dell'origine nell'intestazione HTML o HTTP. Per ulteriori informazioni, consulta il post Guida introduttiva alle prove di origine.

I proprietari dei siti possono scegliere di includere la prova dell'origine nelle loro pagine per tutti gli utenti o solo per un sottoinsieme. Tieni presente la sezione Implicazioni precedente in merito a come questa modifica influisce sulla modalità di generazione dei report sulle metriche, soprattutto se attivi questa prova dell'origine per una percentuale elevata di utenti. Tieni presente che CrUX continuerà a generare report sulle metriche nel modo esistente, indipendentemente da questa impostazione di navigazione soft, pertanto non è interessato da queste implicazioni. Va inoltre osservato che le prove di origine sono limitate all'attivazione di funzionalità sperimentali su un massimo dello 0,5% di tutti i caricamenti di pagine Chrome come mediana in 14 giorni, ma questo dovrebbe essere un problema solo per i siti molto grandi.

Come posso misurare le navigazioni soft?

Una volta attivato l'esperimento di navigazione soft, le metriche verranno generate utilizzando l'API PerformanceObserver, come per le altre metriche. Tuttavia, per queste metriche è necessario prendere in considerazione alcuni aspetti aggiuntivi.

Report sulle navigazioni soft

Puoi utilizzare un PerformanceObserver per osservare le navigazioni soft. Di seguito è riportato un esempio di snippet di codice 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 });

Può essere utilizzato per finalizzare le metriche della pagina per l'intera durata della navigazione precedente.

Genera report sulle 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 riportate per l'URL precedente, in quanto l'URL attuale rifletterà l'URL aggiornato per la nuova pagina.

L'attributo navigationId dell'PerformanceEntry appropriato può essere utilizzato per ricollegare l'evento all'URL corretto. Puoi cercarlo 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 attuale che potrebbe essere stato utilizzato in passato.

Visualizzazione di startTime navigazioni soft

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 è l'ora dell'interazione iniziale (ad esempio, un clic su un pulsante) che ha avviato la navigazione soft.

Tutti i tempi di rendimento, inclusi quelli per le navigazioni soft, vengono riportati come tempo dalla navigazione "hard" iniziale della pagina. Pertanto, l'ora di inizio della navigazione soft è necessaria per stabilire una base di riferimento per i tempi delle metriche di caricamento della navigazione soft (ad esempio LCP), rispetto a questo tempo di navigazione soft.

Misurare i Segnali web essenziali per navigazione temporanea

Per includere le voci delle metriche di navigazione soft, devi includere includeSoftNavigationObservations: true nella chiamata observe dell'observer 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});

Con le ultime modifiche all'API, il flag includeSoftNavigationObservations non è più necessario e probabilmente verrà rimosso in futuro, ma per ora è necessario questo consenso esplicito a livello di osservatore delle prestazioni, oltre ad attivare la funzionalità di navigazione soft in Chrome.

I tempi verranno comunque restituiti rispetto all'ora di inizio della navigazione "hard" originale. Quindi, per calcolare LCP per una navigazione soft, ad esempio, dovrai prendere il tempo interaction-contentful-paint 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: 'interaction-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

Alcune metriche sono state tradizionalmente misurate durante il ciclo di vita della pagina: 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 man mano che si verifica ogni nuova navigazione soft. Ciò significa che le metriche di navigazione "hard" iniziali potrebbero essere finalizzate prima del solito.

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

Come devono essere trattati i contenuti che rimangono invariati tra le navigazioni?

LCP per le navigazioni soft (calcolato da interaction-contentful-paint) misurerà solo i nuovi paint. Ciò può comportare un LCP diverso, ad esempio, da un caricamento a freddo di quella navigazione soft a un caricamento soft.

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 temporanea. Il caricamento iniziale della pagina contrassegnerà l'immagine del banner come elemento LCP e baserà il tempismo 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 soft, l'immagine del banner sarà un nuovo paint e pertanto potrà essere considerata come elemento LCP.

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

Come misurare il TTFB?

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

Per una navigazione soft, questa è una domanda più difficile. 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 richieste aggiuntive? Che cosa succede se la richiesta viene effettuata in anticipo con un prefetch? Cosa succede se una richiesta non correlata alla navigazione soft 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 soft, in modo simile a quanto consigliato per i ripristini della cache back-forward. Questo è il metodo utilizzato dalla libreria web-vitals per le navigazioni soft.

In futuro, potremmo supportare modi 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'implementazione attuale.

Come misurare sia il vecchio che il nuovo?

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

Oltre a queste, devono essere misurate anche le navigazioni soft per consentirti di vedere come potrebbero essere misurate in futuro e per darti l'opportunità di fornire 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 LCP, ciò significa considerare solo largest-contentful-paint voci per il vecchio metodo e sia largest-contentful-paint che interaction-contentful-paint voci per il nuovo metodo.

Per CLS e INP, ciò significa misurare queste metriche durante l'intero ciclo di vita della pagina, come nel caso del vecchio metodo, e suddividere separatamente la sequenza temporale in base alle navigazioni temporanee per misurare valori CLS e INP separati per il nuovo metodo.

Utilizza la libreria web-vitals per misurare i Segnali web essenziali per le navigazioni soft

Il modo più semplice per tenere conto di tutte le sfumature è utilizzare la libreria JavaScript web-vitals, che offre supporto sperimentale per le navigazioni soft in un soft-navs branch separato (disponibile anche su npm e unpkg). 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 riportate in base all'URL corretto come indicato in precedenza.

La libreria web-vitals riporta le seguenti metriche per le navigazioni temporanee:

Metrica Dettagli
TTFB Segnalato come 0.
FCP Viene segnalato solo il primo FCP per la pagina.
LCP L'ora del successivo Largest Contentful Paint, rispetto all'ora di inizio della navigazione soft. Le verniciature esistenti della navigazione precedente non vengono prese in considerazione. Pertanto, LCP sarà >= 0. Come di consueto, questo valore verrà segnalato in seguito a un'interazione o quando la pagina viene messa in background, poiché solo allora può essere finalizzato l'LCP.
CLS La finestra più ampia di turni tra gli orari di navigazione. Come di consueto, ciò avviene quando la pagina viene messa in background, solo allora il CLS può essere finalizzato. Se non sono presenti turni, viene segnalato un valore pari a 0.
INP L'INP tra i tempi di navigazione. Come di consueto, questo valore verrà registrato in seguito a un'interazione o quando la pagina viene messa in background, poiché solo allora l'INP può essere finalizzato. Un valore pari a 0 non viene segnalato se non sono presenti interazioni.

Queste modifiche faranno parte delle misurazioni di Core Web Vitals?

Questo esperimento di navigazione soft è esattamente questo: un esperimento. Vogliamo valutare le euristiche e vedere se riflettono in modo più accurato l'esperienza utente prima di decidere se integrarle nell'iniziativa Core Web Vitals. Siamo molto entusiasti della possibilità di questo esperimento, ma non possiamo offrire garanzie in merito alla sostituzione delle misurazioni attuali.

Apprezziamo il feedback degli sviluppatori web sull'esperimento, sull'euristica utilizzata e se ritieni che rifletta in modo più accurato l'esperienza. Il repository GitHub di Soft Navigation è il posto migliore per fornire questo feedback, anche se i singoli bug relativi all'implementazione di Chrome devono essere segnalati nel tracker dei problemi di Chrome.

Come verranno registrate le navigazioni soft in CrUX?

Inoltre, se questo esperimento avrà esito positivo, è ancora da determinare in che modo verranno segnalate le navigazioni soft in CrUX. Non è detto che vengano trattati allo stesso modo delle attuali navigazioni "hard".

In alcune pagine web, le navigazioni soft sono quasi identiche ai caricamenti di pagine complete 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 segnalare queste navigazioni soft separatamente in CrUX o magari ponderarle durante il calcolo dei segnali web essenziali per una determinata pagina o gruppo di pagine. Man mano che l'euristica si evolve, potremmo anche essere in grado di escludere completamente la navigazione soft con caricamento parziale.

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

Feedback

Stiamo cercando attivamente feedback su questo esperimento nei seguenti luoghi:

In caso di dubbi, non preoccuparti troppo. Preferiamo ricevere il feedback in entrambi i luoghi e saremo felici di eseguire il triage dei problemi in entrambi i luoghi e reindirizzare i problemi alla posizione corretta.

Log delle modifiche

Poiché questa API è in fase sperimentale, sono in corso diverse modifiche, più che con le API stabili. Per ulteriori dettagli, consulta il changelog dell'euristica di navigazione soft.

Conclusione

L'esperimento sulle navigazioni soft è un approccio entusiasmante all'evoluzione dell'iniziativa Segnali web essenziali per misurare un pattern comune sul web moderno che non è presente nelle nostre metriche. Anche se questo esperimento è ancora nelle sue fasi iniziali e c'è ancora molto da fare, rendere i progressi compiuti finora disponibili alla più ampia community web per la sperimentazione è un passo importante. La raccolta dei feedback di questo esperimento è un'altra parte fondamentale dell'esperimento, pertanto incoraggiamo vivamente le persone interessate a questo sviluppo a utilizzare questa opportunità per contribuire a modellare l'API in modo che sia rappresentativa di ciò che speriamo di poter misurare con questo strumento.

Ringraziamenti

Immagine in miniatura di Jordan Madrid su Unsplash

Questo lavoro è la continuazione di un lavoro iniziato da Yoav Weiss quando lavorava in Google. Ringraziamo Yoav per il suo impegno in questa API.