Risposte alle domande più frequenti su SPA, Core Web Vitals e sul piano di Google per risolvere le attuali limitazioni di misurazione.
Da quando abbiamo introdotto l'iniziativa Web Vitals a maggio 2020, noi del team di Chrome abbiamo ricevuto molte domande e feedback interessanti sul programma.
Forse l'argomento su cui abbiamo ricevuto più domande, nonché 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 di dettagli e contesto possibile.
Prima di entrare nei dettagli, però, è importante affermare che Google non ha preferenze in merito all'architettura o alla tecnologia utilizzata per creare un sito. Riteniamo che le applicazioni SPA e multipagina (MPA) siano entrambe in grado di offrire esperienze di alta qualità agli utenti e la nostra intenzione con l'iniziativa Web Vitals è fornire metriche che misurano l'esperienza indipendentemente dalla tecnologia. Anche se al momento non è possibile in tutti i casi (a causa di limitazioni della piattaforma web), ci stiamo adoperando attivamente per colmare queste lacune.
Domande frequenti
Le metriche di Core Web Vitals includono le transizioni di route SPA?
No. Ogni metrica di Core Web Vitals viene misurata in base alla navigazione corrente della pagina di primo livello. Se una pagina carica dinamicamente nuovi contenuti e aggiorna l'URL della pagina nella barra degli indirizzi, questo non influisce sulla misurazione delle metriche Core Web Vitals. I valori delle metriche non vengono reimpostati e l'URL associato a ogni misurazione della metrica è l'URL a cui l'utente ha eseguito la navigazione e che ha avviato il caricamento della pagina.
Le metriche di Core Web Vitals possono trattare le modifiche ai percorsi delle APS come i caricamenti di pagine tradizionali?
Purtroppo no. Non ancora, comunque.
Al momento non esiste un modo standardizzato per creare un'app SPA e, anche tra le raccolte 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 ai contenuti o anche solo per modifiche dello stato dell'interfaccia utente.
- Alcune APS aggiornano l'URL utilizzando l'API History, mentre altre utilizzano modifiche dell'hash per supportare i browser meno recenti (e altre ancora 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 contemporaneamente, in modo sincrono, in un'unica attività JavaScript, mentre altre trasferiscono i 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 alla route vengano caricate immediatamente dalla memoria.
Queste differenze rendono molto difficile definire e identificare ciò che costituisce un cambiamento di route di un'SPA o addirittura un'SPA stessa su larga scala.
In alcuni casi, una modifica del percorso dell'SPA è logicamente identica al caricamento di una pagina MPA e in questi casi sarebbe fantastico poter applicare le metriche Core Web Vitals esistenti.
Tuttavia, senza solide strategie di euristica per identificare in modo affidabile le modifiche "reali" del percorso da tutte le altre modifiche dell'URL, nonché indicatori chiari che ne segnalino l'inizio e la fine, la generazione di report sulle metriche Core Web Vitals in questi casi potrebbe confondere i dati e renderli meno utili o rappresentativi dell'esperienza utente reale sul sito.
È più difficile per le SPA ottenere buoni risultati in Core Web Vitals rispetto alle MPA?
Non c'è nulla nell'architettura delle APS che impedisca a una pagina di caricarsi con la stessa rapidità e di ottenere lo stesso punteggio in tutte le metriche di Core Web Vitals di una pagina simile in un'app MPA.
Tuttavia, le MPA ottimizzate correttamente hanno alcuni vantaggi nel soddisfare le soglie di Core Web Vitals che al momento non sono disponibili per le SPA. 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 un 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 pagine per un MPA comporterà la memorizzazione nella cache di alcune o di tutte le risorse secondarie.
È vero che, affinché un'app MPA abbia un rendimento migliore rispetto a un'app SPA per quanto riguarda le metriche di Core Web Vitals, è necessario che si verifichino alcune condizioni:
- L'MPA deve avere ottimizzato la memorizzazione nella cache delle risorse secondarie per garantire che i caricamenti delle pagine con la stessa origine siano effettivamente più rapidi rispetto ai caricamenti delle pagine con origini diverse al 75° percentile.
- Gli utenti che visitano gli MPA devono visitare più pagine affinché il sito possa beneficiare della memorizzazione nella cache, che consente di caricare le pagine più velocemente.
Poiché le valutazioni di Core Web Vitals prendono in considerazione il 75° percentile delle visite di pagina, avere un maggior numero di 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 è il modo in cui vengono aggregati i dati, ovvero se il set di dati nella distribuzione include tutte le pagine del tuo sito o della tua origine o solo i caricamenti di pagine per un determinato URL pagina.
Quando vengono aggregati i punteggi di tutte le pagine di un'origine, le singole pagine rapide possono migliorare il 75° percentile per l'origine nel suo complesso. Tuttavia, quando si aggrega per singole pagine, i punteggi di una pagina non influiscono su quelli della pagina successiva. In altre parole, quando vengono aggregati i punteggi di un MPA per pagina, i caricamenti rapidi della cache visualizzati nella pagina di pagamento non miglioreranno 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 Report sull'esperienza utente di Chrome, che riporta i punteggi sia per i singoli URL pagina sia per l'intera origine.
Un altro modo in cui l'architettura SPA può influire sui punteggi Core Web Vitals riguarda le metriche che prendono in considerazione l'intera durata di una pagina. Poiché gli utenti che visitano le SPA tendenzialmente rimangono nella stessa "pagina" per l'intera sessione, le metriche che si accumulano nel tempo possono essere più severe per le SPA rispetto alle MPA.
Ad aprile 2021 abbiamo annunciato modifiche alla metrica CLS che hanno risolto parzialmente il problema. In precedenza, il CLS si accumulava nell'intero ciclo di vita della pagina, mentre ora si accumula solo in un determinato intervallo di tempo, ovvero nell'esplosione peggiore di variazioni di layout in una determinata pagina.
Tuttavia, anche con la nuova definizione di CLS, le SPA sono ancora svantaggiate perché il valore CLS non viene "reimpostato " dopo una transizione di route come accade con i caricamenti completi della pagina in un'AMP. Ciò può anche creare confusione perché i cambiamenti di layout che si verificano dopo una transizione di percorso verranno attribuiti all'URL della pagina al momento del caricamento, non all'URL nella barra degli indirizzi al momento del cambiamento (maggiori dettagli di seguito).
Se le architetture SPA migliorano l'esperienza utente, questo miglioramento non dovrebbe essere riflesso nelle metriche?
Sì, dovrebbe. Tuttavia, come accennato in precedenza, è difficile quantificare l'entità del miglioramento dell'esperienza su larga scala, dati tutti i diversi modi in cui le APS vengono implementate oggi sul web.
La verità è che il settore del rendimento web (incluso Google) storicamente non ha impiegato molto tempo e impegno nello sviluppo di metriche incentrate sull'utente per il rendimento post-caricamento di una pagina, come ha fatto per il caricamento della pagina stessa. Non perché le prestazioni post-caricamento non siano importanti, 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 queste.
Tuttavia, anche se avessimo metriche post-caricamento ben definite per misurare il rendimento delle SPA, non vorremmo ignorare l'esperienza di caricamento solo perché l'esperienza post-caricamento è migliorata.
Uno degli obiettivi dell'iniziativa Web Vitals è promuovere e incentivare esperienze utente positive 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 per compensarle. Gli utenti vogliono che le pagine si carichino rapidamente e che la transizione ai nuovi contenuti sia altrettanto rapida. Abbiamo quindi cercato di progettare metriche che favoriscano questi tipi di esperienze.
Pertanto, sebbene sia vero che una versione MPA di un sito possa avere un rendimento migliore per le metriche Core Web Vitals al 75° percentile rispetto a una versione SPA dello stesso sito, la versione SPA dovrebbe comunque cercare di raggiungere la soglia "buona". Se la versione MPA non raggiunge la soglia "buona" per la maggior parte degli utenti, è probabile che l'esperienza di caricamento iniziale non sia ancora percepita come buona, anche se l'esperienza di navigazione in-page successiva è eccellente.
In futuro prevediamo di sviluppare metriche che incoraggino esperienze post-caricamento eccellenti e riteniamo che questo sia il percorso migliore per incentivare le APS di alta qualità in modo da non compromettere l'esperienza di caricamento iniziale. Abbiamo già fornito una nuova metrica denominata Interaction to Next Paint (INP) che misura la latenza di interazione durante l'intero ciclo di vita della pagina e stiamo lavorando attivamente anche su altre metriche post-caricamento, tra cui quelle che misurano le transizioni di route SPA (vedi di seguito).
Abbiamo passato il nostro sito da un MPA a un'SPA e i nostri punteggi sono peggiorati. È normale?
Dipende. Esistono diversi motivi per cui i punteggi potrebbero cambiare dopo una migrazione dell'architettura di grandi dimensioni, ma una diminuzione del numero di caricamenti della cache a caldo potrebbe spiegare in parte la variazione.
Un modo rapido per verificare è testare sia una versione MPA che una SPA di una delle tue pagine di destinazione con Lighthouse. Se il voto di Lighthouse è inferiore per una delle metriche Core Web Vitals per la versione SPA, è probabile che l'esperienza di caricamento sia peggiorata dopo l' aggiornamento.
Dovrei passare dal mio sito da un'applicazione SPA a un'applicazione MPA per ottenere un punteggio migliore in Core Web Vitals?
Probabilmente no. Passa da un'app SPA a un'app MPA solo se non sei soddisfatto del tuo stack SPA e hai motivo di ritenere che un'app MPA fornirà un'esperienza utente migliore.
Nel tempo, con il miglioramento delle metriche di Core Web Vitals e la copertura di una parte maggiore dell'esperienza di navigazione completa, i team con SPA ben strutturate che offrono un'esperienza utente eccezionale dovrebbero aspettarsi che i punteggi di Core Web Vitals riflettano questo aspetto.
Se i punteggi di Core Web Vitals vengono registrati solo per le pagine di destinazione di un'applicazione SPA, come faccio a eseguire il debug dei problemi che si verificano nelle "pagine" dopo una transizione di route?
Gli strumenti Google che registrano i dati sul campo per la metrica Core Web Vitals (come Search Console e PageSpeed Insights) li ricavano dal Report sull'esperienza utente di Chrome (CrUX). Inoltre, CrUX aggrega i dati in base all'origine o all'URL pagina (ovvero l'URL pagina al momento del caricamento).
Per tutti i motivi già elencati sopra, CrUX non è in grado di aggregare i dati in base al percorso dell'SPA. Tuttavia, in qualità di proprietario del sito che conosce la tua architettura, è possibile misurare questo valore autonomamente e molti strumenti di analisi ti consentono di indicare quando si verifica una modifica del percorso dell'SPA e aggiornano di conseguenza i dati di misurazione.
Quando misuri le metriche Web Vitals con uno strumento di analisi, assicurati di misurare sia l'URL percorso corrente sia l'URL pagina originale. In questo modo, potrai eseguire il debug dei singoli problemi che si verificano durante il ciclo di vita della pagina, nonché aggregare i dati in base all'URL della pagina originale per allinearti al modo in cui gli strumenti Google misurano e generano report sulle metriche.
Per ulteriori dettagli e best practice su questo argomento, consulta Eseguire il debug del rendimento sul campo.
Cosa fa Google per garantire che le MPA non abbiano un vantaggio sleale rispetto alle SPA?
Come accennato in precedenza, un MPA ottimizzato correttamente può, in alcuni casi, registrare punteggi Core Web Vitals migliori al 75° percentile perché probabilmente avrà una percentuale più elevata di visite di pagine memorizzate nella cache. Al contrario, i miglioramenti reali dell'esperienza utente nelle SPA ottimizzate correttamente non vengono attualmente rilevati da nessuna delle metriche di Core Web Vitals.
Google è consapevole che questo crea incentivi che non sono completamente in linea con gli obiettivi dell'iniziativa Web Vitals e sta cercando attivamente dei modi per risolvere il problema. Al momento stiamo valutando due potenziali soluzioni, una a breve termine e una a lungo termine:
- Valuta separatamente le visite alle pagine cross-origin e con la stessa origine.
- Progettare nuove API che consentano una misurazione migliore delle SPA.
Valutare separatamente le visite alle pagine cross-origin e same-origin
Attualmente le metriche Core Web Vitals aggregano tutte le visite alle pagine in un unico bucket: non distinguono tra visite nuove e di ritorno o tra 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 delle campagne SPA e MPA consiste nell'applicare un peso diverso ai diversi tipi di visite, potenzialmente anche con consigli di soglie completamente diversi.
Sebbene vogliamo 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 alle pagine cross-origin e dello stesso origin, possiamo contribuire a garantire che entrambi i tipi di esperienze siano importanti senza lasciare che la popolarità relativa di un tipo su un determinato sito distorca la distribuzione di una determinata metrica.
Progettare nuove API che consentano una misurazione migliore delle SPA
Un'altra soluzione su cui si sta lavorando attivamente (in parallelo a quanto sopra) è una nuova API App History, che contribuirebbe a standardizzare gli attuali pattern di SPA e a semplificare la misurazione e la comprensione dell'utilizzo delle SPA su larga scala.
L'API App History introduce un nuovo
evento navigate, che
ha due funzionalità chiave specifiche per la misurazione delle APS:
- Un
userInitiatedindicatore, che verrà impostato su true solo se la navigazione è stata avviata tramite un clic su un link, l'invio di un modulo o l'interfaccia utente Indietro o Avanti del browser. - Un metodo
transitionWhile()che accetta una promessa che consente allo sviluppatore di segnalare quando il lavoro avviato per eseguire la navigazione è completato.
Il flag userInitiated può essere utilizzato per determinare un punto di partenza semantico per la transizione di un percorso SPA, indicando l'intent dell'utente. La risoluzione della promessa transitionWhile() può aiutare il browser a correlare le paint con la transizione di percorso specifica, in modo da poter determinare la paint più grande con contenuti correlata a quella transizione.
Sulla base dell'idea presentata nella sezione precedente, potrebbe persino essere possibile aggregare il tempo di transizione del percorso SPA nello stesso bucket dei caricamenti di pagine con la stessa origine in un MPA. Questo è entusiasmante perché consentirebbe a un sito che esegue la migrazione da un MPA a un'SPA di confrontare effettivamente il rendimento prima e dopo.
Naturalmente, sono necessarie ulteriori ricerche prima di sapere se possiamo prendere queste decisioni con precisione. Se hai suggerimenti o feedback su queste proposte, invia un'email all'indirizzo web-vitals-feedback@googlegroups.com.
Considerazioni finali
Google si impegna a migliorare le metriche Web Vitals e a garantire che misurino e incentivino esperienze di alta qualità importanti per gli utenti. Detto questo, siamo consapevoli che al momento esistono lacune nella misurazione. Al momento le metriche non coprono tutti gli aspetti dell'esperienza utente, ma ci stiamo adoperando attivamente per colmare queste lacune.
Nonostante le limitazioni attuali, riteniamo che le aree coperte dalle metriche esistenti siano fondamentali per la salute e il successo del web e, nella misura in cui i siti (indipendentemente dall'architettura) non soddisfano le soglie consigliate, riteniamo che ci sia spazio di miglioramento.
Mi auguro che questo post abbia contribuito a fare chiarezza su questo argomento complesso e ricco di sfumature. Come sempre, se hai feedback sulle metriche Web Vitals attuali o future, invia un'email all'indirizzo web-vitals-feedback@googlegroups.com.