L'API Soft Navigations di Chrome 151 permette finalmente alle single-page app (SPA) di riportare i Core Web Vitals per ogni navigazione all'interno dell'app, ma il dataset CrUX di Google registra ancora solo il primo caricamento "hard", lasciando gli sviluppatori con due scenari di performance divergenti.

Perché le metriche delle SPA sono rimaste indietro

I Core Web Vitals — Largest Contentful Paint (LCP), Interaction-to-Next-Paint (INP) e Cumulative Layout Shift (CLS) — sono stati definiti in relazione alle hard navigation. Una hard navigation recupera un documento completamente nuovo e scarta lo stato della pagina precedente.

Le SPA costruite con React, Vue, Next.js o framework simili attivano raramente hard navigation. Cliccare su un link aggiorna l'URL tramite la History API, recupera i dati in background e sostituisce il contenuto senza un ricaricamento completo. L'attuale Performance API cattura solo il caricamento iniziale della pagina, quindi LCP e INP non rilevano mai la latenza che gli utenti percepiscono quando si spostano da una rotta all'altra.

Questo punto cieco altera le dashboard che estraggono dati dalla Performance Timeline o dal Chrome User Experience Report (CrUX) di Google. Spesso mostrano un LCP eccellente per la pagina "shell", ignorando i caricamenti più lenti nelle parti più profonde dell'app, fornendo così una falsa percezione della salute delle performance.

L'API Soft Navigations di Chrome

Chrome 151 ha introdotto la Soft Navigations API, un insieme di euristiche che trattano determinate interazioni delle SPA come vere e proprie navigazioni. L'API monitora tre segnali:

  • Un'interazione avviata dall'utente (click, tap, evento da tastiera)
  • Un cambiamento dell'URL tramite la History API
  • Eventi di paint successivi che renderizzano nuovi contenuti

Quando tutti e tre i segnali coincidono, Chrome registra una soft navigation nella Performance Timeline, e i Core Web Vitals vengono calcolati per quella transizione esattamente come per una hard navigation. La libreria open-source web-vitals ha aggiunto il supporto il 21 luglio, permettendo agli sviluppatori di iniziare a estrarre questi dati utilizzando la stessa API che già utilizzano.

In pratica, ora è possibile visualizzare un valore LCP per ogni cambio di rotta, un INP che riflette la reale latenza dell'ultimo input dell'utente e un CLS che cattura i layout shift dopo una soft navigation.

La divisione dei dati: Chrome vs. CrUX

Il CrUX (Chrome User Experience Report) di Google alimenta PageSpeed Insights, Search Console e, indirettamente, i segnali di ranking. CrUX aggrega ancora solo i dati relativi alle hard navigation.

Di conseguenza, ci si ritrova con due flussi di dati coerenti ma differenti:

  • Gli strumenti interni che leggono la Performance Timeline mostrano ora LCP, INP e CLS a livello di rotta, offrendo una visione realistica di ciò che gli utenti sperimentano in una SPA.
  • I dataset pubblici di Google continuano a mostrare le metriche solo per il primo caricamento della pagina, ovvero ciò che riporta Search Console e ciò a cui fanno riferimento gli algoritmi di ranking di Google.

Entrambi sono corretti; misurano semplicemente momenti diversi. Affidarsi esclusivamente a Search Console può mascherare regressioni delle performance che avvengono dopo il caricamento iniziale, mentre le sole dashboard interne non rifletteranno il baseline utilizzato da Google per la SEO.

Cosa devono monitorare gli sviluppatori

  • Supporto del browser – Oggi la Soft Navigations API è disponibile solo nei browser basati su Chromium. Safari e Firefox non hanno un equivalente, quindi è necessario mantenere una logica di fallback per una parte del proprio pubblico.
  • Limiti euristici – L'API decide se si tratta di una soft navigation in base a un insieme di segnali. Se l'app aggiorna il contenuto senza cambiare l'URL (ad esempio, overlay modali o scroll infinito), l'API potrebbe non rilevare tali transizioni, lasciando lacune nei dati.
  • Testare prima di fidarsi – Poiché il rilevamento è euristico, esegui una serie di interazioni nel mondo reale sulla tua app e confronta le metriche riportate con una misurazione manuale (ad esempio, usando performance.mark). Solo dopo aver confermato l'accuratezza dovresti basare le decisioni di ottimizzazione sui nuovi dati.

In sintesi

Chrome 151 offre agli sviluppatori di SPA la tanto attesa capacità di misurare LCP, INP e CLS per ogni cambio di rotta all'interno dell'app, ma i dati di ranking di Google riflettono ancora solo il primo caricamento "hard". Finché CrUX non si allineerà, i team dovranno gestire due set di dati paralleli: uno che racconta la vera esperienza dell'utente e un altro che guida il posizionamento nelle ricerche. Bilanciare entrambi — e prepararsi a un supporto browser più ampio — sarà fondamentale per mantenere SPA orientate alle performance in un ecosistema web competitivo.