Misurare le navigazioni soft

Barry Pollard

Michal Mocny

Pubblicato: 1° febbraio 2023, ultimo aggiornamento: 24 giugno 2026

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ù complessa dell'ideale e la popolare architettura applicazione a pagina singola 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 tracciare il confine 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 Core Web Vitals possono essere misurati per questo, in modo simile a come vengono misurati i siti web implementati nell'architettura convenzionale multi-pagina (MPA).

Abbiamo apportato diversi miglioramenti alla proposta in base al feedback degli sviluppatori e puntiamo a rilasciare due nuove API per il rendimento per risolvere questo problema a partire da Chrome 151.

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.
• L'interazione genera un rendering visibile.

Per alcuni siti, questa definizione potrebbe 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 nel repository delle specifiche di navigazione soft.

Supporto di DevTools per le navigazioni soft

Abbiamo aggiunto il supporto per le navigazioni soft al riquadro Prestazioni di DevTools nella visualizzazione Traccia:

Puoi visualizzare i marcatori per le navigazioni soft e LCP, entrambi contrassegnati con un * per distinguerli dalle normali voci di navigazione hard. Questa opzione è abilitata per impostazione predefinita ed è separata dalle modifiche all'API Performance che tratteremo di seguito. È un modo rapido per verificare se il rilevamento della navigazione soft funziona correttamente per il tuo sito.

Per il momento, nella visualizzazione della traccia vengono visualizzati solo i timestamp di navigazione soft e LCP. Altre metriche (ad esempio LCP) e il supporto nella visualizzazione Metriche in tempo reale verranno aggiunti in un secondo momento.

In che modo Chrome implementa le navigazioni soft per gli sviluppatori web?

Una volta attivata la funzionalità di navigazione soft (maggiori dettagli nella sezione successiva), Chrome modificherà il modo in cui vengono registrate alcune metriche sul rendimento:

• Un evento soft-navigation PerformanceTiming verrà generato dopo ogni navigazione temporanea rilevata.
• Questa voce soft-navigation includerà un navigationId, il nuovo URL nell'attributo name, nonché un interactionId dell'interazione iniziale.
• Una o più voci interaction-contentful-paint verranno emesse dopo le interazioni che causano un rendering significativo dei contenuti. Questo conterrà una voce largestContentfulPaint che può essere utilizzata per misurare la metrica Largest Contentful Paint (LCP) per le navigazioni soft.
• L'attributo navigationId viene aggiunto a ciascuna delle tempistiche del rendimento (first-paint, first-contentful-paint, largest-contentful-paint, interaction-contentful-paint, first-input-delay, event e layout-shift). Corrisponde alla voce di navigazione in cui è stato generato l'evento. Tieni presente che quando queste voci si estendono su navigazioni soft, possono contenere il navigationId precedente o successivo a seconda di quando è stata emessa la voce. Scopri di più nella sezione Generare report sulle metriche in base all'URL appropriato.
• soft-navigation includerà una funzione getLargestInteractionContentfulPaint() per recuperare la voce interaction-contentful-paint più grande per quella navigazione. Questo valore può essere utilizzato come LCP iniziale per la navigazione e può essere aggiornato man mano che vengono osservate altre voci interaction-contentful-paint per l'interazione. Tieni presente che questo attributo sostituisce un attributo largestInteractionContentfulPaint disponibile nelle prove dell'origine precedenti.
• Potenzialmente, alcune voci interaction-contentful-paint potrebbero essere state registrate prima della navigazione soft (se l'aggiornamento dell'URL non avviene prima di questi paint). In questi casi, la funzione getLargestInteractionContentfulPaint() evita di dover memorizzare nel buffer e rivedere le voci precedenti dopo il completamento di una navigazione soft. Tieni presente che la voce restituita da getLargestInteractionContentfulPaint() è una copia esatta della voce interaction-contentful-paint più grande al momento dell'emissione, pertanto questa voce potrebbe aver utilizzato il valore navigationId precedente, poiché è stato in quel momento che è avvenuta la pittura, ma queste pitture devono essere misurate rispetto al nuovo valore navigationId.
• La voce soft-navigation includerà anche paintTime e presentationTime come FCP per quella navigazione.
• Tieni presente che le voci interaction-contentful-paint verranno emesse anche dopo ulteriori interazioni, ma LCP per un URL deve essere limitato alle voci interaction-contentful-paint che corrispondono alle navigazioni soft interactionId per escluderle e anche solo alle proprietà largestContentfulPaint al loro interno.

Queste modifiche consentiranno di misurare i Core Web Vitals 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à:

• Il monitoraggio delle voci soft-navigation consente di "suddividere" le voci di rendimento in ogni "navigazione".
• Le metriche CLS e INP possono già essere suddivise a tua discrezione, anziché essere misurate per tutta la durata del ciclo di vita della pagina, ma la funzionalità di navigazione soft fornisce una misurazione standardizzata di quando ciò si verifica, indipendentemente dalla tecnologia sottostante utilizzata.
• La voce largest-contentful-paint viene finalizzata in un'interazione (necessaria per avviare una navigazione soft), quindi può essere utilizzata solo per misurare l'LCP della navigazione "hard" iniziale. Ciò significa che questa metrica non cambierà quando vengono misurate le navigazioni soft, quindi LCP per il caricamento della pagina iniziale e hard può essere misurata come sempre.
• La nuova voce interaction-contentful-paint che verrà emessa dalle interazioni può essere utilizzata per misurare LCP per le navigazioni soft esaminando la proprietà largestContentfulPaint al suo interno, ma ci sono alcune considerazioni su come utilizzare questa voce che tratteremo in questo articolo.
• Tieni presente che non tutti gli utenti supportano questa funzionalità 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 basate sulla navigazione soft, anche se segnalano le metriche Core Web Vitals.

Verifica con il tuo provider RUM se supporta la misurazione dei Core Web Vitals 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 temporanee, consulta la sezione Misurazione di Core Web Vitals per navigazione temporanea.

Come faccio ad attivare le navigazioni soft in Chrome?

La funzionalità di navigazione soft dovrebbe essere attivata per impostazione predefinita in Chrome 151, ma è disponibile per i test prima di questa versione attivandola esplicitamente.

Per gli sviluppatori, questa opzione può essere attivata impostando il flag su chrome://flags/#soft-navigation-heuristics. In alternativa, può essere attivato utilizzando gli argomenti della riga di comando --enable-features=SoftNavigationHeuristics all'avvio di Chrome. L'attivazione del flag chrome://flags/#enable-experimental-web-platform-features attiva anche le navigazioni soft.

Alcuni proprietari di siti web hanno anche attivato questa funzionalità sui siti prima del lancio tramite la procedura di prova dell'origine. Tieni presente che la forma dell'API è cambiata durante lo sviluppo della funzionalità e le differenze tra la funzionalità finale e le precedenti prove di origine sono descritte in dettaglio nel changelog delle navigazioni soft

Supporto dell'API Soft Navigations per il rilevamento delle funzionalità

Puoi utilizzare il seguente codice per verificare se l'API è supportata:

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

Tieni presente che supportedEntryTypes viene bloccato al primo utilizzo, quindi se il supporto della navigazione soft viene aggiunto dinamicamente da un token di prova dell'origine inserito nella pagina, potrebbe restituire il valore originale, prima dell'attivazione della funzionalità.

In questo caso, puoi utilizzare la seguente alternativa mentre le navigazioni soft non sono ancora supportate per impostazione predefinita e si trovano in questo stato di transizione:

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

Come posso misurare le navigazioni soft?

Una volta attivato il rilevamento delle navigazioni 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

Quando viene visualizzata una navigazione soft, i Core Web Vitals della pagina precedente devono essere finalizzati e poi segnalati per l'URL precedente. Il nuovo monitoraggio deve essere avviato per il nuovo URL.

L'attributo name della voce soft-navigation appropriata conterrà il nuovo URL per cui generare le metriche, mentre navigationId sarà il riferimento univoco per questa navigazione (poiché lo stesso URL potrebbe essere visitato più volte durante la durata di una singola applicazione a pagina singola).

Questo valore deve essere impostato come ogni voce soft-navigation e utilizzato per generare report sulle metriche fino alla ricezione della voce soft-navigation successiva.

Segnala l'URL corretto per interaction-contentful-paint

Per calcolare l'LCP dalle voci interaction-contentful-paint sono necessarie considerazioni aggiuntive, poiché non tutte le voci interaction-contentful-paint devono essere mappate utilizzando navigationId e segnalate come LCP per quell'URL:

• Il primo problema è che le voci interaction-contentful-paint potrebbero essere emesse prima che si verifichi la navigazione temporanea se si verifica un rendering prima dell'aggiornamento dell'URL. In questi casi, il navigationId sarà per il vecchio URL. Se l'URL viene aggiornato per primo, il rendering completerà la navigazione soft e in questo caso verrà emessa prima la voce soft-navigation e interaction-contentful-paint avrà il nuovo URL.
• Il secondo problema è che interaction-contentful-paint, le voci continueranno a essere emesse per le interazioni più recenti, poiché l'ambito di questa metrica delle prestazioni si estende oltre il solo LCP per le navigazioni soft. Vogliamo prendere in considerazione solo i paint per il caricamento della navigazione soft per LCP e non quelli per le interazioni successive.

Pertanto, per mappare le voci interaction-contentful-paint a soft-navigation-entries per ottenere l'URL corretto, è necessario utilizzare interactionId anziché navigationId. In questo modo verranno gestite tutte le voci con navigationId precedenti e verranno filtrate tutte le voci interaction-contentful-paint che non devono essere prese in considerazione per LCP.

Inoltre, devi prendere in considerazione l'elaborazione della funzione getLargestInteractionContentfulPaint() delle voci soft-navigation, per gestire più facilmente le voci interaction-contentful-paint che si verificano prima dell'emissione di soft-navigation entries.

Visualizzazione di startTime navigazioni soft

Tutti i tempi di rendimento, inclusi quelli per le navigazioni soft, e le voci utilizzate per calcolare le metriche di Core Web Vitals vengono riportati come tempo dalla navigazione nelle pagine "hard" iniziale. Pertanto, il tempo di inizio della navigazione soft deve essere sottratto dai tempi delle metriche di caricamento della navigazione soft (ad esempio LCP) per segnalarli in relazione a questo tempo di navigazione soft.

L'ora di inizio della navigazione può essere ottenuta in modo simile mappando la voce soft-navigation appropriata e utilizzando il relativo startTime.

startTime è l'ora dell'interazione iniziale (ad esempio, un clic su un pulsante) che ha avviato la navigazione soft. Questo è leggermente diverso dalle "navigazioni hard", in cui l'"ora di inizio" è il momento in cui la nuova pagina viene "confermata" al browser e dopo l'esecuzione di parte del codice del gestore di eventi. Anche i tempi di inizio della navigazione soft includono il codice del gestore di eventi, poiché la misurazione viene eseguita a partire dal tempo di inizio dell'interazione.

Misurare i Core Web Vitals per navigazione soft

Per misurare i Core Web Vitals, ascolta le voci soft-navigation e reimposta le metriche al ricevimento. L'FCP può essere emesso in base a presentationTime e l'LCP può essere inizializzato in base alla voce getLargestInteractionContentfulPaint(). INP, CLS, devono essere inizializzati a 0 come per il caricamento di una pagina.

LCP, INP e CLS possono quindi essere misurati e monitorati come di consueto (con l'eccezione dell'utilizzo di interaction-contentful-paint per LCP che fornisce le corrispondenze interactionId). interactionId può essere utilizzato per assegnare un nome alle voci di un URL, come descritto in precedenza.

I tempi verranno comunque restituiti rispetto all'ora di inizio della navigazione "hard" originale. Pertanto, 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.

Alcune metriche sono state tradizionalmente misurate durante il ciclo di vita della pagina: LCP, ad esempio, può cambiare finché non si verifica un'interazione. CLS e INP possono essere aggiornati finché non si esce dalla pagina, indipendentemente dalle interazioni. Pertanto, le metriche della navigazione precedente devono essere finalizzate a ogni nuova navigazione soft. Ciò significa che le metriche di navigazione "hard" iniziali potrebbero essere finalizzate prima del solito quando si misurano i Core Web Vitals con le navigazioni soft.

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. ovvero la comprensione di quale sia la pittura, l'interazione con il successivo paint o lo spostamento del layout "più grande" viene reimpostata per consentire una nuova misurazione da zero.

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 e solo quelli associati all'interazione che ha causato la navigazione. Ciò può comportare un LCP diverso, ad esempio, da un caricamento completo di quella navigazione soft a un caricamento soft.

Ad esempio, prendi una pagina che include un'immagine del banner di grandi dimensioni che è l'elemento LCP, ma il testo sottostante cambia a ogni navigazione soft. Il caricamento iniziale della pagina contrassegnerà l'immagine del banner come elemento LCP e baserà la tempistica LCP su questo elemento. 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 la pagina viene caricata 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.

Allo stesso modo, un'animazione potrebbe aggiornare continuamente una parte della pagina, indipendentemente dalla navigazione soft. Eventuali nuovi paint dovuti all'animazione dello sfondo non verranno presi in considerazione per LCP per la nuova navigazione soft. Tuttavia, potrebbero essere presi in considerazione per LCP se la pagina è stata ricaricata da questo URL.

Come mostrano questi esempi, 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 per le navigazioni hard.

Come misurare il TTFB?

Il Time to First Byte (TTFB) per un caricamento di pagina convenzionale rappresenta il tempo necessario per restituire 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? 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 temporanee ed è quello che consigliamo per questa metrica al momento.

Devi misurare i Core Web Vitals con entrambe le metodologie?

Sebbene queste nuove API siano limitate ai browser basati su Chromium, i siti potrebbero voler misurare entrambi i tipi di navigazione suddividendo i dati in base alle navigazioni soft e continuando a suddividerli in base alle navigazioni hard. Ciò consentirebbe il confronto tra i browser e per le tendenze storiche.

Per LCP, ciò significa considerare solo le voci largest-contentful-paint per il metodo attuale e le voci largest-contentful-paint e interaction-contentful-paint per il nuovo metodo.

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

Le metriche dovrebbero quindi essere inviate e archiviate due volte per l'analisi.

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

Il modo più semplice per tenere conto di tutte le sfumature è utilizzare la libreria JavaScript web-vitals, che offre il supporto sperimentale per le navigazioni soft in un soft-navs branch separato (disponibile anche su npm e unpkg). Questa operazione può essere misurata 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';

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

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

La libreria web-vitals garantisce inoltre che le metriche vengano riportate in base all'URL corretto come indicato in precedenza, in quanto includono sia navigationId sia navigationURL nelle voci fornite al callback.

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

Queste modifiche faranno parte delle misurazioni di Core Web Vitals?

L'obiettivo finale è fornire un mezzo per misurare meglio il rendimento in base alle esperienze degli utenti reali. Quindi sì, l'obiettivo è includerli nelle misurazioni dei Segnali web essenziali, come esposto da tutti gli strumenti dopo il lancio dell'API.

Apprezziamo il feedback degli sviluppatori web sull'API 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, non è ancora stato stabilito con esattezza come verranno segnalate le navigazioni soft in CrUX una volta lanciata la funzionalità. Annunceremo le modifiche a CrUX non appena avremo maggiori informazioni da condividere qui.

Feedback

Stiamo attivamente raccogliendo feedback su questa API nei seguenti luoghi:

• Il feedback sull'API deve essere segnalato come problemi su GitHub.
• I bug nell'implementazione di Chromium devono essere segnalati nel tracker dei problemi di Chrome, se non si tratta ancora di uno dei problemi noti.
• Il feedback generale sui web vitals può essere condiviso all'indirizzo web-vitals-feedback@googlegroups.com.

In caso di dubbi, non preoccuparti troppo. Preferiamo ricevere il feedback in entrambi i casi e saremo felici di esaminare i problemi in entrambi i luoghi e reindirizzarli alla posizione corretta.

Log delle modifiche

Durante lo sviluppo di questa API, sono state apportate diverse modifiche, più che con le API stabili. Per ulteriori dettagli, consulta il log delle modifiche della navigazione soft.

Conclusione

La funzionalità Navigazioni soft è un approccio entusiasmante al modo in cui l'iniziativa Core Web Vitals potrebbe evolversi per misurare un pattern comune sul web moderno che manca nelle nostre metriche. Abbiamo raccolto numerosi feedback dalla community web più ampia e invitiamo vivamente le persone interessate a questo sviluppo a sfruttare questa opportunità per contribuire a modellare le API in modo che siano rappresentative di ciò che speriamo di poter misurare con queste.

Ringraziamenti

Immagine in miniatura di Jordan Madrid su Unsplash

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