A partire dal set di dati di marzo 2024, il Report sull'esperienza utente di Chrome (CrUX) include una metrica navigation_types
. Vengono fornite statistiche aggregate sui tipi di navigazione dei caricamenti delle pagine per la dimensione sottoposta a query.
I diversi tipi di navigazione comportano differenze nelle metriche di rendimento; pertanto, quando analizzi il rendimento del tuo sito, è utile capire la frequenza relativa di questi vari tipi. Ad esempio, quando una navigazione utilizza il back-forward (bfcache), di solito si produce una navigazione quasi istantanea, che si riflette in metriche LCP e FCP ridotte, oltre a metriche CLS e INP ridotte.
Esponendo l'analisi del tipo di navigazione, speriamo di incoraggiare i proprietari dei siti a essere più consapevoli dei tipi di navigazione utilizzati sui loro siti e cercare di incoraggiare alcuni di questi tipi più veloci esaminando la configurazione della memorizzazione nella cache, i blocchi della cache back-forward e il prerendering.
La metrica navigation_types
è disponibile nell'API CrUX giornaliera, nell'API CrUX History (con una cronologia di 3 settimane disponibile inizialmente e con un aumento della copertura settimanale o completa nei prossimi 6 mesi), nell'ultimo set di dati BigQuery di CrUX e nella Dashboard di CrUX. La cronologia consente anche ai proprietari dei siti di visualizzare i cambiamenti nell'utilizzo del tipo di navigazione nel tempo. Ciò può consentire il monitoraggio dei miglioramenti (ad esempio, la rimozione del blocco della cache back-forward). Può anche essere utile per spiegare le modifiche alle metriche anche se non sono state apportate modifiche ai siti.
Quali tipi di navigazione sono disponibili in CrUX?
CrUX distingue i seguenti tipi di navigazione nella tabella seguente:
Tipo | Descrizione |
---|---|
navigate |
Un caricamento pagina, che non rientra in nessuna delle altre categorie. |
navigate_cache |
Un caricamento pagina per cui la risorsa principale (il documento HTML principale) è stata fornita dalla cache HTTP. I siti spesso ricorrono alla memorizzazione nella cache per le risorse secondarie, ma il documento HTML principale viene spesso memorizzato nella cache molto meno. Quando è possibile, le prestazioni possono migliorare notevolmente, grazie alla possibilità di essere memorizzate nella cache localmente e su una rete CDN. |
reload |
L'utente ha ricaricato la pagina premendo il pulsante Ricarica, premendo Invio nella barra degli indirizzi o annullando la chiusura di una scheda. I ricaricamenti delle pagine spesso comportano una nuova convalida al server per controllare se la pagina principale è stata modificata. Un'elevata percentuale di ricarica delle pagine potrebbe essere un segnale di frustrazione per gli utenti. |
restore |
La pagina è stata ricaricata dopo il riavvio del browser o una scheda che è stata rimossa per motivi di memoria. Per Chrome su Android, questi vengono segnalati come reload . |
back_forward |
Una navigazione nella cronologia, il che significa che la pagina è stata visualizzata e visualizzata di recente. Con una memorizzazione nella cache corretta, queste dovrebbero essere esperienze ragionevolmente veloci, ma richiedere comunque l'elaborazione della pagina e l'esecuzione di JavaScript, entrambi evitabili dalla bfcache. |
back_forward_cache |
Una navigazione della cronologia fornita dalla cache back-forward. L'ottimizzazione delle pagine per sfruttare la cache back-forward dovrebbe comportare un'esperienza più veloce. I siti dovrebbero cercare di rimuovere i blocchi della cache back-forward per migliorare la percentuale di navigazioni in questa categoria. |
prerender |
La pagina è stata prerenderizzata e, analogamente alla cache bfcache, la pagina può essere sottoposta a caricamenti quasi istantanei. |
In alcuni casi, un caricamento pagina può essere una combinazione di più tipi di navigazione. In questo caso, CrUX segnala la prima corrispondenza in ordine inverso rispetto alla tabella precedente (dal basso verso l'alto).
Limitazioni dei tipi di navigazione in CrUX
Poiché CrUX è un set di dati pubblico, la sua granularità dei report è limitata. Per molte origini e molti URL, la metrica navigation_types
non è disponibile a causa di traffico idoneo insufficiente. Per saperne di più, consulta la metodologia CrUX.
Inoltre, CrUX non è in grado di fornire suddivisioni di altre metriche per tipo di navigazione, in quanto ciò ridurrebbe ulteriormente il numero di origini e URL disponibili in CrUX.
Consigliamo ai siti di implementare il proprio monitoraggio degli utenti reali (RUM) per essere in grado di suddividere il traffico in base a criteri come i tipi di navigazione. Tieni presente che potresti notare differenze nei tipi di navigazione in queste soluzioni a seconda dei tipi segnalati e delle visualizzazioni di pagina incluse. Consulta l'articolo Perché i dati CrUX sono diversi dai miei dati RUM?.
RUM può anche fornire un livello di dettaglio maggiore su specifici problemi di prestazioni. Ad esempio, mentre CrUX può suggerire che sarebbe utile migliorare l'idoneità alla cache back-forward, l'API bfcache not robustdReasons può indicare esattamente il motivo per cui un determinato caricamento pagina non è stato pubblicato dalla cache back-forward.
Tipi di navigazione nell'API CrUX
Per visualizzare i tipi di navigazione nell'API, includi la metrica navigation_types
nella richiesta oppure non impostarne una in modo da includere tutte le metriche:
export API_KEY="[YOUR_API_KEY]"
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=$API_KEY" \
--header 'Content-Type: application/json' \
--data '{"origin": "https://example.com", metrics: ["navigation_types"]}'
Il formato della richiesta è descritto più dettagliatamente nella documentazione API, che include una spiegazione su come ottenere la chiave API e la guida alle API. Verrà restituito un oggetto simile al seguente:
{
"record": {
"key": { "origin": "https://example.com" },
"metrics": {
"navigation_types": {
"fractions": {
"navigate": 0.5335,
"navigate_cache": 0.2646,
"reload": 0.0885,
"restore": 0.0023,
"back_forward": 0.0403,
"back_forward_cache": 0.0677,
"prerender": 0.0031
}
}
},
"collectionPeriod": {
"firstDate": { "year": 2024, "month": 3, "day": 6 },
"lastDate": { "year": 2024, "month": 4, "day": 2 }
}
}
}
Nella risposta, CrUX segnala la metrica navigation_types
come oggetto con le frazioni dei caricamenti pagina per ciascun tipo di navigazione. Ogni frazione è un valore compreso tra 0.0
(indicando lo 0% dei caricamenti delle pagine) e 1.0
(indicando il 100% dei caricamenti delle pagine) per la chiave specificata.
Da questa risposta puoi notare che per il periodo di raccolta dal 6 marzo 2024 al 2 aprile 2024 incluso: il 6,77% delle navigazioni (caricamenti pagina) è stato fornito dalla cache back-forward del browser. Allo stesso modo, alcune delle altre frazioni possono aiutare a identificare le opportunità di ottimizzazione del caricamento delle pagine. Tieni presente che per ogni chiave specifica (inclusa una combinazione di un URL o di un'origine e un fattore di forma), la somma delle frazioni navigation_types
corrisponde a circa 1,0.
Tipi di navigazione nell'API CrUX History
L'API CrUX History può fornire una serie temporale per i tipi di navigazione con un massimo di 25 punti dati per frazione, che consente di visualizzare queste frazioni nel tempo. Per modificare la richiesta dall'API CrUX all'API CrUX History, eseguila sull'endpoint queryHistoryRecord
anziché su queryRecord
. Ad esempio, il nostro Colab con la cronologia CrUX traccia la metrica navigation_types
come barre in pila:
![Grafico a barre in pila che mostra la cronologia dei tipi di navigazione nell'arco di tre settimane, con la maggior parte delle operazioni di navigazione di tipo "navigazione" e nessun cambiamento significativo nelle tre settimane.](https://developer.chrome.google.cn/static/blog/crux-navigation-types/image/navigation-types-history-chart.png?authuser=5&hl=it)
Nello screenshot precedente, la cronologia è disponibile soltanto per 3 periodi di raccolta (28 giorni ciascuno, a distanza di 7 giorni). Una volta completata, l'elenco coprirà tutti i 25 periodi di raccolta. La visualizzazione di questa cronologia consente di confermare che le ottimizzazioni sono state applicate o sono regredite. Questo è particolarmente vero per la configurazione della cache HTTP, che consente l'ottimizzazione di una pagina per la cache back-forward e il prerendering.
Tipi di navigazione in CrUX BigQuery
Le tabelle BigQuery per CrUX ora includono un record navigation_type
, composto per ogni tipo, mentre le viste materializzate di riepilogo includono più colonne navigation_types_*
, una per ogni tipo.
Tabelle dettagliate
Lo schema della tabella dettagliata in CrUX BigQuery fornisce istogrammi dettagliati per le metriche delle prestazioni web, che ci permettono di mostrare in questa analisi esemplificativa in che modo determinati tipi di navigazione possono essere correlati alle prestazioni di caricamento istantaneo o buono.
Ad esempio, abbiamo esaminato la frazione back_forward_cache
e la sua correlazione con la frequenza di caricamento istantaneo delle pagine (instant_lcp_density
definito come LCP <= 200 ms) e con quale frequenza è stato riscontrato un buon LCP (good_lcp_density
definito come LCP <= 2500 ms). Abbiamo osservato una forte correlazione statistica tra back_forward_cache
e instant_lcp_density
(sp=0,87), mostrata nel seguente grafico, e una correlazione moderata tra back_forward_cache
e good_lcp_density
(sp=0,29).
![Grafico di correlazione che mostra una forte correlazione tra la frazione di caricamenti di pagina istantanei e la frazione di caricamenti di pagine bfcache](https://developer.chrome.google.cn/static/blog/crux-navigation-types/image/instant-lcp-bfcache-correlation.png?authuser=5&hl=it)
Il report Colab per questa analisi è ben commentato; qui discutiamo solo la query che estrae le frazioni di navigazione_types per le 10.000 origini più popolari dalle tabelle dettagliate in CrUX BigQuery:
- Accediamo alla tabella
all.202403
qui (vedi la fraseFROM
), filtrandoform_factor
perphone
e selezioniamo le origini con ranking di popolarità <= 10.000 per le prime 10.000 origini più popolari (vedi la clausolaWHERE
). - Quando esegui una query sulla metrica
navigation_types
in BigQuery, è necessario dividere per il totale delle frazioninavigation_types
, poiché queste si sommano solo per origine, ma non per combinazione (origine, fattore di forma). - Non tutte le origini avranno
navigation_types
, quindi è buona norma usareSAVE_DIVIDE
.
WITH tmp AS (
SELECT
origin,
SUM(navigation_types.navigate.fraction) AS navigate,
SUM(navigation_types.navigate_cache.fraction) AS navigate_cache,
SUM(navigation_types.reload.fraction) AS reload,
SUM(navigation_types.restore AS restore,
SUM(navigation_types.back_forward.fraction) AS back_forward,
SUM(navigation_types.back_forward_cache.fraction) AS back_forward_cache,
SUM(navigation_types.prerender.fraction) AS prerender,
SUM(navigation_types.navigate.fraction
+ navigation_types.navigate_cache.fraction
+ navigation_types.reload.fraction
+ navigation_types.restore.fraction
+ navigation_types.back_forward.fraction
+ navigation_types.back_forward_cache.fraction
+ navigation_types.prerender.fraction) AS total
FROM
`chrome-ux-report.all.202403`
WHERE
experimental.popularity.rank <= 10000 AND
form_factor.name = 'phone'
GROUP BY
origin
)
SELECT
origin,
ROUND(SAFE_DIVIDE(navigate, total), 4) AS navigate,
ROUND(SAFE_DIVIDE(navigate_cache, total), 4) AS navigate_cache,
ROUND(SAFE_DIVIDE(reload, total), 4) AS reload,
ROUND(SAFE_DIVIDE(restore, total), 4) AS restore,
ROUND(SAFE_DIVIDE(back_forward, total), 4) AS back_forward,
ROUND(SAFE_DIVIDE(back_forward_cache, total), 4) AS back_forward_cache,
ROUND(SAFE_DIVIDE(prerender, total), 4) AS prerender
FROM
tmp
Tabelle materializzate
Quando un riepilogo è sufficiente, spesso è più conveniente (e meno costoso) eseguire query sulle tabelle materializzate. Ad esempio, la seguente query estrae i dati navigation_types
disponibili dalla tabella chrome-ux-report.materialized.device_summary
. La tabella è basata su mese, origine e tipo di dispositivo.
SELECT
yyyymm,
device,
navigation_types_navigate,
navigation_types_navigate_cache,
navigation_types_reload,
navigation_types_restore,
navigation_types_back_forward,
navigation_types_back_forward_cache,
navigation_types_prerender
FROM
chrome-ux-report.materialized.device_summary
WHERE
origin = 'https://example.com' AND
navigation_types_navigate IS NOT NULL
ORDER BY
yyyymm DESC,
device DESC
Tieni presente che la somma di queste frazioni non sarà pari a 1,0 per riga, quindi è necessario dividere ogni frazione per la somma dei risultati su cui deve essere interpretata la query.
Il motivo è che la somma di navigation_type
frazioni in chrome-ux-report.materialized.device_summary
, come le densità degli istogrammi, è pari a 1,0 per origine anziché per origine e dispositivo per data. In questo modo puoi visualizzare la distribuzione dei tipi di navigazione tra i dispositivi:
SELECT
device,
navigation_types_back_forward
FROM
chrome-ux-report.materialized.device_summary
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202403
device |
navigation_types_back_forward |
---|---|
phone |
0.0663 |
desktop |
0.0179 |
tablet |
0.0009 |
In questo risultato della query, le frazioni riflettono la percentuale di caricamenti pagina per l'origine https://www.google.com
: il 6,63% dei caricamenti di pagine aveva il tipo di navigazione back_forward
su telefono, l'1,79% su computer e lo 0,09% su tablet.
La percentuale di back_forward
notevolmente più elevata su phone
suggerisce che potremmo provare a ottimizzare i caricamenti di queste pagine in modo che possano essere pubblicate dalla cache back-forward.
Tuttavia, è anche importante considerare quale frazione di caricamenti pagina è già servita dalla bfcache, ovvero la percentuale di hit della cache bfcache. La seguente query suggerisce che questa particolare origine potrebbe essere già ben ottimizzata, considerate percentuali di successo superiori al 60% per telefoni e computer.
SELECT
device,
navigation_types_back_forward_cache /
(navigation_types_back_forward + navigation_types_back_forward_cache)
AS back_forward_cache_hit_rate
FROM
chrome-ux-report.materialized.device_summary
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202403
device |
back_forward_cache_hit_rate |
---|---|
phone |
0.6239 |
desktop |
0.6805 |
tablet |
0.7353 |
Quindi sembrerebbe che l'elevato tasso di back_forward
sugli smartphone non sia dovuto a un minore utilizzo della cache bfcache, ma più a un riflesso del modo in cui gli utenti si spostano più avanti e indietro sui telefoni.
Tipi di navigazione nella dashboard di CrUX
Il modo più semplice per vedere i tipi di navigazione è nella dashboard di CrUX, a cui è possibile accedere per un'origine da questo link. Come puoi vedere dallo screenshot seguente, inizialmente sono disponibili solo i dati di un mese, ma nel tempo la cronologia si riempirà consentendoti di vedere i cambiamenti nei tipi mese per mese.
![Screenshot della schermata Distribuzione dei tipi di navigazione nella dashboard di CrUX che mostra un mese di dati.](https://developer.chrome.google.cn/static/blog/crux-navigation-types/image/crux-dashboard-navigation-types.png?authuser=5&hl=it)
Come puoi anche vedere, nella parte superiore di questa pagina della dashboard abbiamo evidenziato i tipi di navigazione più veloci, che dovrebbero essere ottimizzati.
Conclusione
Ci auguriamo che le suddivisioni dei tipi di navigazione in CrUX ti siano utili e che ti aiutino a comprendere e ottimizzare il rendimento del tuo sito. Garantendo un uso efficiente della memorizzazione nella cache HTTP, della cache back-forward e del prerendering, i siti possono caricare pagine molto più rapidamente rispetto ai caricamenti delle pagine che richiedono una visita al server.
Inoltre, siamo lieti di rendere disponibili i dati in tutti i vari punti di accesso CrUX, in modo che gli utenti possano utilizzare i dati come vogliono e vedere le suddivisioni dei tipi in base all'URL per coloro che sono esposti nelle API CrUX.
Ci piacerebbe ricevere un feedback su questa aggiunta a CrUX sui social media o sul gruppo di discussione di CrUX.