Risposte alle domande più frequenti su SPA, Core Web Vitals e su come Core Web Vitals tratta questi elementi.
Data di pubblicazione: 14 settembre 2021, ultimo aggiornamento: 11 agosto 2026
Da quando abbiamo introdotto l'iniziativa Web Vitals nel maggio 2020, il team di Chrome ha ricevuto molte domande e feedback interessanti sul programma.
Forse l'argomento su cui abbiamo ricevuto più domande, che è anche probabilmente la domanda più difficile a cui rispondere, è come misurare Core Web Vitals in un' applicazione a pagina singola (SPA), nonché in che modo le architetture SPA influiscono sui punteggi di Core Web Vitals.
È difficile rispondere a queste domande perché il problema è piuttosto complesso, quindi in questo post faremo del nostro meglio per rispondere alle domande più comuni, fornendo il maggior numero possibile di dettagli e contesto.
Prima di entrare nei dettagli, è importante sottolineare che Google non ha alcuna preferenza in merito all'architettura o alla tecnologia utilizzata per creare un sito. Riteniamo che sia le SPA sia le applicazioni multipagina (MPA) siano in grado di offrire esperienze di alta qualità agli utenti e il nostro intento con l'iniziativa Web Vitals è fornire metriche che misurino l'esperienza indipendentemente dalla tecnologia.
Domande frequenti
Di seguito sono riportate alcune delle domande più frequenti che riceviamo su questo argomento. Siamo felici di ricevere feedback da aggiungere a queste domande frequenti nel nostro gruppo di feedback o aprendo un problema.
Le metriche di Core Web Vitals includono le transizioni di route SPA?
Al momento dell'introduzione, ciascuna delle metriche di Core Web Vitals veniva misurata rispetto alla navigazione della pagina di primo livello corrente. Se una pagina caricava dinamicamente nuovi contenuti e aggiornava l'URL della pagina nella barra degli indirizzi, ciò non avrebbe influito sulla misurazione delle metriche di Core Web Vitals.
I valori delle metriche non venivano reimpostati e l'URL associato a ogni misurazione delle metriche è l'URL a cui l'utente ha eseguito la navigazione che ha avviato il caricamento pagina.
Chrome 151 ha introdotto nuove API che consentono di misurare Core Web Vitals nelle transizioni di route SPA. Al momento della stesura (agosto 2026), queste API stanno iniziando a essere utilizzate nelle librerie di misurazione come web-vitals, nelle soluzioni RUM e negli strumenti come Chrome DevTools. Chrome non ha ancora pubblicato le tempistiche di integrazione di questi elementi nel Rapporto sull'esperienza utente di Chrome (CrUX). Inoltre, altri motori dei browser non supportano ancora queste nuove API, pertanto Core Web Vitals può essere misurato solo nei caricamenti di pagine complete per questi browser.
Perché è stato difficile risolvere questo problema?
Oggi non esiste un modo standardizzato per creare una SPA e, anche tra le librerie di routing e SPA più diffuse, l'esperienza utente può essere molto diversa da un'app all'altra:
- Alcune SPA aggiornano l'URL solo quando caricano nuovi contenuti "a pagina intera", mentre altri siti aggiornano l'URL per piccole modifiche dei contenuti o anche solo per modifiche dello stato dell'interfaccia utente.
- Alcune SPA aggiornano l'URL utilizzando l'API History, mentre altre utilizzano le modifiche dell'hash per supportare i browser meno recenti (e altre non aggiornano affatto l'URL).
- Alcune SPA caricano i contenuti e poi aggiornano l'URL, mentre altre aggiornano l'URL prima di caricare i contenuti.
- Alcune SPA caricano i contenuti tutti in una volta, in modo sincrono, in una singola attività JavaScript, mentre altre eseguono la transizione dei contenuti in modo asincrono, in più attività (senza un evento di fine transizione chiaro).
- Alcune SPA caricano sempre i contenuti dalla rete, mentre altre precaricano tutti i contenuti in anticipo in modo che le modifiche delle route vengano caricate istantaneamente dalla memoria.
Queste differenze rendono molto difficile definire e identificare ciò che costituisce una modifica della route SPA o anche una SPA stessa su larga scala.
In alcuni casi, una modifica della route SPA è logicamente identica a un caricamento di pagina MPA e, in questi casi, sarebbe ideale se le metriche di Core Web Vitals esistenti potessero essere applicate.
Tuttavia, senza euristiche solide per identificare in modo affidabile le modifiche delle route "reali" da tutte le altre modifiche degli URL, nonché indicatori chiari che contrassegnano l'inizio e la fine di queste transizioni, la generazione di report sulle metriche di Core Web Vitals in questi casi oscurerebbe i dati e li renderebbe meno utili o rappresentativi dell'esperienza utente reale sul sito.
Il lavoro sulle navigazioni soft ha fornito una soluzione a questo problema con due nuove API per il rendimento:
PerformanceSoftNavigation, che misura quando un'interazione dell'utente comporta sia un paint sia una modifica dell'URL. La combinazione di questi tre elementi fornisce una definizione standardizzata di "navigazione soft" indipendentemente dal framework utilizzato e da alcune delle differenze menzionate in precedenza. In questo modo, la sequenza temporale del rendimento può essere suddivisa in "navigazioni" separate, consentendo di misurare CLS e INP per ogni navigazione.InteractionContentfulPaint, che misura i "paint con contenuti" dopo un'interazione, consentendo di misurare FCP e LCP per queste navigazioni soft.
La combinazione di queste due API consente di misurare Core Web Vitals sia nei caricamenti di pagine complete sia nelle navigazioni soft.
Le modifiche delle route SPA sono uguali ai caricamenti di pagine complete per Core Web Vitals?
No, esistono ancora molte differenze tra questi tipi di navigazione, che possono comportare metriche di Core Web Vitals diverse.
Una navigazione soft ha contenuti sulla pagina e aggiorna alcuni o tutti i contenuti per visualizzare la nuova "pagina". Per molti aspetti, questa situazione è simile alla differenza tra un caricamento pagina completa senza cache e un caricamento pagina quando alcune o tutte le risorse della pagina sono memorizzate nella cache, ma in uno stato ancora più estremo, poiché alcuni contenuti potrebbero rimanere sottoposti a rendering.
In teoria, la differenza principale sarà la possibilità che le navigazioni soft siano molto più veloci. Tuttavia, esistono altre differenze più sottili.
Le nuove API di navigazione soft prendono in considerazione solo i nuovi contenuti. Pertanto, una pagina che aggiorna il contenuto di <h1> e il testo, ma lascia la stessa immagine hero tra le pagine, non considererà l'immagine hero come candidato LCP se non è stata eseguita una nuova pittura. Ciò comporterà differenze negli elementi utilizzati per calcolare il tempo LCP in base al fatto che la stessa pagina venga caricata come caricamento pagina completo o come navigazione soft da un'altra pagina esistente.
Allo stesso modo, INP potrebbe essere inferiore per le navigazioni soft, poiché gran parte del codice JavaScript necessario per eseguire il sito sarà già caricato. Allo stesso modo, una navigazione soft potrebbe avere un valore CLS inferiore (o superiore!) se gli stessi contenuti causano CLS in un caricamento pagina completa, ma non devono essere caricati o sottoposti a rendering in una navigazione soft.
Esistono anche lievi differenze nel momento in cui le misurazioni vengono effettuate nei caricamenti di pagine complete (misurate dopo l'elaborazione dell'interazione di navigazione) rispetto alle navigazioni soft (misurate dal tempo di inizio dell'interazione).
Come indicato in precedenza, molte di queste differenze sono simili a quelle tra pagine senza cache e pagine con cache e il concetto di ciò che Core Web Vitals tenta di misurare è ancora valido. Tuttavia, vale la pena comprendere queste sottigliezze quando si esaminano i problemi di Core Web Vitals.
È più difficile per le SPA ottenere buoni risultati in Core Web Vitals rispetto alle MPA?
Non esiste nulla di intrinseco nell'architettura SPA che impedisca a una pagina di una SPA di caricarsi altrettanto rapidamente e di ottenere un punteggio altrettanto buono in tutte le metriche di Core Web Vitals rispetto a una pagina simile in una MPA.
Tuttavia, le MPA ottimizzate correttamente presentano alcuni vantaggi nel soddisfare le soglie di Core Web Vitals che le SPA non hanno. Questo problema è stato in gran parte mitigato con il lavoro sulle navigazioni soft descritto in precedenza, ma potrebbe ancora verificarsi quando queste nuove API non vengono ancora utilizzate. Il motivo è che con l'architettura MPA, ogni "pagina" viene caricata come navigazione a pagina intera (anziché recuperare dinamicamente i contenuti e inserirli nella pagina esistente), il che significa che gli utenti che visitano una MPA hanno maggiori probabilità di caricare più di una pagina del sito, il che a sua volta significa che una percentuale maggiore della distribuzione di tutti i caricamenti di pagina per una MPA coinvolgerà alcune o tutte le risorse secondarie memorizzate nella cache.
Certo, affinché una MPA abbia un rendimento migliore nelle metriche di Core Web Vitals rispetto a una SPA, è necessario che si verifichino alcune condizioni:
- La MPA deve avere una memorizzazione nella cache delle risorse secondarie ottimizzata per garantire che i caricamenti di pagine della stessa origine siano effettivamente più veloci dei caricamenti di pagine multiorigine al 75° percentile.
- Gli utenti che visitano le MPA devono visitare più pagine affinché il sito riceva i vantaggi della memorizzazione nella cache che comportano caricamenti di pagina più rapidi.
Poiché le valutazioni di Core Web Vitals prendono in considerazione il 75° percentile delle visite di pagina, avere più visite di pagina con un buon rendimento nel set di dati aumenterà la probabilità che la visita al 75° percentile della distribuzione rientri nelle soglie consigliate.
Tieni presente che un aspetto importante da considerare quando si confrontano i punteggi di Core Web Vitals è la modalità di aggregazione dei dati, ovvero se il set di dati nella distribuzione include tutte le pagine del sito o dell'origine oppure solo i caricamenti di pagina per un URL di pagina specifico.
Quando si aggregano i punteggi di tutte le pagine di un'origine, le singole pagine veloci possono migliorare il 75° percentile per l'origine nel suo complesso. Tuttavia, quando si esegue l'aggregazione per singole pagine, i punteggi di una pagina non influiscono sui punteggi della pagina successiva. In altre parole, quando si aggregano i punteggi di una MPA per pagina, i caricamenti rapidi della cache visualizzati nella pagina di checkout non migliorano i punteggi dei caricamenti iniziali lenti riscontrati nella pagina di destinazione del sito.
Puoi controllare il punteggio del tuo sito per diversi metodi di aggregazione utilizzando PageSpeed Insights o l'API Rapporto sull'esperienza utente di Chrome, che segnala i punteggi sia per i singoli URL delle pagine sia per l'intera origine.
Un altro modo in cui l'architettura SPA può influire sui punteggi di Core Web Vitals è per le metriche che considerano l'intera durata di una pagina. Poiché gli utenti che visitano le SPA tendono a rimanere sulla stessa "pagina" per l'intera sessione, le metriche che si accumulano nel tempo possono essere più severe per le SPA rispetto alle MPA.
Con il lavoro sulle navigazioni soft, riteniamo che non dovrebbero esserci svantaggi per le SPA in termini di misurazione di Core Web Vitals. Tuttavia, l'integrazione completa di queste API in tutte le soluzioni di strumenti e report richiederà tempo.
Se le architetture SPA migliorano l'esperienza utente, questo miglioramento non dovrebbe riflettersi nelle metriche?
Sì, dovrebbe. Quantificare la misura in cui l'esperienza è migliorata è stato difficile su larga scala, dati tutti i modi diversi in cui le SPA vengono implementate oggi sul web. Ora abbiamo una soluzione al problema di misurazione e, quando vengono utilizzate queste nuove API, eventuali miglioramenti derivanti dal passaggio alle SPA dovrebbero riflettersi nelle metriche.
La verità è che il settore del rendimento web (incluso Google) non ha storicamente investito quasi altrettanto tempo e impegno nello sviluppo di metriche incentrate sull'utente per il rendimento post-caricamento di una pagina rispetto al caricamento della pagina stessa. Questo non perché il rendimento post-caricamento non sia importante, ma perché l'esperienza utente e le interazioni post-caricamento sono molto più varie e meno ben definite, il che rende difficile progettare metriche per loro.
Ma anche ora che abbiamo più metriche post-caricamento per misurare il rendimento delle SPA, non vogliamo ignorare l'esperienza di caricamento solo perché l'esperienza post-caricamento è migliorata.
Uno degli obiettivi dell'iniziativa Web Vitals è promuovere e incentivare le buone esperienze utente in quanti più aspetti possibili del caricamento e dell'utilizzo di una pagina web. Non vogliamo incoraggiare scenari in cui le esperienze negative sono giustificate se puoi avere abbastanza esperienze positive da compensarle. Gli utenti vogliono che le pagine si carichino rapidamente e che la transizione ai nuovi contenuti sia veloce e abbiamo cercato di progettare metriche che favoriscano questi tipi di esperienze.
Abbiamo eseguito la migrazione del nostro sito da una MPA a una SPA e i nostri punteggi sono peggiorati. È normale?
Dipende. Esistono diversi motivi per cui i punteggi potrebbero cambiare dopo una migrazione di architettura importante, ma una diminuzione del numero di caricamenti della cache calda potrebbe spiegare parte della modifica.
Un modo rapido per verificare è testare sia una versione MPA sia una versione SPA di una delle tue pagine di destinazione con Lighthouse. Se il punteggio di Lighthouse è inferiore in una delle metriche di Core Web Vitals per la versione SPA, è probabile che l'esperienza di caricamento sia peggiorata dopo l'aggiornamento.
Devo eseguire la migrazione del mio sito da una SPA a una MPA per ottenere un punteggio migliore in Core Web Vitals?
Probabilmente no. Dovresti passare da una SPA a una MPA solo se non sei soddisfatto dello stack SPA e hai motivo di ritenere che una MPA offrirà una migliore esperienza utente.
Con il lavoro sulle navigazioni soft, riteniamo di aver risolto i problemi di misurazione, quindi la migrazione per questo solo motivo non ha senso.
Tuttavia, se hai motivo di dimostrare che il rendimento migliorerà, anziché solo le misurazioni, allora potrebbe essere un motivo per passare da SPA a MPA (o viceversa).
Se i punteggi di Core Web Vitals vengono segnalati solo per le pagine di destinazione di una SPA, come posso eseguire il debug dei problemi che si verificano nelle "pagine" dopo una transizione di route?
Gli strumenti di Google che segnalano i dati sul campo per la metrica Core Web Vitals (come Search Console e PageSpeed Insights) ottengono i dati dal Rapporto sull'esperienza utente di Chrome (CrUX). CrUX aggrega i dati per origine o per URL della pagina (ovvero l'URL della pagina al tempo di caricamento).
Stiamo lavorando per consentire a CrUX di includere i dati per route SPA nei dati aggregati. Tuttavia, in qualità di proprietario del sito, ora puoi utilizzare le nuove API per misurare Core Web Vitals per route SPA in anticipo per capire come potrebbero cambiare i tuoi punteggi.
Per maggiori dettagli e best practice, consulta: Misurazione delle navigazioni soft.
Cosa sta facendo Google per garantire che le MPA non abbiano un vantaggio ingiusto rispetto alle SPA?
Come indicato in precedenza, con il lavoro sulle navigazioni soft, riteniamo che il lavoro che abbiamo intrapreso ora significhi che non dovrebbero esserci svantaggi per le SPA a questo proposito, anche se l'integrazione completa in tutte le soluzioni di strumenti e report richiederà tempo.
Valutare separatamente le visite di pagina multiorigine e della stessa origine
Oggi le metriche di Core Web Vitals aggregano tutte le visite di pagina in un unico bucket: non distinguono tra visite nuove e di ritorno, pagine di destinazione e pagine di pagamento o qualsiasi altro tipo di aggregazione in cui lo stato della cache potrebbe influire sul rendimento.
Un modo per normalizzare le differenze tra il rendimento di SPA e MPA è applicare una ponderazione diversa a diversi tipi di visite, potenzialmente anche con consigli di soglia completamente diversi.
Sebbene vogliamo sicuramente premiare le implementazioni efficaci della cache, non vogliamo che le navigazioni rapide all'interno del sito possano compensare i caricamenti lenti delle pagine di destinazione. Inoltre, non vogliamo incentivare i siti a suddividere le pagine lunghe in una raccolta di pagine più brevi solo per migliorare i punteggi delle metriche.
Valutando separatamente le visite di pagina multiorigine e della stessa origine, possiamo contribuire a garantire che entrambi i tipi di esperienze siano importanti senza che la popolarità relativa di un tipo su un determinato sito distorca la distribuzione di una metrica specifica.
Considerazioni finali
Google si impegna a fondo per migliorare le metriche di Web Vitals e garantire che misurino e incentivino esperienze di alta qualità importanti per gli utenti. Detto questo, riconosciamo che oggi esistono lacune nella misurazione. Le metriche sono ora in grado di coprire le transizioni di route SPA, il che risolve una delle principali lacune.
Riteniamo inoltre che queste nuove API (in particolare InteractionContentfulPaint) abbiano ulteriori utilizzi e potenziali vantaggi oltre alla misurazione di Core Web Vitals per le navigazioni soft. Siamo molto entusiasti di continuare a sviluppare questi elementi ora che è stato risolto il motivo principale della loro introduzione.
Spero che questo post ti abbia aiutato a fare luce su questo argomento complesso e sfumato. Come sempre, se hai feedback sulle metriche di Web Vitals attuali o future, invia un'email all'indirizzo web-vitals-feedback@googlegroups.com.