Misurare le navigazioni soft

Barry Pollard

Michal Mocny

Data di pubblicazione: 1° febbraio 2023, Ultimo aggiornamento: 20 settembre 2026

Sin 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 al modo in cui gli utenti percepivano le prestazioni della pagina. 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 delle applicazioni a pagina singola non è mai stata completamente supportata dalle metriche di Core Web Vitals. Anziché caricare pagine web distinte e singole 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 ai pulsanti Indietro e Avanti di funzionare come l'utente si aspetta.

Molti framework JavaScript utilizzano questo modello, ma ognuno in modo diverso. Poiché questo non rientra in ciò che il browser tradizionalmente intende per "pagina", misurarlo è sempre stato difficile: dove tracciare il confine tra un'interazione sulla pagina corrente e considerarla come 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 parziale" 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.

Abbiamo apportato diversi miglioramenti alla proposta in base al feedback degli sviluppatori e abbiamo lanciato due nuove API per le prestazioni per contribuire a risolvere questo problema a partire da Chrome 151. Inoltre, abbiamo reso disponibili le metriche di navigazione soft nel Chrome User Experience Report (CrUX) come metriche sperimentali.

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 dell'URL visibile all'utente.
• L'interazione genera un paint visibile.

Per alcuni siti, questa definizione potrebbe portare a falsi positivi (gli utenti non considererebbero effettivamente che sia avvenuta una "navigazione ") o falsi negativi (l'utente considera che sia avvenuta una "navigazione" nonostante non soddisfi questi criteri). Accogliamo con favore i feedback nel repository delle specifiche di navigazione flessibile.

Supporto di DevTools per le navigazioni soft

Abbiamo aggiunto il supporto per le navigazioni soft al riquadro Prestazioni di DevTools nella visualizzazione Metriche in tempo reale e nella visualizzazione della traccia con il supporto di Approfondimenti e indicatori:

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

Una volta attivata la funzionalità di navigazione parziale (maggiori informazioni nella sezione successiva), Chrome cambierà il modo in cui genera i report su alcune metriche sul rendimento:

• Un evento soft-navigation PerformanceTiming verrà emesso dopo il rilevamento di ogni navigazione parziale.
• Questa voce soft-navigation includerà un navigationId, il nuovo URL nell'attributo name e un interactionId dell'interazione iniziale.
• Una o più voci interaction-contentful-paint verranno emesse dopo le interazioni che causano un Contentful Paint. Contiene una voce largestContentfulPaint che può essere utilizzata per misurare il Largest Contentful Paint (LCP) per le navigazioni soft.
• L'attributo navigationId viene aggiunto a ciascuna delle tempistiche di 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 emesso 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. Per saperne di più, consulta la sezione Segnala le 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 può essere utilizzato come LCP iniziale per la navigazione e può essere aggiornato man mano che vengono osservate più voci interaction-contentful-paint per l'interazione. Tieni presente che questo attributo sostituisce un attributo largestInteractionContentfulPaint disponibile negli origin trial precedenti.
• È possibile che alcune voci interaction-contentful-paint siano state registrate prima della navigazione parziale (se l'aggiornamento dell'URL non avviene fino a dopo questi paint). In questi casi, la funzione getLargestInteractionContentfulPaint() evita di dover eseguire il buffering e di dover esaminare le voci precedenti dopo la finalizzazione di una navigazione di tipo soft. Tieni presente che la voce restituita da getLargestInteractionContentfulPaint() è una copia esatta della voce interaction-contentful-paint più grande al momento della sua emissione, pertanto la voce potrebbe aver utilizzato il navigationId precedente, poiché è il momento in cui è avvenuto il paint, ma questi paint devono essere misurati rispetto al nuovo navigationId.
• La voce soft-navigation includerà anche paintTime e presentationTime come FCP per la navigazione.
• Tieni presente che le voci interaction-contentful-paint verranno emesse anche dopo ulteriori interazioni, ma l'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 suo interno.

Queste modifiche consentiranno di misurare i Core Web Vitals e alcune delle metriche di diagnostica associate per ogni navigazione nelle pagine, 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 relative alle prestazioni in ogni "navigazione".
• Le metriche CLS e INP possono già essere suddivise a tua discrezione, anziché essere misurate per l'intera durata del ciclo di vita della pagina, ma la funzionalità Soft Navigation fornisce una misura standardizzata di quando ciò accade, indipendentemente dalla tecnologia di base 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 questo non cambierà quando vengono misurate le navigazioni soft, quindi l'LCP per il caricamento pagina iniziale, con navigazione hard, può essere misurato come sempre.
• La nuova voce interaction-contentful-paint che verrà emessa dalle interazioni può essere utilizzata per misurare l'LCP per le navigazioni soft esaminando la proprietà largestContentfulPaint al suo interno, ma ci sono alcune considerazioni su come utilizzare questa voce che discuteremo in questo articolo.
• Tieni presente che non tutti gli utenti supporteranno questa funzionalità di navigazione soft, in particolare quelli che utilizzano altri browser o versioni di Chrome precedenti alla 151. Tieni presente che alcuni utenti potrebbero non segnalare metriche basate sulla navigazione flessibile, anche se segnalano metriche di Core Web Vitals.

Verifica con il tuo provider RUM se supporta la misurazione di Core Web Vitals tramite navigazione parziale. Molti stanno pianificando 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?

La funzionalità di navigazione parziale è attivata per impostazione predefinita a partire da Chrome 151.

Rilevamento delle funzionalità del supporto dell'API Soft Navigations

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

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

In alternativa:

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

Come posso misurare le navigazioni soft?

Se supportate, le metriche possono essere registrate utilizzando l'API PerformanceObserver come per le altre metriche. Tuttavia, esistono alcune considerazioni aggiuntive da tenere presenti per queste metriche.

Segnala le navigazioni soft

Puoi utilizzare un PerformanceObserver per osservare le navigazioni soft. Di seguito è riportato uno snippet di codice di esempio che registra le voci di navigazione parziale nella console, incluse le navigazioni parziali 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 della navigazione precedente.

Generare report sulle metriche in base all'URL appropriato

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

L'attributo name della voce soft-navigation appropriata conterrà il nuovo URL per cui generare i report sulle metriche e navigationId sarà il riferimento univoco per questa navigazione (poiché lo stesso URL potrebbe essere visitato più volte nel corso della durata di un'applicazione a pagina singola).

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 ulteriori considerazioni, poiché non tutte le voci interaction-contentful-paint devono essere mappate utilizzando navigationId e registrate come LCP per quell'URL:

• Il primo problema è che le voci interaction-contentful-paint potrebbero essere emesse prima della navigazione di tipo soft se si verifica un paint prima dell'aggiornamento dell'URL. In questi casi, il navigationId sarà relativo al vecchio URL. Se l'URL viene aggiornato per primo, il paint 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 le voci interaction-contentful-paint continueranno a essere emesse per le interazioni più recenti, poiché l'ambito di questa metrica sul rendimento va oltre l'LCP per le navigazioni di tipo soft. Vogliamo prendere in considerazione solo i paint per il caricamento della navigazione flessibile per LCP e non quelli per le interazioni successive.

Pertanto, per mappare le voci interaction-contentful-paint a soft-navigation-entries e 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 prima elaborare la funzione getLargestInteractionContentfulPaint() delle voci soft-navigation per gestire le voci interaction-contentful-paint che si sono verificate prima dell'emissione di soft-navigation entries.

Ottenere il startTime delle 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 un tempo rispetto al tempo di navigazione iniziale "hard" della pagina. Pertanto, l'ora di inizio della navigazione soft deve essere sottratta dai tempi delle metriche di caricamento della navigazione soft (ad esempio LCP), per registrarli 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 complete", in cui l'"ora di inizio" è il momento in cui la nuova pagina viene "confermata" nel browser e dopo l'esecuzione di parte del codice del gestore di eventi. Anche le ore di inizio della navigazione soft includono il codice del gestore di eventi, poiché la misurazione viene eseguita a partire dall'ora di inizio dell'interazione.

Misura i Core Web Vitals per la navigazione parziale

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

Le metriche LCP, INP e CLS possono quindi essere misurate e monitorate come di consueto (con l'eccezione dell'utilizzo di interaction-contentful-paint per LCP, a condizione che interactionId corrisponda). interactionId può essere utilizzato per assegnare un nome alle voci di un URL, come descritto in precedenza.

Le tempistiche verranno comunque restituite in relazione all'ora di inizio della navigazione "hard" originale. Quindi, per calcolare l'LCP per una navigazione parziale, ad esempio, dovrai prendere la tempistica interaction-contentful-paint e sottrarre l'ora di inizio della navigazione parziale appropriata, come descritto in precedenza, per ottenere una tempistica relativa alla navigazione parziale.

Alcune metriche sono state tradizionalmente misurate per tutta la durata della pagina: LCP, ad esempio, può cambiare fino a quando non si verifica un'interazione. CLS e INP possono essere aggiornati fino a quando non si esce dalla pagina, indipendentemente dalle interazioni. Pertanto, le metriche della navigazione precedente devono essere finalizzate quando si verifica ogni nuova navigazione parziale. 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 si inizia a misurare le metriche per la nuova navigazione parziale 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. In altre parole, la comprensione di ciò che è il paint "più grande", l'Interaction to Next Paint o la variazione del layout viene reimpostata per consentire di misurare di nuovo da zero.

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

LCP per le navigazioni software (calcolato da interaction-contentful-paint) misurerà solo i nuovi paint e solo i paint associati all'interazione che ha causato la navigazione. Ciò può comportare un LCP diverso da un caricamento completo di quella navigazione parziale a un caricamento parziale.

Ad esempio, prendi una pagina che include un'immagine del banner di grandi dimensioni che è l'elemento LCP, ma il testo sottostante cambia con ogni navigazione parziale. Il caricamento pagina iniziale contrassegnerà l'immagine del banner come elemento LCP e baserà su questo il tempo LCP. 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 deep link nell'URL della navigazione parziale, l'immagine del banner sarà un nuovo paint e, pertanto, potrà essere considerata come l'elemento LCP.

Analogamente, un'animazione potrebbe aggiornare continuamente parte della pagina, indipendentemente da qualsiasi navigazione parziale che si verifica. Eventuali nuovi paint dovuti all'animazione di sfondo non verranno presi in considerazione per l'LCP della nuova navigazione parziale. Tuttavia, potrebbero essere presi in considerazione per l'LCP se la pagina è stata ricaricata da questo URL.

Come mostrano questi esempi, l'elemento LCP per la navigazione parziale può essere registrato in modo diverso a seconda di come viene caricata la pagina, allo stesso modo in cui il caricamento di una pagina con un link di ancoraggio più in basso nella pagina può comportare un elemento LCP diverso per le navigazioni complete.

Come si misura il TTFB?

Il Time to First Byte (TTFB) per un caricamento pagina convenzionale rappresenta il tempo necessario per la restituzione dei 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 esistono già nell'app e non ci sono richieste aggiuntive? E se la richiesta viene effettuata in anticipo con un precaricamento? 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 e quello che consigliamo per questa metrica al momento.

Dovresti misurare i Core Web Vitals con entrambe le metodologie?

Sebbene queste nuove API siano limitate solo ai browser basati su Chromium, i siti potrebbero voler misurare entrambe le metriche suddividendole per navigazioni soft e continuando a suddividerle per navigazioni hard. In questo modo, sarebbe possibile effettuare un confronto tra i browser e 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 nell'intero ciclo di vita della pagina, come avviene attualmente, e suddividere separatamente la sequenza temporale in base alle navigazioni parziali per misurare valori CLS e INP separati per la nuova.

Le metriche dovrebbero quindi essere segnalate 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 supporta le navigazioni soft a partire dalla versione 6.0.0. Questo 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';

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 registrate per l'URL corretto, come indicato in precedenza, poiché includono sia navigationId che navigationURL nelle voci fornite al callback.

La libreria web-vitals segnala le seguenti metriche per le navigazioni soft:

Queste modifiche diventeranno parte delle misurazioni di Core Web Vitals?

L'obiettivo finale è fornire un mezzo per misurare meglio le prestazioni in base alle esperienze degli utenti reali. Quindi sì, l'obiettivo è includerli nelle misurazioni di Core Web Vitals, come mostrato da tutti gli strumenti dopo il lancio dell'API.

Come verranno registrate le navigazioni soft in CrUX?

Abbiamo lanciato versioni sperimentali delle metriche Core Web Vitals in CrUX. Questi terminano le metriche CLS e INP di "navigazione completa" dopo la prima navigazione parziale e includono anche misure LCP, CLS e INP aggiuntive per ogni navigazione parziale. Prevediamo di trasformare queste metriche sperimentali in metriche stabili a maggio 2027. Per saperne di più, consulta il blog post Metriche sperimentali di navigazione soft ora disponibili in CrUX.

Come gestire le navigazioni soft in altri browser?

Le navigazioni soft sono difficili da rilevare in modo programmatico nei browser che non supportano l'API, motivo per cui abbiamo lavorato su questa API.

È possibile utilizzare l'API Navigation per monitorare le modifiche degli URL, il che potrebbe consentire di suddividere l'INP per URL (e analogamente il CLS, anche se al momento è solo per Chromium, quindi non verrebbe misurato comunque). Tuttavia, questo non risolve il problema delle metriche di visualizzazione (FCP e LCP), che possono essere solo approssimate.

Allo stesso tempo, riteniamo che gli insight offerti da questa API siano troppo preziosi per essere ignorati, sia per misurare i tempi delle navigazioni parziali sia per attribuire le metriche alla navigazione corretta. Ti consigliamo di utilizzare questa nuova API nonostante la mancanza di supporto cross-browser al momento. Come è successo con il lancio di Core Web Vitals, i problemi identificati e le soluzioni per le prestazioni probabilmente influiranno su tutti i browser, anche se per ora la visibilità è limitata ai soli browser basati su Chromium.

Continueremo a lavorare al processo di standardizzazione e a collaborare con gli altri fornitori di browser per dimostrare l'importanza di questa API.

Feedback

Stiamo attivamente cercando feedback su questa API nei seguenti canali:

• Il feedback sull'API deve essere segnalato come problema su GitHub.
• I bug relativi all'implementazione di Chromium devono essere segnalati nell'Issue Tracker di Chrome, se non sono ancora tra i problemi noti.
• Il feedback generale su 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 posti e saremo felici di valutare i problemi in entrambi i posti e di reindirizzarli alla posizione corretta.

Log delle modifiche

Durante lo sviluppo di questa API, sono state apportate diverse modifiche, più di quante ne vengano apportate alle API stabili. Per maggiori dettagli, consulta il log delle modifiche delle navigazioni soft.

Conclusione

La funzionalità Soft Navigations è un approccio entusiasmante al modo in cui l'iniziativa Core Web Vitals potrebbe evolversi per misurare un pattern comune sul web moderno che non è presente nelle nostre metriche. Abbiamo raccolto un feedback considerevole dalla community web più ampia e siamo incoraggiati dal potenziale di questa API.

Ringraziamenti

Immagine in miniatura di Jordan Madrid su Unsplash

Questo lavoro è una continuazione del lavoro iniziato da Yoav Weiss quando era in Google. Ringraziamo Yoav per il suo impegno su questa API.