Pubblicato il 31 luglio 2025
A partire da Chrome 139, Chrome lancerà una nuova prova dell'origine per l'API Navigazioni soft con cui abbiamo sperimentato in precedenza. Questa prova dell'origine consente ai siti di provare l'API sul proprio sito con utenti reali per testarla sul campo e fornire feedback al team di Chrome.
Che cosa sono le navigazioni soft?
Una navigazione soft si verifica quando JavaScript intercetta una navigazione (ad esempio, facendo clic su un link) e aggiorna i contenuti della pagina esistente, anziché caricare una nuova pagina, e poi l'URL viene aggiornato nella barra degli indirizzi (con uno stato della cronologia per consentire le navigazioni soft avanti e indietro). Per l'utente, queste navigazioni sono identiche a quelle convenzionali, ma per il browser la pagina è ancora quella originale.
Perché è necessaria l'API Navigazioni soft
L'API Navigazioni soft è un'API proposta per consentire il rilevamento basato su euristiche delle cosiddette "navigazioni soft" utilizzate dai siti di applicazioni a pagina singola (SPA). Poiché per una navigazione soft non si verifica una navigazione di pagina effettiva, ciò significa che alcune 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 Core Web Vitals, non sono possibili per queste navigazioni.
L'API Navigazioni soft consente di osservare le navigazioni soft. Sebbene JavaScript che avvia la navigazione soft (in genere un framework JavaScript) sia a conoscenza di quando si verifica una navigazione, altri JavaScript e il browser stesso non lo saranno.
Core Web Vitals e SPA
Uno dei principali motivi per cui è stata creata l'API Navigazioni soft è 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 Chrome User Experience Report) sia dalle librerie JavaScript di monitoraggio degli utenti reali (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 (l'API Event Timing e l'API Layout Instability rispettivamente) che possono essere misurate in qualsiasi periodo di tempo per calcolare le metriche INP e CLS. Tuttavia, poiché il browser segnala e finalizza Largest Contentful Paint (LCP) in base alle navigazioni e alle interazioni delle pagine, i framework JavaScript non hanno visibilità su altro se non sulle prestazioni di caricamento iniziali per le SPA.
In che modo l'API Navigazioni soft consente la misurazione dei Core Web Vitals per le SPA
La prima iterazione dell'API Navigazioni soft ha accoppiato l'euristica delle navigazioni soft con una reimpostazione di LCP. Dopo la reimpostazione, LCP può essere riemesso per le navigazioni soft per il nuovo paint con contenuti, consentendo la misurazione di questa metrica per le navigazioni soft.
Questa ultima iterazione adotta un approccio diverso e disaccoppia questi concetti nell'API Navigazioni soft e in una nuova voce di prestazioni Interaction to Contentful Paint. La voce interaction-contentful-paint misura il "paint con contenuti" dopo le interazioni. Per il momento, questa voce viene emessa solo per le navigazioni soft, ma se abilitata per tutte le interazioni, apre altri potenziali casi d'uso oltre a LCP.
L'API ha anche espanso ciascuna delle voci di prestazioni largest-contentful-paint, interaction-contentful-paint, event-timing e layout-shift per includere un identificatore della navigazione a cui si riferisce la voce. Le voci di prestazioni vengono emesse dopo l'evento che misurano, in genere durante il tempo di inattività. Ciò significa che l'URL spesso sarà cambiato quando viene emessa la voce di prestazioni. L'inclusione della navigazione nella voce semplifica notevolmente la misurazione dei Core Web Vitals per l'URL specificato senza dover abbinare i tempi delle voci di prestazioni ai tempi delle voci di navigazione soft.
Perché un'euristica?
L'API Navigazioni soft considera una navigazione soft quando si verifica quanto segue:
- Si verifica un'interazione basata sull'utente (gli aggiornamenti degli URL senza un'interazione dell'utente non vengono conteggiati)
- … che comporta una modifica del DOM e un paint
- … e si verifica un aggiornamento dell'URL
- Aggiornamento dell'URL, inclusa una modifica della cronologia.
L'API adotta questo approccio basato su euristiche anziché consentire a un framework JavaScript di "emettere" una navigazione soft o di essere basata sull'API Navigation, in quanto consente una comprensione coerente di ciò che costituisce una navigazione soft indipendentemente dal framework o dal modo in cui uno sviluppatore la utilizza.
I framework o gli 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 una navigazione. Possono anche aggiornare l'URL in momenti diversi: all'inizio dell'interazione o solo alla fine, quando è completa, o in qualsiasi stato intermedio.
Anziché fare affidamento sulle scelte del framework, l'integrazione del rilevamento delle navigazioni soft nel browser stabilisce "euristiche" canoniche (con il tuo feedback di questa prova dell'origine) che ci consentiranno di misurare i Core Web Vitals per le navigazioni soft su larga scala e di rendere tali misurazioni comparabili su larga scala.
I framework e gli sviluppatori possono anche ignorare l'euristica dell'API Navigazioni soft e utilizzare le API sottostanti Event Timing, Layout Instability e Interaction to Contentful Paint per misurare le metriche sul rendimento aggiuntive come preferiscono, ma consigliamo di utilizzare i Core Web Vitals utilizzando l'euristica per consentire la misurazione tra i siti.
Aiuto necessario per testare l'API Navigazioni soft
Abbiamo bisogno del tuo aiuto per testare l'API Navigazioni soft 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 ripete le navigazioni che non consideri navigazioni soft?
Gli esempi che abbiamo visto causare problemi includono quando un URL viene aggiornato con replaceState anziché aggiungere una cronologia o quando si verifica una navigazione non avviata dall'utente (ad esempio, un logout in caso di timeout). Entrambi i casi sono spiegati dal fatto che non corrispondono all'euristica e il team di Chrome è a suo agio con la mancata inclusione di questi casi, ma vogliamo sapere se gli sviluppatori web sono d'accordo. In particolare, vogliamo sapere se ci sono casi in cui l'euristica sembra essere soddisfatta, ma l'API non riconosce comunque la navigazione soft.
Inoltre, vogliamo capire se questa API e la nuova primitiva Interaction to Contentful Paint soddisfano il caso d'uso principale di consentire la misurazione dei Core Web Vitals per le SPA.
Vogliamo che l'API sia il più utile possibile e questo è molto più facile prima del lancio e prima che i siti inizino a dipendere da un'implementazione. Pertanto, chiediamo agli sviluppatori di SPA e a coloro che sono interessati alla misurazione delle prestazioni web per questi siti di provare questa API e di comunicarci come funziona.
Come eseguire il test
L'API può essere testata localmente con i flag di Chrome o le opzioni della riga di comando. Inoltre, può essere testata sul campo con la prova dell'origine.
Per ulteriori dettagli tecnici sull'API, in particolare su come misurare i Core Web Vitals, consulta la nostra documentazione o il repository GitHub. Inoltre, è disponibile una versione sperimentale di navigazione soft della libreria web-vitals.
Feedback
Stiamo cercando attivamente feedback su questo esperimento nei seguenti luoghi:
- I feedback sull'API devono essere segnalati 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.
- I feedback generali sui Segnali web essenziali possono essere condivisi 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.