Risposte alle domande comuni su SPA, Core Web Vitals e piano di Google per affrontare gli attuali limiti di misurazione.
Dalla prima introduzione dell'iniziativa Web Vitals a maggio 2020, il team di Chrome ha ricevuto molte domande e feedback utili in merito al programma.
Forse l'argomento su cui abbiamo ricevuto più domande, probabilmente la domanda più difficile a cui rispondere, è come misurare i Segnali web essenziali in un'applicazione di una sola pagina (SPA) e come le architetture SPA influiscono sui punteggi di Segnali web essenziali.
Queste domande sono difficili da rispondere perché il problema presenta varie sfumature, pertanto in questo post faremo del nostro meglio per rispondere alle domande più comuni, fornendo il maggior numero di dettagli e contesto possibile.
Prima di scendere nel dettaglio, è importante sottolineare che Google non ha alcuna preferenza riguardo a quale architettura o tecnologia viene utilizzata per creare un sito. Riteniamo che le APS e le applicazioni con più pagine (MPA) siano in grado di offrire esperienze di alta qualità agli utenti, pertanto l'iniziativa Web Vitals intende fornire metriche che misurino l'esperienza in modo indipendente dalla tecnologia. Anche se al momento non è possibile in tutti i casi (a causa delle limitazioni della piattaforma web), stiamo lavorando attivamente per colmare queste lacune.
Domande frequenti
Le metriche di Core Web Vitals includono le transizioni delle route SPA?
No. Ogni metrica di Segnali web essenziali viene misurata in base all'attuale navigazione nelle pagine di primo livello. Se una pagina carica dinamicamente nuovi contenuti e aggiorna l'URL della pagina nella barra degli indirizzi, il modo in cui vengono misurate le metriche di Core Web Vitals non influirà su come vengono misurate le metriche di Core Web Vitals. I valori delle metriche non vengono reimpostati e l'URL associato a ogni misurazione è l'URL a cui è stato indirizzato l'utente che ha avviato il caricamento pagina.
Le metriche di Segnali web essenziali possono trattare le modifiche ai percorsi SPA come i tradizionali caricamenti pagina?
Purtroppo no. Non ancora, comunque.
Attualmente non esiste un modo standardizzato di creare un'SPA e, anche tra le popolari librerie SPA e di routing, l'esperienza utente può essere molto diversa da un'app all'altra:
- Alcune APS aggiornano l'URL solo quando vengono caricati nuovi contenuti a pagina intera, mentre altri siti aggiornano l'URL per piccole modifiche ai contenuti o anche solo per modifiche allo stato dell'interfaccia utente.
- Alcune APS aggiornano l'URL utilizzando l'API History, mentre altre utilizzano modifiche di hash per supportare browser meno recenti (altre non aggiornano affatto l'URL).
- Alcune APS caricano i contenuti e quindi 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 eseguono la transizione dei contenuti, in modo asincrono, tra più attività (senza un chiaro evento di fine della transizione).
- Alcune APS caricano sempre contenuti dalla rete, mentre altre precaricano tutti i contenuti in anticipo in modo che le modifiche al percorso vengano caricate istantaneamente dalla memoria.
Queste differenze rendono molto difficile la definizione e l'identificazione di ciò che costituisce una modifica di percorso dell'APS, o anche di una SPA stessa, molto difficile da fare su larga scala.
In alcuni casi, una modifica di route SPA è logicamente identica al caricamento di una pagina MPA e, in questi casi, sarebbe fantastico se potessero essere applicate le metriche esistenti di Core Web Vitals.
Tuttavia, senza una solida euristica per identificare in modo affidabile le modifiche di route "reale" da tutte le altre modifiche agli URL, oltre a indicatori chiari che indicano l'inizio e la fine di queste transizioni, la generazione di report sulle metriche di Segnali web essenziali in questi casi potrebbe confondere i dati e li renderebbe meno utili o rappresentativi dell'esperienza utente reale sul sito.
È più difficile per le SPA avere un buon rendimento in Segnali web essenziali rispetto agli MPA?
Non c'è nulla di intrinseco nell'architettura SPA che potrebbe impedire il caricamento rapido di una pagina in un'APS (e lo stesso punteggio in tutte le metriche di Segnali web essenziali) di una pagina simile in un'MPA.
Tuttavia, gli MPA ottimizzati correttamente presentano alcuni vantaggi nel raggiungere le soglie dei Core Web Vitals che attualmente non sono presenti nelle APS. Il motivo è che con l'architettura MPA ogni "pagina" viene caricata come una 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 dal sito, il che significa che una percentuale maggiore della distribuzione di tutti i caricamenti di tutte le pagine per una MPA coinvolge parte o tutte le risorse secondarie memorizzate nella cache.
Certo, affinché un'MPA possa funzionare meglio nelle metriche di Segnali web essenziali rispetto a un'APS, deve soddisfare i seguenti requisiti:
- L'MPA deve avere la memorizzazione nella cache delle sottorisorse ottimizzata per garantire che i caricamenti delle pagine della stessa origine siano effettivamente più veloci rispetto ai caricamenti di pagine multiorigine al 75° percentile.
- Gli utenti che visitano gli MPA devono visitare più pagine per far sì che il sito riceva i vantaggi della memorizzazione nella cache che velocizzano i caricamenti delle pagine.
Poiché le valutazioni di Segnali web essenziali prendono in considerazione il 75° percentile di visite alle pagine, aumentare il numero di visite alle pagine con un buon rendimento nel set di dati aumenterà la probabilità che la visita al 75° percentile della distribuzione rispetti le soglie consigliate.
Tieni presente che un aspetto importante da considerare quando confronti i punteggi di Segnali web essenziali è il modo in cui i dati vengono aggregati, ovvero se il set di dati nella distribuzione include tutte le pagine del tuo sito o della tua origine oppure solo il caricamento delle pagine per un determinato URL di pagina.
Quando aggreghi i punteggi di tutte le pagine in un'origine, le singole pagine rapide possono migliorare il 75° percentile per l'origine nel suo complesso. Tuttavia, se aggreghi i dati per singole pagine, i punteggi di una pagina non influiscono su quelli delle pagine successive. In altre parole, quando aggreghi i punteggi di un MPA per pagina, i caricamenti veloci della cache visualizzati nella pagina di pagamento non migliorano i punteggi dei caricamenti iniziali lenti che si verificano sulla pagina di destinazione del sito.
Puoi controllare il punteggio del tuo sito per diversi metodi di aggregazione utilizzando PageSpeed Insights o l'API Chrome User Experience Report, che registra 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 dei Segnali web essenziali è per le metriche che considerano l'intera durata di una pagina. Poiché gli utenti che visitano le APS tendono a rimanere sulla stessa "pagina" per l'intera sessione, le metriche che si accumulano nel tempo possono essere più severe per le APS rispetto agli MPA.
Ad aprile 2021 abbiamo annunciato modifiche alla metrica CLS che hanno risolto in parte questo problema. In precedenza, il CLS si accumulava sull'intera durata della pagina, mentre ora si accumula solo in una finestra di tempo specifica, ovvero in pratica la peggiore serie di variazioni di layout in una determinata pagina.
Tuttavia, anche con la nuova definizione CLS, le APS sono ancora svantaggiate perché il valore CLS non viene "resettato" dopo la transizione di una route come avviene con il caricamento a pagina intera in un MPA. Questo può anche creare confusione, perché le variazioni del layout che si verificano dopo una transizione di route verranno attribuite all'URL della pagina al momento del caricamento, non a quello nella barra degli indirizzi al momento dello spostamento (maggiori dettagli di seguito).
Se le architetture degli SPA migliorano l'esperienza utente, questo miglioramento non dovrebbe riflettersi nelle metriche?
Sì. Sebbene, come accennato in precedenza, quantificare i miglioramenti dell'esperienza su larga scala, visti tutti i diversi modi in cui oggi vengono implementate le APS sul web,
La verità è che il settore delle prestazioni web (Google incluso) storicamente non ha investito lo stesso tempo e lo stesso impegno nello sviluppo di metriche incentrate sull'utente per le prestazioni post-caricamento di una pagina rispetto a quelle in termini di questo stesso caricamento. Ciò non è dovuto al fatto che le prestazioni post-caricamento non sono importanti, ma perché l'esperienza utente e le interazioni post-caricate sono molto più variegate e meno definite, il che rende difficile progettare metriche per loro.
Tuttavia, anche se disponevamo di metriche post-caricamento ben definite per misurare le prestazioni SPA, non vorremmo ignorare l'esperienza di caricamento solo perché quest'ultima è migliorata.
Uno degli obiettivi dell'iniziativa Web Vitals è promuovere e incentivare esperienze utente positive nel maggior numero possibile di aspetti del caricamento e dell'utilizzo di una pagina web. Non vogliamo incoraggiare scenari in cui le esperienze negative sono giustificate, se si può avere esperienze abbastanza positive per rimediare. Gli utenti vogliono che le pagine si carichino velocemente e passino rapidamente ai nuovi contenuti. Abbiamo provato a progettare metriche che favoriscano questo tipo di esperienze.
Quindi, anche se è vero che una versione MPA di un sito può avere un rendimento migliore nelle metriche di Core Web Vitals al 75° percentile rispetto a una versione SPA dello stesso sito, la versione SPA deve comunque cercare di soddisfare la soglia "buona". Se la versione SPA non soddisfa la soglia "buona " per la maggior parte degli utenti, è probabile che l'esperienza di caricamento iniziale non sia ancora percepita come buona, anche se la successiva esperienza di navigazione in-page è eccellente.
In futuro, prevediamo di sviluppare metriche che favoriscano esperienze straordinarie dopo il caricamento e riteniamo che questo sia il modo migliore per incentivare offerte di prodotto di alta qualità, senza compromettere l'esperienza di caricamento iniziale. Abbiamo già pubblicato una nuova metrica denominata Interaction to Next Paint (INP) che misura la latenza dell'interazione durante l'intero ciclo di vita della pagina e stiamo lavorando attivamente anche su altre metriche post-caricamento, incluse metriche che misurano le transizioni delle route SPA (vedi di seguito).
Abbiamo cambiato il nostro sito da MPA a SPA e i nostri punteggi sono regrediti. È previsto che sia così?
Dipende. Esistono diversi motivi per cui i punteggi potrebbero cambiare dopo una migrazione di grandi dimensioni dell'architettura, ma una diminuzione del numero di caricamenti della cache a caldo potrebbe determinare una parte del cambiamento.
Un modo rapido per controllare è testare sia una versione MPA che una versione SPA di una delle tue pagine di destinazione con Lighthouse. Se il punteggio di Lighthouse è più basso per una qualsiasi delle metriche di Segnali web essenziali per la versione SPA, è probabile che l'esperienza di caricamento sia peggiorata dopo l'aggiornamento.
Devo passare da una SPA a un MPA per ottenere un punteggio migliore in Segnali web essenziali?
Probabilmente no. Dovresti passare da un'APS a un'MPA solo se non sei soddisfatto dello stack SPA e hai motivo di ritenere che un MPA fornirà una migliore esperienza utente.
Nel corso del tempo, man mano che le metriche di Segnali web essenziali migliorano e coprono maggiormente l'esperienza di navigazione completa, i team con SPA ben strutturate che offrono un'ottima esperienza utente dovrebbero aspettarsi di vedere che i loro punteggi di Segnali web essenziali riflettono questa caratteristica.
Se i punteggi di Segnali web essenziali vengono registrati solo per le pagine di destinazione di un'APS, come posso eseguire il debug dei problemi che si verificano sulle "pagine" dopo una transizione di percorso?
Gli strumenti di Google che segnalano i dati dei campi per la metrica Core Web Vitals (come Search Console e PageSpeed Insights) ricevono i dati dal Report sull'esperienza utente di Chrome (CrUX). Inoltre, CrUX aggrega i dati per origine o per URL della pagina (ovvero l'URL della pagina al momento del caricamento).
Per tutti i motivi già elencati sopra, CrUX non è in grado di aggregare i dati per route SPA. Tuttavia, in qualità di proprietario di un sito che conosce la tua architettura, puoi misurarlo autonomamente e molti strumenti di analisi ti permettono di segnalare quando si verifica una modifica del percorso SPA e aggiornare i dati di misurazione di conseguenza.
Quando misuri le metriche di Web Vitals con uno strumento di analisi, assicurati di misurare sia l'URL di percorso corrente sia l'URL della pagina originale. Ciò ti consentirà di eseguire il debug di singoli problemi che si verificano durante il ciclo di vita della pagina e di aggregare i dati in base all'URL della pagina originale al fine di creare corrispondenze con il modo in cui gli strumenti di Google misurano e generano report sulle metriche.
Per ulteriori dettagli e best practice su questo argomento, consulta: Eseguire il debug delle prestazioni nel campo.
Che cosa sta facendo Google per garantire che le MPA non abbiano un vantaggio sleale rispetto alle APS?
Come già accennato, in alcuni casi un MPA ottimizzato correttamente può registrare punteggi migliori dei Segnali web al 75° percentile in quanto avrà probabilmente una percentuale più alta di visite di pagine memorizzate nella cache. Al contrario, nessuna delle metriche di Core Web Vitals non rileva miglioramenti reali dell'esperienza utente nelle SPA correttamente ottimizzate.
Google riconosce che ciò crea incentivi non completamente in linea con gli obiettivi dell'iniziativa Web Vitals, e stiamo cercando attivamente di risolvere questo problema. Al momento stiamo esplorando due potenziali soluzioni, una a breve e una a più lungo termine:
- Valuta separatamente le visite alle pagine multiorigine e della stessa origine.
- Progetta nuove API che consentano una misurazione SPA migliore.
Valutare separatamente le visite alle pagine multiorigine e della stessa origine
Attualmente, le metriche di Segnali web essenziali aggregano tutte le visite alle pagine in un unico bucket, non fanno distinzione tra visite nuove o di ritorno o pagine di destinazione rispetto alle pagine di pagamento o qualsiasi altro tipo di aggregazione in cui lo stato della cache potrebbe avere un impatto sulle prestazioni.
Un modo per normalizzare le differenze tra il rendimento di SPA e MPA consiste nell'applicare una ponderazione diversa a diversi tipi di visite, potenzialmente anche con consigli sulle soglie completamente diversi.
Sebbene desideriamo premiare le implementazioni efficaci della cache, non vogliamo che le navigazioni rapide all'interno del sito siano in grado di coprire 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 multiorigine e della stessa origine, 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 distingua la distribuzione di qualsiasi metrica specifica.
Progettare nuove API che consentano una migliore misurazione SPA
Un'altra soluzione su cui stiamo lavorando attivamente (Parallelamente a quanto sopra) è una nuova API App History, che aiuterebbe a standardizzare gli attuali pattern 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 SPA:
- Un flag
userInitiated, che viene 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 in avanti del browser. - Un metodo
transitionWhile()che garantisce allo sviluppatore di segnalare il completamento dell'operazione avviata per eseguire la navigazione.
Il flag userInitiated può essere utilizzato per determinare un punto di partenza semantico per una transizione di route SPA, indicando un chiaro intent dell'utente. La risoluzione della promessa di transitionWhile() può aiutare il browser a correlare le visualizzazioni con la transizione della route specifica, in modo da poter determinare la visualizzazione con contenuti più grande relativa a questa transizione.
Sulla base dell'idea presentata nella sezione precedente, potrebbe anche essere possibile aggregare il tempo di transizione delle route SPA nello stesso bucket del caricamento di una pagina della stessa origine in un MPA. È entusiasmante perché permette a un sito che migra da un'MPA a un'APS di confrontare il rendimento prima e dopo.
Naturalmente, sono necessarie ulteriori ricerche per sapere se siamo in grado di effettuare queste valutazioni in modo accurato. Per eventuali suggerimenti o feedback su queste proposte, invia un'email all'indirizzo web-vitals-feedback@googlegroups.com.
Considerazioni finali
Google si impegna a fondo per migliorare le metriche di Segnali web e garantire che misurino e incentivino esperienze di alta qualità importanti per gli utenti. Detto questo, siamo consapevoli che oggi esistono lacune nella misurazione. Al momento le metriche non coprono ogni aspetto dell'esperienza utente, ma stiamo lavorando attivamente per colmare queste lacune.
Nonostante i limiti attuali, riteniamo che le aree acquisite tramite le metriche esistenti siano fondamentali per l'integrità e il successo del web e, nella misura in cui i siti (indipendentemente dall'architettura) non soddisfano le soglie consigliate, riteniamo che ci sia un margine di miglioramento.
Spero che questo post ti sia stato utile per far luce su questo argomento complesso e articolato. Come sempre, se hai feedback sulle metriche attuali o future di Segnali web, invia un'email all'indirizzo web-vitals-feedback@googlegroups.com.