Tipi di navigazione ora disponibili in CrUX

A partire dal set di dati di marzo 2024, il Report sull'esperienza utente di Chrome (CrUX) include una metrica navigation_types. Questo fornisce statistiche aggregate sui tipi di navigazione dei caricamenti pagina per la dimensione sottoposta a query.

Tipi di navigazione diversi comportano differenze nelle metriche sul rendimento. Pertanto, quando esamini il rendimento del tuo sito, è utile comprendere la frequenza relativa di questi diversi tipi. Ad esempio, quando una navigazione utilizza la retromarcia (bfcache), di solito si verifica una navigazione quasi istantanea, il che si riflette nelle metriche LCP e FCP molto piccole e nelle metriche CLS e INP ridotte.

Esponendo la suddivisione del tipo di navigazione, ci auguriamo di incoraggiare i proprietari di siti a essere più consapevoli dei tipi di navigazione utilizzati sui loro siti e ci impegniamo a incoraggiare alcuni dei tipi più veloci esaminando la configurazione della memorizzazione nella cache, i blocchi bfcache 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 copertura settimanale fino alla completa nei 6 mesi successivi), nell'ultimo set di dati BigQuery di CrUX e nella Dashboard di CrUX. La cronologia consente inoltre ai proprietari dei siti di visualizzare le modifiche relative all'utilizzo del tipo di navigazione nel tempo. In questo modo è possibile monitorare i miglioramenti (ad esempio la rimozione del blocco bfcache). Inoltre, è utile per spiegare le variazioni nelle metriche anche se non sono state apportate modifiche ai siti.

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 il quale la risorsa principale (il documento HTML principale) è stata fornita dalla cache HTTP. I siti spesso utilizzano la memorizzazione nella cache per le risorse secondarie, ma il documento HTML principale viene spesso nella cache notevolmente inferiore. Quando può essere, può portare a miglioramenti significativi delle prestazioni derivanti dalla possibilità di essere memorizzato nella cache in locale e su una 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 di pagine spesso comportano una riconvalida al server per verificare se la pagina principale è stata modificata. Un'elevata percentuale di ricaricamenti delle pagine può indicare utenti frustrati.
restore La pagina è stata ricaricata dopo un riavvio del browser o una scheda che è stata rimossa per motivi di memoria. Per Chrome su Android, questi elementi vengono segnalati invece come reload.
back_forward Una navigazione della cronologia, il che significa che la pagina è stata visualizzata e tornata di recente. Con una memorizzazione nella cache corretta, dovrebbero essere esperienze ragionevolmente rapide, ma richiedere comunque l'elaborazione della pagina e l'esecuzione di JavaScript, entrambi evitati da bfcache.
back_forward_cache Una navigazione della cronologia fornita da bfcache. L'ottimizzazione delle pagine per sfruttare bfcache dovrebbe comportare esperienze più veloci. I siti dovrebbero cercare di rimuovere i blocchi bfcache per migliorare la percentuale di navigazioni in questa categoria.
prerender La pagina è stata prerenderizzata e questo, come per bfcache, può comportare 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 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 di CrUX.

Inoltre, CrUX non è in grado di fornire analisi dettagliate 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 Real User Monitoring (RUM) per poter 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 dati RUM?.

Il RUM può inoltre fornire un maggiore livello di dettaglio su problemi di prestazioni specifici. Ad esempio, anche se CrUX può suggerire che vale la pena migliorare l'idoneità a bfcache, l'API bfcache notRipristinadReasons può indicare esattamente il motivo per cui non è stato possibile fornire un determinato caricamento pagina dalla bfcache.

Tipi di navigazione nell'API CrUX

Per visualizzare i tipi di navigazione nell'API, includi la metrica navigation_types nella richiesta oppure non impostare una metrica in modo che vengano incluse 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 dell'API, che include una spiegazione su come ottenere la chiave API e nella 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 di caricamenti pagina per ciascuno dei tipi di navigazione. Ogni frazione è un valore compreso tra 0.0 (che indica lo 0% dei caricamenti pagina) e 1.0 (che indica il 100% dei caricamenti pagina) per la chiave specificata.

Da questa risposta puoi vedere che, per il periodo di raccolta a partire dal 6 marzo 2024, fino al 2 aprile 2024 incluso, il 6,77% delle navigazioni (caricamenti pagina) è stato gestito dalla cache bfcache del browser. Analogamente, alcune delle altre frazioni possono essere utili per identificare le opportunità di ottimizzazione del caricamento delle pagine. Tieni presente che per ogni chiave specifica (inclusa una combinazione di URL o origine e fattore di forma), la somma delle frazioni navigation_types è pari 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, in modo da 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 della cronologia di 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, prevalentemente di tipo "navigazione" e nessun cambiamento significativo nelle tre settimane.
Tipi di navigazione nel tempo

Nello screenshot precedente, la cronologia è disponibile solo per 3 periodi di raccolta dei dati (ciascuno di 28 giorni, a 7 giorni di distanza). Una volta completata la compilazione, verranno coperti tutti i 25 periodi di raccolta dei dati. 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, l'ottimizzazione di una pagina per bfcache e il prerendering.

Tipi di navigazione in BigQuery con CrUX

Le tabelle BigQuery di CrUX ora includono un record navigation_type, composto da 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 BigQuery di CrUX fornisce istogrammi dettagliati per le metriche delle prestazioni web, che ci consentono di mostrare in questa analisi di esempio come determinati tipi di navigazione possono essere correlati con prestazioni di caricamento istantaneo o buone.

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 la frequenza con cui è stato rilevato un valore LCP buono (good_lcp_density definito come LCP <= 2500 ms). Abbiamo osservato una forte correlazione statistica tra back_forward_cache e instant_lcp_density (p=0,87), mostrata nel grafico seguente, e una correlazione moderata tra back_forward_cache e good_lcp_density (p=0,29).

Grafico di correlazione che mostra una forte correlazione tra la frazione dei caricamenti di pagina istantanei e quella dei caricamenti di pagina Bfcache
Correlazione tra caricamenti di pagine istantanei e utilizzo di bfcache

Il Colab per questa analisi è ben commentato; qui, discutiamo solo della query che estrae le frazioni Navigation_types per le 10.000 origini più popolari dalle tabelle dettagliate in BigQuery di CrUX:

  • Accediamo alla tabella all.202403 qui (vedi la clausola FROM), filtriamo form_factor per phone e selezioniamo origini con ranking di popolarità <= 10.000 per le prime 10.000 origini più popolari (consulta la clausola WHERE).
  • Quando si esegue una query sulla metrica navigation_types in BigQuery, è necessario dividere per il totale delle frazioni navigation_types, poiché si sommano solo per origine, ma non per combinazione (origine, fattore di forma).
  • Non tutte le origini avranno navigation_types, quindi è buona norma usare SAVE_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 economico) eseguire query sulle tabelle materializzate. Ad esempio, la seguente query estrae i dati navigation_types disponibili dalla tabella chrome-ux-report.materialized.device_summary. Questa tabella è definita per 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 queste frazioni non vengono sommate fino 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 navigation_type frazioni di chrome-ux-report.materialized.device_summary, ad esempio le densità degli istogrammi, vengono sommate fino a 1,0 per origine anziché per origine e dispositivo per data. In questo modo puoi visualizzare la distribuzione dei tipi di navigazione sui vari 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

Nel risultato di questa query, le frazioni riflettono la percentuale di caricamenti pagina per l'origine https://www.google.com: il 6,63% di questi caricamenti di pagine ha avuto il tipo di navigazione back_forward su telefono, 1,79% da computer e 0,09% da tablet.

La percentuale di back_forward notevolmente superiore su phone suggerisce che potremmo provare a ottimizzare questi caricamenti pagina in modo che possano essere pubblicati da bfcache.

Tuttavia, è anche importante considerare quale frazione dei caricamenti pagina viene già gestita da bfcache, ovvero la percentuale di successi di bfcache. La seguente query suggerisce che questa particolare origine potrebbe essere già ben ottimizzata, dato il suo > Percentuali di hit del 60% per smartphone 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

Pertanto, sembrerebbe che l'elevata percentuale di back_forward sui telefoni non sia dovuta a un minore utilizzo di bfcache, ma a un riflesso del modo in cui gli utenti navigano e inoltrano di più sui telefoni.

Il modo più semplice per visualizzare 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 relativi a un mese di dati, ma nel tempo la cronologia si riempirà consentendoti di vedere le variazioni nei tipi di mese in mese.

Screenshot della schermata Distribuzione dei tipi di navigazione nella dashboard di CrUX che mostra i dati di un mese.
Tipi di navigazione nella dashboard di CrUX

Come puoi notare, abbiamo evidenziato i tipi di navigazione più veloce, che devono essere ottimizzati, nella parte superiore di questa pagina della Dashboard.

Conclusione

Ci auguriamo che le suddivisioni dei tipi di navigazione in CrUX ti siano utili e che ti aiutino a comprendere e ottimizzare le prestazioni del tuo sito. Garantendo un uso efficiente della memorizzazione nella cache HTTP, di bfcache e del prerendering, i siti possono ottenere caricamenti pagina molto più rapidi rispetto ai caricamenti di pagine che richiedono viaggi di ritorno al server.

Siamo inoltre lieti di rendere disponibili i dati in tutti i vari punti di accesso di CrUX, in modo che gli utenti possano utilizzare i dati come preferiscono e di vedere le suddivisioni dei tipi in base all'URL per gli utenti esposti nelle API di CrUX.

Ci piacerebbe ricevere il tuo feedback su questa aggiunta a CrUX sui social media o sul gruppo di discussione di CrUX.