Data di pubblicazione: 31 lug 2025
A partire da Chrome 139, Chrome lancerà una nuova prova dell'origine per l'API Soft Navigations con cui abbiamo sperimentato in precedenza. Questa prova dell'origine consente ai siti di provare l'API sul proprio sito con utenti reali per testare sul campo l'API e fornire feedback al team di Chrome.
Che cosa sono le barre di navigazione virtuali?
Una navigazione soft si verifica quando JavaScript intercetta una navigazione (ad esempio, un clic su un link) e aggiorna i contenuti della pagina esistente, anziché caricare una nuova pagina. L'URL viene quindi aggiornato nella barra degli indirizzi (con uno stato della cronologia per consentire le navigazioni soft avanti e indietro). Per l'utente, queste navigazioni hanno lo stesso aspetto di quelle convenzionali, ma per il browser la pagina è ancora quella originale.
Perché è necessaria l'API Soft Navigation
L'API Soft Navigations è un'API proposta per consentire il rilevamento basato su euristica delle cosiddette "soft navigation" utilizzate dai siti Single Page Application (SPA). Poiché non si verifica alcuna navigazione effettiva della pagina per una navigazione soft, ciò significa che determinate azioni che normalmente si verificano per una navigazione devono essere gestite manualmente da JavaScript. Alcune azioni, come la gestione della cronologia di navigazione, sono possibili con le API attuali. Tuttavia, altre azioni, come la misurazione dei Segnali web essenziali, non sono possibili per queste navigazioni.
L'API Soft Navigation consente l'osservazione delle navigazioni soft. Mentre il codice JavaScript che avvia la navigazione temporanea (in genere un framework JavaScript) è consapevole di quando si verifica una navigazione, altri codici JavaScript e il browser stesso non lo sono.
Segnali web essenziali e SPA
Uno dei principali motivi per cui è stata creata l'API Soft Navigation è consentire la misurazione dei Core Web Vitals per le SPA. I Core Web Vitals vengono misurati sia dal browser (per essere visualizzati negli strumenti come il Report sull'esperienza utente di Chrome) sia dalle librerie JavaScript di Real User Monitoring (RUM).
I framework JavaScript potrebbero misurare alcuni aspetti dei Core Web Vitals. In particolare, Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS) si basano su primitive (rispettivamente l'API Event Timing e l'API Layout Instability) che possono essere misurate in qualsiasi intervallo di tempo per calcolare le metriche INP e CLS. Tuttavia, altre metriche come Largest Contentful Paint (LCP) vengono emesse solo dal browser in base alle navigazioni delle pagine e vengono finalizzate al momento dell'interazione.
In che modo l'API Soft Navigation consente la misurazione dei Segnali web essenziali per le SPA
La prima iterazione dell'API Soft Navigation ha accoppiato l'euristica della navigazione soft con un ripristino di LCP. Una volta reimpostato, LCP può essere riemesso per le navigazioni soft per la nuova pittura significativa, consentendo la misurazione di questa metrica per le navigazioni soft.
Questa ultima iterazione adotta un approccio diverso e separa questi concetti nell'API Soft Navigation e in una nuova voce di rendimento Interaction to Contentful Paint. La voce interaction-contentful-paint misura il "contentful paint" dopo le interazioni. Per ora, questo valore viene emesso solo per le navigazioni soft, ma apre altri potenziali casi d'uso oltre a LCP se abilitato per tutte le interazioni.
L'API ha anche espanso ogni voce di rendimento largest-contentful-paint, interaction-contentful-paint, event-timing e layout-shift per includere un identificatore per la navigazione della voce. Le voci relative al rendimento vengono emesse dopo l'evento che misurano, in genere durante il tempo di inattività. Ciò significa che l'URL sarà spesso cambiato al momento dell'emissione della voce relativa al rendimento. L'inclusione della navigazione con la voce semplifica notevolmente la misurazione dei Core Web Vitals per l'URL specificato, senza dover abbinare i tempi di inserimento delle prestazioni ai tempi di inserimento della navigazione soft.
Perché un'euristica?
L'API Soft Navigation considera una navigazione soft quando si verifica quanto segue:
- Si verifica un'interazione basata sull'utente (gli aggiornamenti degli URL senza interazione dell'utente non vengono conteggiati)
- … che comporta una modifica del DOM e un repaint
- … e si verifica un aggiornamento dell'URL
- Aggiornamento dell'URL, inclusa una modifica della cronologia.
L'API adotta questo approccio basato sull'euristica anziché consentire a un framework JavaScript di "emettere" una navigazione soft o di essere basata sull'API Navigation, in quanto ciò consente di comprendere in modo coerente cosa costituisce una navigazione soft indipendentemente dal framework o da come viene utilizzato da uno sviluppatore.
Framework o sviluppatori possono aggiornare l'URL per una navigazione soft anche senza un'interazione dell'utente o un aggiornamento del DOM che consideriamo ciò che un utente vedrebbe come navigazione. Potrebbero anche aggiornare l'URL in momenti diversi, all'inizio dell'interazione o solo alla fine, quando è completa, o in qualsiasi stato intermedio.
Anziché basarsi sulle scelte del framework, l'integrazione del rilevamento della navigazione soft nel browser stabilisce "euristiche" canoniche (con il tuo feedback di questa prova dell'origine) che ci consentiranno di misurare i Segnali web essenziali per le navigazioni soft su larga scala e di rendere queste misurazioni comparabili su larga scala.
I framework e gli sviluppatori possono anche ignorare l'euristica dell'API Soft Navigations e utilizzare le API Event Timing, Layout Instability e Interaction to Contentful Paint sottostanti per misurare le metriche di rendimento aggiuntive che preferiscono, ma consigliamo di utilizzare le Core Web Vitals con l'euristica per consentire la misurazione su più siti.
Assistenza necessaria per testare l'API Soft Navigation
Abbiamo bisogno di aiuto per testare l'API Soft Navigations per verificare se l'euristica corrisponde correttamente alle tue aspettative su quando si è verificata una navigazione soft. Esistono casi in cui l'API non segnala le navigazioni soft quando le consideri avvenute? Al contrario, l'API esegue il conteggio delle navigazioni ripetute che non consideri navigazioni temporanee?
Gli esempi che abbiamo riscontrato causare problemi includono l'aggiornamento di un URL con replaceState anziché l'aggiunta di una cronologia o quando si verifica una navigazione non avviata dall'utente (ad esempio, la disconnessione per timeout). Entrambi i casi sono spiegati dal mancato rispetto delle euristiche e il team di Chrome è d'accordo a non includerli, ma vogliamo sentire il parere degli sviluppatori web. In particolare, ci interessano i casi in cui le euristiche sembrano essere soddisfatte, ma l'API non riconosce comunque la navigazione soft.
Inoltre, vogliamo capire se questa API e la nuova primitiva Interaction to Contentful Paint risolvono il caso d'uso principale che consente la misurazione delle metriche Core Web Vitals per le SPA.
Vogliamo che l'API sia il più utile possibile e questo è molto più facile da fare prima del lancio e prima che i siti inizino a dipendere da un'implementazione. Pertanto, chiediamo agli sviluppatori di SPA e a chi è interessato a misurare le prestazioni web di questi siti di provare questa API e di farci sapere come funziona.
Come eseguire il test
L'API può essere testata localmente con flag o opzioni della riga di comando di Chrome. Inoltre, può essere testato sul campo con la prova dell'origine.
Per ulteriori dettagli tecnici sull'API, in particolare su come misurare le metriche Core Web Vitals, consulta la nostra documentazione o il repository GitHub. Inoltre, è disponibile una versione sperimentale della libreria web-vitals con navigazione soft.
Feedback
Stiamo cercando attivamente feedback su questo esperimento nei seguenti luoghi:
- Il feedback sull'API deve essere segnalato come problema 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 sulle metriche web può essere condiviso all'indirizzo web-vitals-feedback@googlegroups.com.
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.