À 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.
Quels types de navigation sont disponibles dans CrUX ?
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:
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).
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.202403ici (voir la clauseFROM), puis nous filtronsform_factorsurphoneet 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 clauseWHERE). - Lorsque vous interrogez la métrique
navigation_typesdans BigQuery, vous devez la diviser par le total des fractionsnavigation_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'utiliserSAVE_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.
Types de navigation dans le tableau de bord CrUX
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">
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.