Fin dal suo lancio, l'iniziativa Segnali web essenziali ha cercato di misurare l'esperienza utente effettiva di un sito web, piuttosto che i dettagli tecnici della modalità di creazione o caricamento di un sito web. Le tre metriche di Segnali web essenziali sono state create come metriche incentrate sull'utente, un'evoluzione rispetto a metriche tecniche esistenti come DOMContentLoaded o load che misuravano tempismi spesso non correlati al modo in cui gli utenti percepivano le prestazioni della pagina. Per questo motivo, la tecnologia utilizzata per creare un sito non dovrebbe influire sul punteggio a condizione che il sito funzioni bene.
La realtà è sempre un po' più difficile dell'ideale e la popolare architettura delle applicazioni a pagina singola non è mai stata completamente supportata dalle metriche di Core Web Vitals. Anziché caricare singole pagine web distinte durante la navigazione dell'utente all'interno del sito, queste applicazioni web utilizzano le cosiddette "navigazioni soft", in cui i contenuti della pagina vengono modificati da JavaScript. In queste applicazioni, viene mantenuta l'illusione di un'architettura di pagina web convenzionale modificando l'URL e spingendo gli URL precedenti nella cronologia del browser per consentire il funzionamento dei pulsanti Indietro e Avanti come previsto.
Molti framework JavaScript utilizzano questo modello, ma ognuno in un modo diverso. Dal momento che questo dato esula da ciò che il browser in genere interpreta come "pagina", la misurazione di questo aspetto è sempre stata difficile: qual è la linea da tracciare tra un'interazione sulla pagina corrente rispetto a considerare questa come una pagina nuova?
Il team di Chrome sta esaminando questa sfida da tempo e sta cercando di standardizzare una definizione di "navigazione soft" e di come possono essere misurati i Segnali web essenziali a questo scopo, in modo simile ai siti web implementati nell'architettura multi-pagina convenzionale (MPA). Sebbene sia ancora nelle fasi iniziali, il team è pronto a rendere disponibile per i siti un'ampia disponibilità di ciò che è già stato implementato. In questo modo, i siti potranno fornire un feedback sull'approccio che hai adottato finora.
Che cos'è una navigazione soft?
Abbiamo ideato la seguente definizione di navigazione soft:
- La navigazione viene avviata da un'azione dell'utente.
- La navigazione comporta una modifica visibile dell'URL per l'utente e una modifica della cronologia.
- La navigazione genera una modifica del DOM.
Per alcuni siti, queste euristiche possono generare falsi positivi (che gli utenti non considererebbero effettivamente una "navigazione ") o falsi negativi (dove l'utente considera avvenuta una "navigazione" nonostante non soddisfi questi criteri). Siamo lieti di ricevere feedback sull'euristica nel repository delle specifiche di navigazione soft.
In che modo Chrome implementa le navigazioni software?
Una volta attivate le euristiche di navigazione soft (ulteriori informazioni nella prossima sezione), Chrome cambierà la modalità di segnalazione di alcune metriche sul rendimento:
- Dopo il rilevamento di ogni navigazione soft, verrà generato un evento
soft-navigationPerformanceTiming. - L'API Performance fornirà l'accesso a una voce di tempo
soft-navigation, come emessa dall'eventoPerformanceTimingsoft-navigation. - Le metriche First Paint (FP), First Contentful Paint (FCP) e Largest Contentful Paint (LCP) vengono reimpostate e vengono nuovamente emesse alle successive occorrenze appropriate. Nota: FP e FCP non sono ancora stati implementati.
- Un attributo
navigationIdverrà aggiunto a ciascuno dei tempi delle prestazioni (first-paint,first-contentful-paint,largest-contentful-paint,first-input-delay,eventelayout-shift) corrispondente alla voce di navigazione a cui era correlato l'evento, consentendo di calcolare Cumulative Layout Shift (CLS) e Interaction to Next Paint (INP).
Queste modifiche consentiranno di misurare i Segnali web essenziali e alcune delle metriche di diagnostica associate per ogni navigazione nelle pagine, sebbene ci siano alcuni aspetti che devono essere presi in considerazione.
Quali sono le implicazioni dell'attivazione delle navigazioni software in Chrome?
Di seguito sono riportate alcune delle modifiche che i proprietari dei siti devono prendere in considerazione dopo aver attivato questa funzionalità:
- Altri eventi FP, FCP e LCP possono essere riemessi per navigazioni soft. Il Report sull'esperienza utente di Chrome (CrUX) ignorerà questi valori aggiuntivi, ma ciò potrebbe influire su qualsiasi monitoraggio RUM (Real User Measurement) sul tuo sito. Verifica con il tuo fornitore di RUM se hai dubbi sull'impatto sulle misurazioni. Consulta la sezione sulla misurazione dei Segnali web essenziali per le navigazioni flessibili.
- Il nuovo attributo
navigationID(e facoltativo) nelle voci relative al rendimento potrebbe dover essere preso in considerazione nel codice dell'applicazione utilizzando queste voci. - Questa nuova modalità sarà supportata solo dai browser basati su Chromium. Anche se molte delle metriche più recenti sono disponibili solo nei browser basati su Chromium, alcune (FCP, LCP) sono disponibili in altri browser e non tutti potrebbero aver eseguito l'upgrade alla versione più recente dei browser basati su Chromium. Tieni presente che alcuni utenti potrebbero non generare report con le metriche di navigazione soft.
- Si tratta di una nuova funzionalità sperimentale che non è attiva per impostazione predefinita, pertanto i siti dovrebbero testarla per assicurarsi che non si verifichino altri effetti collaterali indesiderati.
Per saperne di più su come misurare le metriche per le navigazioni flessibili, consulta la sezione sulla misurazione dei Segnali web essenziali per navigazione soft.
Come faccio ad attivare le navigazioni soft in Chrome?
Le navigazioni soft non vengono attivate per impostazione predefinita in Chrome, ma possono essere sperimentate con Chrome 110 mediante l'attivazione esplicita di questa funzionalità.
Per gli sviluppatori, questa funzionalità può essere attivata attivando il flag Funzionalità sperimentali della piattaforma web all'indirizzo chrome://flags/#enable-experimental-web-platform-features o utilizzando l'argomento della riga di comando --enable-experimental-web-platform-features durante l'avvio di Chrome.
Per un sito web che vuole attivare questa funzionalità per tutti i visitatori per vederne l'impatto, è disponibile una prova dell'origine in esecuzione da Chrome 117, che può essere attivata registrandosi per la prova e includendo un meta elemento con il token della prova dell'origine nell'intestazione HTML o HTTP. Per saperne di più, consulta il post Iniziare a utilizzare le prove dell'origine.
I proprietari dei siti possono scegliere di includere la prova dell'origine sulle loro pagine per tutti o solo per un sottoinsieme di utenti. Tieni presente la precedente sezione delle implicazioni in merito a come ciò cambia il modo in cui le metriche potrebbero essere registrate, soprattutto se attivi questa prova dell'origine per un'ampia percentuale di utenti. Tieni presente che CrUX continuerà a generare report sulle metriche nel modo esistente, indipendentemente da questa impostazione di navigazione semplificata, per cui non viene influenzata da queste implicazioni. Occorre inoltre tenere presente che le prove dell'origine sono limitate anche all'attivazione di funzionalità sperimentali su un massimo dello 0,5% di tutti i caricamenti delle pagine di Chrome in una media di 14 giorni, ma questo dovrebbe essere un problema solo per i siti di grandi dimensioni.
Come posso misurare le navigazioni flessibili?
Una volta abilitato l'esperimento di navigazione soft, le metriche verranno registrate utilizzando l'API PerformanceObserver come di consueto. Tuttavia, per queste metriche occorre prendere in considerazione alcuni aspetti aggiuntivi.
Segnala navigazioni soft
Puoi utilizzare un PerformanceObserver per osservare le navigazioni in modalità soft. Di seguito è riportato uno snippet di codice di esempio che registra le voci di navigazione soft nella console, incluse le navigazioni software precedenti in questa pagina utilizzando l'opzione buffered:
const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });
Questa opzione può essere utilizzata per finalizzare le metriche complete della pagina per la navigazione precedente.
Segnala le metriche rispetto all'URL appropriato
Poiché le navigazioni software possono essere visualizzate solo dopo che si sono verificate, alcune metriche dovranno essere finalizzate in base a questo evento e poi riportate per l'URL precedente, poiché l'URL corrente ora rifletterà quello aggiornato per la nuova pagina.
L'attributo navigationId dell'elemento PerformanceEntry appropriato può essere utilizzato per ricollegare l'evento all'URL corretto. Può essere cercato con l'API PerformanceEntry:
const softNavEntry =
performance.getEntriesByType('soft-navigation').filter(
(entry) => entry.navigationId === navigationId
)[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;
Questo pageUrl dovrebbe essere utilizzato per segnalare le metriche in base all'URL corretto e non all'URL corrente che potrebbe aver utilizzato in passato.
Recupero del startTime delle navigazioni soft
Puoi ottenere il tempo di inizio della navigazione in un modo simile:
const softNavEntry =
performance.getEntriesByType('soft-navigation').filter(
(entry) => entry.navigationId === navigationId
)[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;
startTime indica l'ora dell'interazione iniziale, ad esempio il clic di un pulsante, che ha avviato la navigazione soft.
Tutti i tempi delle prestazioni, inclusi quelli per le navigazioni flessibili, sono indicati come tempo di navigazione iniziale "difficile" nella pagina. Di conseguenza, il tempo di avvio della navigazione soft è necessario per basare i tempi delle metriche di caricamento della navigazione soft (ad esempio LCP), rispetto a questo tempo di navigazione soft.
Misura i Segnali web essenziali per navigazione soft
Per includere le voci delle metriche di navigazione soft, devi includere includeSoftNavigationObservations: true nella chiamata observe di Performance Observationr.
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
console.log('Layout Shift time:', entry);
}
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});
Oltre all'attivazione della funzionalità di navigazione soft in Chrome, è necessario il flag includeSoftNavigationObservations aggiuntivo nel metodo observe. Questa attivazione esplicita a livello di osservatore delle prestazioni serve a garantire che gli attuali osservatori delle prestazioni non siano sorpresi da queste voci aggiuntive, poiché è necessario prendere in considerazione alcune considerazioni aggiuntive quando si cerca di misurare i Segnali web essenziali per le navigazioni flessibili.
I tempi verranno comunque restituiti rispetto all'ora di inizio della navigazione "difficile" originale. Quindi, per calcolare l'LCP per una navigazione soft, ad esempio, devi prendere il tempo LCP e sottrarre il tempo di inizio della navigazione soft appropriato come dettagliato in precedenza per ottenere un tempismo relativo alla navigazione soft. Ad esempio, per LCP:
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
const softNavEntry =
performance.getEntriesByType('soft-navigation').filter(
(navEntry) => navEntry.navigationId === entry.navigationId
)[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;
console.log('LCP time:', entry.startTime - startTime);
}
}).observe({type: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});
Tradizionalmente, alcune metriche vengono misurate per tutta la durata della pagina: il valore LCP, ad esempio, può cambiare fino a quando si verifica un'interazione. È possibile aggiornare CLS e INP finché non esci dalla pagina. Di conseguenza, ogni "navigazione" (compresa la navigazione originale) potrebbe dover finalizzare le metriche della pagina precedente ogni volta che si verifica ogni nuova navigazione soft. Ciò significa che le metriche di navigazione "difficili" iniziali potrebbero essere finalizzate prima del solito.
Analogamente, quando inizi a misurare le metriche per la nuova navigazione soft di queste metriche di lunga durata, le metriche dovranno essere "reimpostate" o "reinizializzate" e trattate come nuove metriche, senza memoria dei valori impostati per le "pagine" precedenti.
Come dovrebbero essere trattati i contenuti che rimangono invariati nelle navigazioni?
FP, FCP e LCP per le navigazioni soft misurano solo i nuovi colori. Ciò può comportare un LCP diverso, ad esempio, da un carico a freddo di quella navigazione soft a un carico flessibile.
Ad esempio, prendi in considerazione una pagina che include un'immagine banner di grandi dimensioni che rappresenta l'elemento LCP, ma il testo sottostante cambia ad ogni navigazione soft. Il caricamento iniziale della pagina contrassegnerà l'immagine banner come elemento LCP, su cui si baserà il tempismo LCP. Per le navigazioni future, il testo sottostante sarà l'elemento più grande visualizzato dopo la navigazione soft e sarà il nuovo elemento LCP. Tuttavia, se viene caricata una nuova pagina con un link diretto nell'URL di navigazione soft, l'immagine del banner sarà di colore nuovo e potrà quindi essere considerata come elemento LCP.
Come illustrato in questo esempio, l'elemento LCP per la navigazione soft può essere riportato in modo diverso a seconda del modo in cui viene caricata la pagina: allo stesso modo del caricamento di una pagina con un link di ancoraggio più in basso nella pagina, è possibile che venga visualizzato un elemento LCP diverso.
Come si misura il TTFB?
Il valore TTFB (Time to First Byte) per un caricamento pagina convenzionale rappresenta il tempo in cui vengono restituiti i primi byte della richiesta originale.
Per una navigazione semplificata, questa è una domanda più difficile. Dovremmo misurare la prima richiesta fatta per la nuova pagina? Cosa succede se tutti i contenuti esistono già nell'app e non ci sono richieste aggiuntive? Che cosa succede se questa richiesta viene effettuata in anticipo con un precaricamento? Che cosa succede se una richiesta non correlata alla navigazione soft dal punto di vista dell'utente (ad esempio, si tratta di una richiesta di analisi)?
Un metodo più semplice consiste nel segnalare il TTFB pari a 0 per le navigazioni soft, in modo simile a quanto consigliamo per i ripristini della cache back-forward. Questo è il metodo attualmente utilizzato dalla libreria web-vitals per le navigazioni soft.
In futuro, potremmo supportare modalità più precise per stabilire quale richiesta sia la "richiesta di navigazione" della navigazione software e saremo in grado di ottenere misurazioni TTFB più precise. Ma non fa parte dell'esperimento corrente.
Come misurare i vecchi e i nuovi?
Durante questo esperimento, ti consigliamo di continuare a misurare i tuoi Segnali web essenziali nel modo attuale, in base alle navigazioni "difficili" nelle pagine in modo che corrispondano a ciò che CrUX misurerà e segnalerà come set di dati ufficiale dell'iniziativa Core Web Vitals.
Oltre a queste attività, occorre anche misurare le navigazioni software per capire come potrebbero essere misurate in futuro e per dare l'opportunità di fornire al team di Chrome un feedback su come funziona nella pratica questa implementazione. Questo aiuterà te e il team di Chrome a definire l'API in futuro.
Per misurare entrambi, devi conoscere i nuovi eventi che possono essere generati in modalità di navigazione soft (ad esempio più eventi FCP e LCP aggiuntivi) e gestirli in modo appropriato finalizzando queste metriche al momento opportuno, ignorando anche gli eventi futuri che si applicano solo alle navigazioni soft.
Usa la libreria web-vitals per misurare i Segnali web essenziali per le navigazioni flessibili
Il modo più semplice per tenere conto di tutte le sfaccettature è utilizzare la libreria JavaScript web-vitals che offre il supporto sperimentale per le navigazioni soft in un soft-navs branch separato (disponibile anche su npm e unpkg). Questo valore può essere misurato nel seguente modo (sostituendo doTraditionalProcessing e doSoftNavProcessing, a seconda dei casi):
import {
onTTFB,
onFCP,
onLCP,
onCLS,
onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';
onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);
onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});
Assicurati che le metriche vengano riportate in base all'URL corretto come indicato in precedenza.
La libreria web-vitals segnala le seguenti metriche per le navigazioni soft:
| Metrica | Dettagli |
|---|---|
| TTFB | Segnalato come 0. |
| FCP | Al momento solo il primo FCP della pagina è indicato dalla libreria web-vitals. |
| LCP | L'ora della successiva visualizzazione con contenuti più grande, in relazione all'ora di inizio della navigazione soft. Le pitture esistenti presenti nella navigazione precedente non vengono prese in considerazione. Di conseguenza, il valore di LCP sarà >= 0. Come di consueto, i dati verranno riportati nel momento in cui la pagina viene riprodotta in background o quando si verifica un'interazione, in quanto solo dopo questa data l'LCP può essere finalizzata. |
| CLS | La finestra di spostamento più grande tra i tempi di navigazione. Come di consueto, questo viene fatto quando la pagina viene eseguita in background, in quanto solo a quel punto è possibile finalizzare la CLS. Se non sono presenti variazioni, viene riportato un valore pari a 0. |
| INP | L'INP tra i tempi di navigazione. Come di consueto, questo verrà segnalato su un'interazione o quando la pagina viene riprodotta in background, in quanto solo allora l'INP può essere finalizzato. Se non sono presenti interazioni, non viene registrato il valore 0. |
Queste modifiche entreranno a far parte delle misurazioni dei Segnali web essenziali?
Questo esperimento di navigazione soft è esattamente questo: un esperimento. Vogliamo valutare l'euristica e vedere se riflettono in modo più accurato l'esperienza utente prima di prendere qualsiasi decisione in merito all'integrazione o meno nell'iniziativa Core Web Vitals. Siamo entusiasti della possibilità di questo esperimento, ma non possiamo offrire garanzie sulla possibilità o meno di sostituire le misurazioni attuali.
Apprezziamo il feedback degli sviluppatori web sull'esperimento, l'euristica utilizzata e se ritieni che rispecchi in modo più accurato l'esperienza. Il repository GitHub di navigazione soft è il luogo migliore per fornire il suo feedback, sebbene i singoli bug relativi all'implementazione di Chrome vengano segnalati nel tracker dei problemi di Chrome.
Come verranno riportate le navigazioni soft in CrUX?
Inoltre, è ancora da determinare il modo in cui esattamente le navigazioni soft verranno riportate in CrUX, se questo esperimento avrà esito positivo. Non è necessariamente chiaro che verranno trattate come le attuali navigazioni "difficili".
In alcune pagine web, per quanto riguarda l'utente, le navigazioni soft sono quasi identiche ai caricamenti di pagine intere e l'utilizzo della tecnologia Applicazione a pagina singola è solo un dettaglio di implementazione. In altri, potrebbero essere più simili a un caricamento parziale di contenuti aggiuntivi.
Di conseguenza, potremmo decidere di segnalare queste navigazioni morbide separatamente in CrUX o eventualmente ponderarle nel calcolo dei Segnali web essenziali per una determinata pagina o un determinato gruppo di pagine. Man mano che l'euristica si evolve, potremmo anche essere in grado di escludere completamente la navigazione soft a carico parziale.
Allo stato attuale, il team si sta concentrando sull'implementazione euristica e tecnica, che ci permetterà di valutare il successo dell'esperimento, quindi non è stata presa alcuna decisione su questi fronti.
Feedback
Stiamo cercando attivamente un feedback su questo esperimento nelle seguenti sezioni:
- Euristica e standardizzazione della navigazione soft.
- Problemi di implementazione di Chrome di queste euristiche.
- Feedback generale sui parametri web all'indirizzo web-vitals-feedback@googlegrouops.com.
Log delle modifiche
Poiché l'API è in fase di sperimentazione, vengono apportate diverse modifiche, più che con le API stabili. Per ulteriori dettagli, vedi il Log delle modifiche all'euristica per la navigazione soft.
Conclusione
L'esperimento di navigazione soft è un approccio entusiasmante al modo in cui l'iniziativa Core Web Vitals potrebbe evolversi per misurare un modello comune nel web moderno che attualmente non è presente nelle nostre metriche. Sebbene questo esperimento sia ancora agli inizi e c'è ancora molto da fare, rendere i progressi disponibili finora alla community web più ampia con cui sperimentare è un passo importante. Raccogliere i feedback di questo esperimento è un'altra parte cruciale dell'esperimento. Pertanto, invitiamo vivamente coloro che sono interessati a questo sviluppo a sfruttare questa opportunità per contribuire a definire l'API e assicurarsi che sia rappresentativa di ciò che speriamo di poter misurare con questo strumento.
Ringraziamenti
Immagine in miniatura di Jordan Madrid su Unsplash