Types de navigation d�sormais disponibles dans CrUX

� partir de l'ensemble de donn�es de mars 2024, le rapport sur l'exp�rience utilisateur Chrome inclut une m�trique navigation_types. Vous obtenez ainsi des statistiques agr�g�es sur les types de navigation lors des chargements de page pour la dimension interrog�e.

Les diff�rents types de navigation peuvent entra�ner des diff�rences au niveau des m�triques de performances. Par cons�quent, lorsque vous examinez les performances de votre site, il est utile de comprendre la fr�quence relative de ces diff�rents types. Par exemple, lorsqu'une navigation utilise le cache am�lior� (bfcache), la navigation est g�n�ralement quasi instantan�e, ce qui se traduit par des m�triques LCP et FCP tr�s faibles, et une diminution des m�triques CLS et INP.

En exposant la r�partition par type de navigation, nous esp�rons encourager les propri�taires de sites � mieux conna�tre les types de navigation utilis�s sur leurs sites, et nous cherchons � encourager certains des types plus rapides en examinant la configuration de la mise en cache, les bloqueurs de cache am�lior� et le pr�rendu.

La m�trique navigation_types est disponible dans l'API CrUX quotidienne, l'API CrUX History (avec un historique de trois semaines disponible dans un premier temps et une couverture �largie chaque semaine jusqu'� une couverture compl�te au cours des six prochains mois), le dernier ensemble de donn�es BigQuery CrUX et le tableau de bord CrUX. Cet historique permet �galement aux propri�taires de sites de voir les changements dans l'utilisation du type de navigation au fil du temps. Cela permet de suivre les am�liorations (par exemple, la suppression du blocage du cache am�lior�). Cela peut �galement aider � expliquer les variations des m�triques, m�me si les sites n'ont pas �t� modifi�s.

CrUX distingue les types de navigation suivants dans le tableau suivant:

Type Description
navigate Un chargement de page qui n'entre dans aucune des autres cat�gories.
navigate_cache Chargement de page pour lequel la ressource principale (le document HTML principal) a �t� diffus�e � partir du cache HTTP. Les sites utilisent souvent la mise en cache pour les sous-ressources, mais le document HTML principal est souvent consid�rablement moins mis en cache. Lorsque c'est possible, la mise en cache locale et au niveau d'un CDN peut am�liorer sensiblement les performances.
reload L'utilisateur a actualis� la page en appuyant sur le bouton d'actualisation, en appuyant sur la touche Entr�e dans la barre d'adresse ou en annulant la fermeture d'un onglet. L'actualisation des pages entra�ne souvent une nouvelle validation vers le serveur pour v�rifier si la page principale a �t� modifi�e. Un pourcentage �lev� d'actualisations de pages peut indiquer de la frustration chez les utilisateurs.
restore La page a �t� actualis�e apr�s le red�marrage du navigateur ou un onglet qui a �t� supprim� pour des raisons de m�moire. Pour Chrome sur Android, ils sont signal�s comme reload � la place.
back_forward Navigation dans l'historique, c'est-�-dire que la page a �t� vue et que vous avez r�cemment acc�d� � celle-ci Avec une mise en cache appropri�e, ces exp�riences devraient �tre relativement rapides, mais n�cessiter tout de m�me le traitement de la page et l'ex�cution de JavaScript, deux �l�ments qui sont �vit�s par le cache am�lior�.
back_forward_cache Une navigation dans l'historique diffus�e � partir du cache am�lior�. L'optimisation de vos pages pour tirer parti du cache am�lior� devrait permettre d'obtenir des exp�riences plus rapides. Les sites devraient chercher � supprimer les bloqueurs de cache am�lior� pour am�liorer le pourcentage de navigations dans cette cat�gorie.
prerender La page a �t� pr�rendue, ce qui peut entra�ner un chargement quasi instantan�, comme pour le cache am�lior�.

Dans certains cas, un chargement de page peut �tre une combinaison de plusieurs types de navigation. Dans ce cas, l'exp�rience utilisateur Chrome indique la premi�re correspondance dans l'ordre inverse du tableau pr�c�dent (de bas en haut).

Limites des types de navigation dans CrUX

�tant donn� que l'exp�rience utilisateur CrUX est un ensemble de donn�es public, la pr�cision de ses rapports est limit�e. Pour de nombreuses origines et URL, la m�trique navigation_types n'est pas disponible en raison d'un trafic �ligible insuffisant. Pour en savoir plus, consultez la m�thodologie CrUX.

De plus, CrUX n'est pas en mesure de fournir des r�partitions des autres m�triques par type de navigation, car cela r�duirait encore davantage le nombre d'origines et d'URL disponibles dans CrUX.

<ph type="x-smartling-placeholder">

Nous recommandons aux sites de mettre en œuvre leur propre système de surveillance des utilisateurs réels (RUM, Real User Monitoring) afin de pouvoir répartir le trafic en fonction de critères tels que le type de navigation. Notez que vous pouvez constater des différences de types de navigation dans ces solutions en fonction des types indiqués et des pages vues incluses. Consultez l'article Pourquoi les données CrUX sont-elles différentes de mes données RUM ?

Le RUM peut également fournir des informations plus détaillées sur des problèmes de performances spécifiques. Par exemple, si l'expérience utilisateur CrUX peut suggérer qu'il serait intéressant d'améliorer l'éligibilité au cache amélioré, l'API bfcache notRestaurerdReasons peut indiquer exactement pourquoi un chargement de page particulier n'a pas pu être diffusé à partir du cache amélioré.

Types de navigation dans l'API CrUX

Pour afficher les types de navigation dans l'API, incluez la métrique navigation_types dans la requête, ou ne définissez pas de métrique afin que toutes les métriques soient incluses:

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"]}'

Le format de la requ�te est d�crit plus en d�tail dans la documentation de l'API, y compris une explication sur la fa�on d'obtenir votre cl� API et le guide de l'API. Un objet semblable � celui-ci est renvoy�:

{
  "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 }
    }
  }
}

Dans la r�ponse, CrUX signale la m�trique navigation_types en tant qu'objet avec les fractions de chargements de page pour chaque type de navigation. Chaque fraction est une valeur comprise entre 0.0 (indiquant 0% des chargements de page) et 1.0 (indiquant 100% des chargements de page) pour la cl� donn�e.

Comme vous pouvez le voir dans cette r�ponse, pour la p�riode de collecte � partir du 6 mars 2024 (jusqu'au 2 avril 2024 inclus) : 6, 77% des navigations (chargements de page) ont �t� effectu�es � partir du cache am�lior� du navigateur. De m�me, d'autres fractions peuvent vous aider � identifier des opportunit�s d'optimisation du chargement des pages. Notez que pour une cl� donn�e (y compris la combinaison d'une URL ou d'une origine et d'un facteur de forme), le total des fractions navigation_types est d'environ 1,0.

Types de navigation dans l'API CrUX History

L'API CrUX History peut fournir une s�rie temporelle pour les types de navigation comportant jusqu'� 25 points de donn�es par fraction, ce qui vous permet de visualiser ces fractions au fil du temps. Pour remplacer votre requ�te de l'API CrUX par l'API CrUX History, ex�cutez-la sur le point de terminaison queryHistoryRecord au lieu de queryRecord. Par exemple, notre Colab sur l'historique CrUX repr�sente la m�trique navigation_types sous forme de barres empil�es:

<ph type="x-smartling-placeholder">
</ph> Graphique � barres empil�es affichant l&#39;historique des types de navigation sur trois semaines, la majorit� des �l�ments de navigation �tant la navigation sans changement majeur
pendant les trois semaines.
Types de navigation au fil du temps
.

Dans la capture d'�cran pr�c�dente, l'historique n'est disponible que pour trois p�riodes de collecte (28 jours chacune, 7 jours d'intervalle). Une fois les donn�es renseign�es, ces champs couvrent les 25 p�riodes de collecte. En visualisant cet historique, vous pouvez v�rifier que les optimisations ont bien �t� prises en compte ou ont r�gress�. Cela est particuli�rement vrai pour la configuration du cache HTTP, l'optimisation d'une page pour le cache am�lior� et le pr�rendu.

Types de navigation dans BigQuery CrUX

Les tables BigQuery CrUX incluent d�sormais un enregistrement navigation_type, de chaque type, tandis que les vues r�capitulatives mat�rialis�es comprennent plusieurs colonnes navigation_types_*, une pour chaque type.

Tableaux d�taill�s

Le sch�ma de table d�taill�e dans BigQuery CrUX fournit des histogrammes d�taill�s des m�triques de performances Web. Ils nous permettent de montrer dans cet exemple d'analyse comment certains types de navigation peuvent �tre corr�l�s � des performances de chargement instantan�es ou bonnes.

� titre d'exemple, nous avons examin� la fraction back_forward_cache et sa corr�lation avec la fr�quence de chargement instantan� des pages (instant_lcp_density d�fini comme LCP <= 200 ms) et la fr�quence � laquelle un LCP bon a �t� observ� (good_lcp_density d�fini comme LCP <= 2 500 ms). Nous avons observ� une forte corr�lation statistique entre back_forward_cache et instant_lcp_density (PER=0,87), comme illustr� dans le graphique suivant, ainsi qu'une corr�lation mod�r�e entre back_forward_cache et good_lcp_density (= 0,29).

<ph type="x-smartling-placeholder">
</ph> Graphique de corr�lation illustrant une forte corr�lation entre la part des chargements de pages instantan�s et celle des chargements de pages en cache am�lior�
Corr�lation entre les chargements de page instantan�s et l'utilisation du cache am�lior�
.

Le Colab pour cette analyse est bien comment�. Nous ne parlerons ici que de la requ�te qui extrait les fractions navigation_types pour les 10 000 origines les plus populaires � partir des tables d�taill�es dans BigQuery en CrUX:

  • Nous acc�dons � la table all.202403 ici (voir la clause FROM), puis nous filtrons form_factor sur phone et s�lectionnons les origines dont le classement de popularit� est inf�rieur ou �gal � 10 000 pour les 10 000 origines les plus populaires les plus populaires (voir la clause WHERE).
  • Lorsque vous interrogez la m�trique navigation_types dans BigQuery, vous devez la diviser par le total des fractions navigation_types, car elles s'additionnent uniquement par origine, mais pas par combinaison (origine, facteur de forme).
  • Toutes les origines n'ont pas navigation_types. Nous vous recommandons donc d'utiliser 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

Tables mat�rialis�es

Lorsqu'un r�sum� est suffisant, il est souvent plus rapide (et moins co�teux) d'interroger les tables mat�rialis�es. Par exemple, la requ�te suivante extrait les donn�es navigation_types disponibles de la table chrome-ux-report.materialized.device_summary. Ce tableau est organis� par mois, par origine et par type d'appareil.

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

Notez que la somme de ces fractions ne sera pas �gale � 1, 0 par ligne.Il est donc n�cessaire de diviser chaque fraction par la somme des r�sultats sur lesquels la requ�te doit �tre interpr�t�e.

En effet, les fractions navigation_type dans chrome-ux-report.materialized.device_summary, comme les densit�s d'histogramme, ajoutent jusqu'� 1,0 par origine au lieu de par origine et appareil par date. Cela vous permet d'afficher la r�partition des types de navigation entre les appareils:

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

Dans ce r�sultat de requ�te, les fractions refl�tent le pourcentage de chargements de page pour l'https://www.google.com d'origine: 6,63% de ces chargements de page avaient le type de navigation back_forward sur t�l�phone, 1,79% sur ordinateur et 0,09% sur tablette.

Le pourcentage de back_forward nettement plus �lev� sur phone sugg�re que nous pourrions essayer d'optimiser ces chargements de page afin qu'ils puissent �tre diffus�s � partir du cache am�lior�.

Cependant, il est �galement important de prendre en compte la fraction de chargements de page d�j� servie par le cache am�lior�, c'est-�-dire le taux de succ�s de cache am�lior�. La requ�te suivante sugg�re que cette origine sp�cifique est peut-�tre d�j� bien optimis�e, compte tenu de ses > Un taux de lecture de 60% sur les t�l�phones et les ordinateurs

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

Il semblerait donc que le taux de back_forward �lev� sur les t�l�phones ne soit pas d� � une baisse de l'utilisation du cache am�lior�, mais plut�t � la fa�on dont les utilisateurs naviguent vers l'avant et l'avant sur leur t�l�phone.

Le moyen le plus simple de visualiser les types de navigation est d'utiliser le tableau de bord CrUX, accessible via ce lien pour chaque origine. Comme vous pouvez le voir sur la capture d'�cran suivante, seules les donn�es d'un mois sont initialement disponibles, mais au fil du temps, l'historique se remplira pour vous permettre de voir les changements de types mois apr�s mois.

<ph type="x-smartling-placeholder">
</ph> Capture de l&#39;�cran de distribution des types de navigation dans le tableau de bord CrUX montrant l&#39;�quivalent d&#39;un mois de donn�es.
Types de navigation dans le tableau de bord CrUX
.

Comme vous pouvez �galement le voir, nous avons mis en �vidence en haut de cette page du tableau de bord les types de navigation plus rapides que les sites doivent chercher � optimiser.

Conclusion

Nous esp�rons que ces informations vous seront utiles, et qu'elles vous aideront � comprendre et � optimiser les performances de votre site. En assurant une utilisation efficace de la mise en cache HTTP, du cache am�lior� et du pr�rendu, les sites peuvent effectuer des chargements de page beaucoup plus rapides que ceux qui n�cessitent un retour sur le serveur.

Nous sommes �galement ravis de rendre les donn�es disponibles dans tous les points d'acc�s CrUX afin que les utilisateurs puissent les consulter comme ils le souhaitent et voir la r�partition par type par URL pour les donn�es pr�sent�es dans les API CrUX.

Nous aimerions conna�tre votre avis sur cet ajout � l'exp�rience utilisateur CrUX sur les r�seaux sociaux ou via le groupe de discussion CrUX.