In che modo le architetture SPA influiscono sui Segnali web essenziali

Risposte alle domande comuni su APS, Core Web Vitals e sul piano di Google per risolvere gli attuali limiti di misurazione.

Philip Walton

Yoav Weiss

Dal lancio dell'iniziativa Web Vitals a maggio 2020, abbiamo del team di Chrome abbiamo ricevuto molte domande e feedback interessanti sul .

Forse l'argomento su cui abbiamo ricevuto più domande, ed è la domanda più difficile a cui rispondere è: come misurare i Core Web Vitals in applicazione su una sola pagina (APS), nonché il modo in cui le architetture SPA influiscono sui punteggi di Core Web Vitals.

È difficile rispondere a queste domande perché il problema è piuttosto articolato, in questo post faremo del nostro meglio per rispondere alle domande più comuni, fornendo quanti più dettagli e contesto possibile.

Prima di entrare nei dettagli, però, è importante sottolineare che Google non hanno alcuna preferenza su quale architettura o tecnologia vengono utilizzate per creare un sito. Riteniamo che le APS e le applicazioni multipagina (MPA) siano in grado di di offrire esperienze di alta qualità agli utenti e la nostra intenzione, con il Web, L'iniziativa Vitals ha lo scopo di fornire metriche che misurino l'esperienza in modo indipendente della tecnologia. Sebbene oggi ciò non sia possibile in ogni caso (a causa limitazioni della piattaforma web), stiamo lavorando attivamente alla chiusura lacune.

Domande frequenti

Le metriche di Core Web Vitals includono le transizioni delle route SPA?

No. Ogni metrica di Core Web Vitals viene misurata in base ai parametri attuali, navigazione nelle pagine di primo livello. Se una pagina carica in modo dinamico nuovi e aggiorna l'URL della pagina nella barra degli indirizzi, non avrà impatto sulle modalità di misurazione delle metriche Core Web Vitals. I valori delle metriche non sono e l'URL associato a ogni misurazione della metrica è l'URL si è indirizzato a che ha avviato il caricamento della pagina.

Le metriche Core Web Vitals possono trattare le modifiche delle route SPA allo stesso modo dei caricamenti delle pagine tradizionali?

Purtroppo no. Non ancora.

Attualmente, non esiste un modo standardizzato per costruire una SPA, e nemmeno librerie di routing e SPA molto note, l'esperienza utente può essere molto diversa da un'app all'altra:

• Alcune SPA aggiornano l'URL solo al caricamento della nuova "pagina intera" contenuti, mentre Altri siti aggiornano l'URL per piccole modifiche ai contenuti o anche solo per lo stato dell'interfaccia utente modifiche.
• Alcune SPA aggiornano l'URL utilizzando l'API History, mentre altre utilizzano hash modifiche per supportare browser meno recenti (e altri non aggiornano l'URL ).
• Alcune APS caricano i contenuti e poi aggiornano l'URL, mentre altre aggiornano l'URL. prima di caricare i contenuti.
• Alcune APS caricano i contenuti contemporaneamente, in modo sincrono, in un unico codice JavaScript mentre altri eseguono la transizione dei contenuti in modo asincrono. attività (senza un chiaro evento di fine della transizione).
• Alcune APS caricano sempre i contenuti dalla rete, mentre altre precaricano tutti contenuti in anticipo in modo che le modifiche al percorso si carichino all'istante dalla memoria.

Queste differenze ci aiutano a definire e identificare ciò che costituisce un percorso SPA modifiche o addirittura un'APE in sé, molto difficili da implementare su larga scala.

In alcuni casi, una modifica della route SPA è logicamente identica al caricamento di una pagina MPA. e, in questi casi, sarebbe l'ideale se le metriche di Core Web Vitals esistenti dell'applicazione.

Tuttavia, senza una solida euristica per identificare in modo affidabile "reale", modifiche al percorso da tutte le altre modifiche all'URL, nonché segnali chiari che indicano l'inizio e la fine transizioni di questo tipo; in questi casi, la segnalazione delle metriche di Core Web Vitals sarebbe falsata i dati e li rendi meno utili o rappresentativi dell'esperienza utente reale. sul sito.

È più difficile per le APS avere un buon rendimento in Core Web Vitals rispetto agli MPA?

Non c'è nulla di intrinseco nell'architettura SPA che impedirebbe a una pagina a un'APS di caricare altrettanto rapidamente e ottenere ottimi risultati su tutte le piattaforme Metriche Web Vitals, come una pagina simile in un MPA.

Tuttavia, le MPA adeguatamente ottimizzate hanno alcuni vantaggi nel soddisfare le esigenze del Soglie di vitals che attualmente le SPA non soddisfano. Il motivo è che con l'MPA architettura, ogni "pagina" viene caricato come una navigazione a pagina intera (anziché recuperando i contenuti in modo dinamico e inserendoli nella pagina esistente), significa che gli utenti che visitano un'MPA hanno maggiori probabilità di caricare più di una pagina dal sito, il che a sua volta significa che una percentuale maggiore della distribuzione di tutti caricamenti di pagine per una MPA coinvolgeranno alcune o tutte le risorse secondarie memorizzati nella cache.

Concesso, affinché un MPA possa avere un rendimento migliore in base alle metriche Core Web Vitals rispetto a un'APS richiede che siano soddisfatte le seguenti condizioni:

• L'MPA deve ottimizzare la memorizzazione nella cache delle sottorisorse per garantire i caricamenti di pagine dalla stessa origine sono effettivamente più veloci di quelli multiorigine 75° percentile.
• Gli utenti che visitano gli MPA devono visitare più pagine affinché il sito possa i vantaggi della memorizzazione nella cache che comportano un caricamento delle pagine più rapido.

Poiché le valutazioni Core Web Vitals prendono in considerazione il 75° percentile della pagina di visite, la presenza nel set di dati di più visite alle pagine con un buon rendimento aumenterà la probabilità che la visita al 75° percentile della distribuzione entro le soglie consigliate.

Tieni presente che un aspetto importante da considerare quando si confrontano i punteggi di Core Web Vitals è 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 o solo i caricamenti di pagine di un particolare dell'URL della pagina di destinazione.

Quando aggrega i punteggi di tutte le pagine in un'origine, le singole pagine veloci possono migliorare il 75° percentile dell'origine nel suo complesso. Tuttavia, quando aggreghi per singole pagine, i punteggi di una pagina non influiscono sui punteggi dei a questo punto. In altre parole, quando aggreghi i punteggi di un'MPA per pagina, i caricamenti nella pagina di pagamento non miglioreranno il punteggio iniziale carichi sperimentati sulla destinazione del sito .

Puoi controllare il punteggio del tuo sito per diversi metodi di aggregazione utilizzando PageSpeed Insights oppure il Report sull'esperienza utente di Chrome l'API, che riporta i punteggi sia per i singoli URL di pagina sia per l'intera origine.

Un altro modo in cui l'architettura SPA può influire sui punteggi di Core Web Vitals è per metriche che considerano l'intera durata di una pagina. Dato che gli utenti che visitano le APS tendono a rimanere sulla stessa "pagina" per l'intera sessione, le metriche che si accumulano nel tempo può essere più dura sulle APS rispetto agli MPA.

Ad aprile 2021 abbiamo annunciato modifiche alla metrica CLS che, ha risolto parzialmente il problema. In precedenza, la metrica CLS si accumulava nelle l'intera durata della pagina, mentre ora si accumula solo in una finestra specifica nel tempo: in pratica la peggiore serie di variazioni del layout in una determinata pagina.

Tuttavia, anche con la nuova definizione di CLS, le APS sono ancora svantaggiate perché il valore CLS non si "reimposta" dopo che un percorso passa come con caricamenti di pagine intere in un'MPA. Questo può creare confusione anche perché il layout le variazioni che si verificano dopo una transizione del percorso verranno attribuite all'URL del pagina al momento del caricamento, non l'URL nella barra degli indirizzi al momento del passaggio (ulteriori dettagli qui sotto).

Se le architetture SPA migliorano l'esperienza utente, questo miglioramento non dovrebbe riflettersi nelle metriche?

Sì, certamente. Anche se, come accennato in precedenza, quantificare quanto è migliorata ed è difficile da fare su larga scala, date tutte le diverse le modalità attuali di implementazione delle APS sul web.

La verità è che il settore del rendimento web (inclusa Google) storicamente non ha hanno investito quasi lo stesso tempo e impegno nello sviluppo di soluzioni incentrate sull'utente metriche per le prestazioni post-caricamento di un così come appare per la pagina caricata. Il motivo non è che il post-caricamento le prestazioni non sono importanti, ma perché le interazioni e l'esperienza utente post-caricamento sono molto più diversificate e meno definite, rendendo difficile la progettazione delle metriche per che li rappresentano.

Ma anche se avevamo metriche post-caricamento ben definite per misurare l'APS del rendimento, non vogliamo ignorare l'esperienza di caricamento solo perché l'esperienza di post-caricamento è migliorata.

Uno degli obiettivi dell'iniziativa Web Vitals è la promozione e l'incentivazione di esperienze utente in tutti gli aspetti del caricamento e dell'utilizzo di una pagina web quanti possibile. Non vogliamo incoraggiare scenari in cui sono presenti esperienze negative giustificato se si possono avere esperienze abbastanza buone da compensarle. Utenti vogliamo che le pagine si carichino rapidamente e passino a nuovi contenuti velocemente. Abbiamo provato progettare metriche che favoriscono questi tipi di esperienze.

Quindi, anche se è vero che la versione MPA di un sito potrebbe avere un rendimento migliore sul Core Web Metriche Vitals al 75° percentile rispetto a una versione SPA delle stesse sito, la versione SPA deve comunque fare il possibile per soddisfare i requisiti soglia. Se La versione SPA non soddisfa i requisiti soglia per la maggior parte degli utenti, il valore l'esperienza di caricamento non viene comunque percepita come buona, anche se le l'esperienza di navigazione in-page è eccellente.

In futuro prevediamo di sviluppare metriche che incoraggino un rendimento ottimale e crediamo che questo sia il percorso migliore per incentivare i contenuti APS in modo da non compromettere l'esperienza di caricamento iniziale. Abbiamo già distribuito una nuova metrica denominata Interaction to Next Paint (INP) che misura la latenza dell'interazione durante l'intero ciclo di vita della pagina, mentre stiamo lavorando attivamente su altre anche le metriche post-caricamento, incluse quelle che misurano le transizioni delle route SPA (vedi sotto).

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 notevole migrazione dell'architettura, ma una diminuzione del numero di caricamenti della cache a caldo potrebbero spiegare alcuni di questi cambiamenti.

Un modo rapido per controllare consiste nel testare sia la versione MPA che quella SPA di uno dei tuoi pagine di destinazione con Lighthouse. Se Il punteggio Lighthouse è più basso in tutte le metriche Core Web Vitals per l'APS della versione precedente, è probabile che l'esperienza di caricamento sia peggiorata dopo aggiornamento.

Devo passare da un'APS a un MPA per avere un punteggio migliore su Core Web Vitals?

Probabilmente no. Dovresti passare da un'APS a un MPA solo se non sei soddisfatto con il tuo stack SPA e hai motivo di credere che un'MPA offrirà un'esperienza un'esperienza utente positiva.

Nel tempo, man mano che le metriche Core Web Vitals migliorano e coprono una parte più ampia dell'intero di navigazione, i team con SPA ben costruite che forniscono un'ottima UX devono si aspettano che i punteggi di Core Web Vitals rispecchino questa situazione.

Se i punteggi Core Web Vitals vengono riportati solo per le pagine di destinazione di un'APS, come posso eseguire il debug dei problemi che si verificano sulle "pagine" dopo un cambio di percorso?

Strumenti Google che segnalano dati dei campi per la metrica Core Web Vitals (come Ricerca Console e PageSpeed Insights) traggono i propri dati dall'esperienza utente di Chrome Segnala (CrUX). E CrUX aggrega i dati per origine o per URL della pagina (ovvero, dell'URL della pagina al momento del caricamento).

Per tutti i motivi già elencati sopra, CrUX non è in grado di aggregare i dati in base a Via SPA. Tuttavia, in quanto proprietario di un sito che conosce bene la tua architettura, è possibile misurarlo autonomamente e molti strumenti di analisi consentono di segnale quando cambia il percorso della SPA e aggiorna la misurazione i dati di conseguenza.

Quando misuri le metriche di Web Vitals con uno strumento di analisi, assicurati di misura sia l'URL del percorso corrente sia l'URL della pagina originale. In questo modo consentono di eseguire il debug di singoli problemi che si verificano nella pagina del ciclo di vita e di aggregarli per URL della pagina originale in modo che corrispondano al modo in cui Google di misurazione e report sulle metriche.

Per ulteriori dettagli e best practice su questo argomento, consulta: Esegui il debug del rendimento nel campo.

Cosa sta facendo Google per garantire che le MPA non abbiano un vantaggio sleale rispetto alle APS?

Come accennato in precedenza, un'MPA correttamente ottimizzata può, in alcuni casi, generare report migliori Web Vitals al 75° percentile perché probabilmente hanno una percentuale più alta di visite alle pagine memorizzate nella cache. Al contrario, i miglioramenti reali al momento non viene acquisita l'esperienza utente nelle APS ottimizzate correttamente in base a una qualsiasi delle metriche Core Web Vitals.

Noi di Google siamo consapevoli che ciò crea incentivi che non rispecchiano del tutto con gli obiettivi dell'iniziativa Web Vitals e stiamo cercando attivamente modi per risolvere il problema. Al momento stiamo esplorando due potenziali soluzioni, una a breve termine e uno più lungo:

1. Valuta separatamente le visite alle pagine multiorigine e della stessa origine.
2. Progetta nuove API che consentano una migliore misurazione SPA.

Valutare separatamente le visite alle pagine multiorigine e della stessa origine

Attualmente, le metriche Core Web Vitals aggregano tutte le visite alle pagine in un'unica di destinazione: non distinguono tra visite nuove e visite di ritorno o visite di destinazione tra pagine e pagine di pagamento o qualsiasi altro tipo di aggregazione in cui si trova lo stato della cache ciò potrebbe influire sul rendimento.

Un modo per normalizzare le differenze tra le prestazioni SPA e MPA è applicare una ponderazione diversa ai diversi tipi di visite, potenzialmente anche con soglia completamente diversa personalizzati.

Vogliamo premiare le implementazioni efficaci della cache, ma desideri che le navigazioni tra siti rapide siano in grado di nascondere le pagine di destinazione lente viene caricato automaticamente. Inoltre non vogliamo incentivare i siti a suddividere le pagine lunghe in un raccolta di pagine più brevi al fine di migliorare i punteggi delle metriche.

Valutando separatamente le visite alle pagine multiorigine e della stessa origine, possiamo aiutarti garantire che entrambi i tipi di esperienze siano importanti senza permettere al relativo la popolarità di un tipo su un determinato sito distorce la distribuzione di qualsiasi o una metrica di valutazione.

Progetta nuove API che consentano una migliore misurazione SPA

Un'altra soluzione su cui si sta lavorando attivamente (in parallelo a quanto sopra) una nuova API App History, che aiuterebbe a standardizzare le attuali Pattern SPA e semplificano la misurazione e la comprensione dell'utilizzo di SPA su larga scala.

L'API App History introduce una nuova navigate, che presenta due funzionalità chiave specifiche per la misurazione delle SPA:

• R userInitiated che verrà impostato su true solo se la navigazione è stata avviata tramite un clic sui link, l'invio di un modulo o l'interfaccia utente per andare avanti o indietro del browser.
• R transitionWhile() , che è una promessa che consente allo sviluppatore di segnalare quando che hanno avviato ed eseguire la navigazione è completa.

Il flag userInitiated può essere utilizzato per determinare un punto di partenza semantico per una transizione del percorso SPA, che indica un chiaro intento dell'utente. transitionWhile() la risoluzione delle promesse può aiutare il browser a correlare i colori con il percorso specifico di grandi dimensioni, in modo da poter determinare la più grande visualizzazione relative a questa transizione.

Partendo dall'idea presentata nella sezione precedente, potrebbe anche essere è possibile aggregare il tempo di transizione delle route SPA nello stesso bucket una pagina della stessa origine in un MPA. È una cosa entusiasmante perché consentirebbe a un sito eseguire la migrazione da un MPA a un'APS per confrontare effettivamente le prestazioni in seguito.

Ovviamente, saranno necessarie ulteriori ricerche per sapere se siamo in grado di prendere queste decisioni. Se hai suggerimenti o feedback su questi argomenti proposte, invia un'email web-vitals-feedback@googlegroups.com.

Considerazioni finali

Google si impegna a fondo per migliorare le metriche Web Vitals e garantire misurano e incentivano esperienze di alta qualità che sono importanti per utenti. Detto questo, siamo consapevoli dell'esistenza di lacune nella misurazione. La metriche attualmente non coprono ogni aspetto dell'esperienza utente, ma lavorando attivamente per colmare queste lacune.

Nonostante i limiti attuali, riteniamo che le aree in cui vengono utilizzate le metriche esistenti acquisizioni sono fondamentali per la salute e il successo del web e, nella misura che i siti (indipendentemente dall'architettura) non soddisfino le soglie consigliate, riteniamo che ci sia un margine di miglioramento.

Spero che questo post ti abbia aiutato a far luce su questo argomento complesso e ricco di sfumature. Come sempre, se hai feedback sulle metriche attuali o future di Web Vitals, invia un'email web-vitals-feedback@googlegroups.com.