À partir de l'ensemble de données de mars 2024, le rapport d'expérience utilisateur Chrome inclut une métrique navigation_types. Vous obtenez ainsi des statistiques agrégées sur les types de navigation de chargements de page pour la dimension interrogée.
Les statistiques de performances varient en fonction du type de navigation. 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é, cela se traduit généralement par une navigation quasi instantanée, qui se reflète dans des métriques LCP et FCP très faibles, ainsi que des métriques CLS et INP réduites.
En présentant 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 initialement disponible et une couverture hebdomadaire à complète au cours des six prochains mois), le dernier ensemble de données CrUX BigQuery et le tableau de bord CrUX. Les propriétaires de sites peuvent également voir l'évolution de l'utilisation du type de navigation au fil du temps. Cela peut permettre d'effectuer le suivi des améliorations (par exemple, la suppression du blocage du cache amélioré). Cela peut également vous aider à expliquer les changements dans les métriques, même si aucun changement n'a été apporté à leurs sites.
Quels sont les types de navigation disponibles dans CrUX ?
CrUX distingue les types de navigation suivants dans le tableau ci-dessous:
| Type | Description |
|---|---|
navigate |
Un chargement de page qui ne rentre dans aucune autre catégorie. |
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 beaucoup moins mis en cache. Lorsque cela est possible, la mise en cache locale et sur un CDN peut entraîner une amélioration notable des performances. |
reload |
L'utilisateur a rechargé la page soit en appuyant sur le bouton d'actualisation, en appuyant sur Entrée dans la barre d'adresse, soit en annulant la fermeture d'un onglet. L'actualisation d'une page entraîne souvent une nouvelle validation du serveur afin de vérifier si la page principale a été modifiée. Un pourcentage élevé d'actualisations de page peut indiquer de la frustration chez les utilisateurs. |
restore |
La page a été actualisée à la suite d'un redémarrage du navigateur ou après la suppression d'un onglet pour des raisons de mémoire. Pour Chrome sur Android, ces paramètres sont signalés en tant que reload. |
back_forward |
une navigation dans l'historique, ce qui signifie que la page a été vue et que l'utilisateur y a accédé récemment ; Avec une mise en cache correcte, l'expérience devrait être assez rapide, tout en nécessitant le traitement de la page et l'exécution du code JavaScript, ce qui est évité par le cache amélioré. |
back_forward_cache |
Navigation dans l'historique diffusée depuis le cache amélioré. Optimiser vos pages pour tirer parti du cache amélioré devrait permettre d'accélérer l'expérience. 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, comme avec le cache amélioré, peut entraîner des chargements quasi instantanés. |
Dans certains cas, le chargement d'une page peut combiner plusieurs types de navigation. Dans ce cas, CrUX signale la première correspondance dans l'ordre inverse du tableau précédent (de bas en haut).
Limites des types de navigation dans CrUX
CrUX étant 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 ne peut pas fournir de répartitions d'autres métriques par type de navigation, car cela réduirait davantage le nombre d'origines et d'URL disponibles dans CrUX.
Nous recommandons aux sites de mettre en œuvre leur propre service de surveillance des utilisateurs réels (RUM, Real User Monitoring) afin de pouvoir répartir le trafic selon des critères tels que les types de navigation. Notez que vous pouvez constater des différences au niveau des types de navigation dans ces solutions en fonction des types signalé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'utilisation de CrUX peut indiquer qu'il serait intéressant d'améliorer l'éligibilité au cache amélioré, l'API notRestoredReasons peut indiquer précisément pourquoi un chargement de page spécifique n'a pas pu être diffusé depuis le 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 qu'elles soient toutes 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 la procédure d'obtention de votre clé API et le guide de l'API. Un objet semblable à celui-ci sera 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 chargement de page pour chaque type de navigation. Chaque fraction est une valeur comprise entre 0.0 (indiquant 0% de chargements de page) et 1.0 (indiquant 100% de chargements de page) pour la clé donnée.
Cette réponse indique que pour la période de collecte commençant le 6 mars 2024 (jusqu'au 2 avril 2024 inclus), 6, 77% des navigations (chargements de pages) ont été diffusé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 une combinaison d'une URL ou d'une origine et d'un facteur de forme), le total des fractions navigation_types est égal à environ 1.
Types de navigation dans l'API CrUX History
L'API CrUX History peut fournir une série temporelle pour les types de navigation avec jusqu'à 25 points de données par fraction, ce qui permet de visualiser ces fractions au fil du temps. Pour passer de l'API CrUX à 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 à sept jours d'intervalle). Une fois les champs renseignés, il couvrira les 25 périodes de collecte. La visualisation de cet historique permet de confirmer que les optimisations ont pris effet ou ont régressé. Cela est particulièrement vrai pour la configuration du cache HTTP, qui optimise une page pour le cache amélioré et le prérendu.
Types de navigation dans CrUX BigQuery
Les tables BigQuery CrUX incluent désormais un enregistrement navigation_type de chaque type, tandis que les vues matérialisées récapitulatives incluent plusieurs colonnes navigation_types_* (une pour chaque type).
Tableaux détaillés
Le schéma de tableau détaillé dans BigQuery CrUX fournit des histogrammes détaillés pour les métriques de performances Web. Nous pouvons ainsi montrer dans cet exemple d'analyse la corrélation entre des types de navigation particuliers et des performances de chargement instantanées ou satisfaisantes.
À 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 d'affichage du LCP correct (good_lcp_density défini sur un LCP inférieur à 2 500 ms). Nous avons observé une forte corrélation statistique entre back_forward_cache et instant_lcp_density (BACKUP=0,87), comme l'illustre le graphique suivant, ainsi qu'une corrélation modérée entre back_forward_cache et good_lcp_density (Control=0,29).
Le Colab pour cette analyse est bien commenté. Ici, nous ne parlons que de la requête qui extrait les fractions "navigation_types" pour les 10 000 origines les plus populaires des tables détaillées dans BigQuery sur CrUX:
- Nous accédons à la table
all.202403ici (voir la clauseFROM), puis 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 (voir la clauseWHERE). - Lorsque vous interrogez la métrique
navigation_typesdans BigQuery, vous devez diviser par le total des fractionsnavigation_types, car elles ne s'additionneront que par origine, mais pas par combinaison (origine, facteur de forme). - Toutes les origines n'auront pas
navigation_types. Il est donc recommandé 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 cher) d'interroger les tables matérialisées à la place. Par exemple, la requête suivante extrait les données navigation_types disponibles de la table chrome-ux-report.materialized.device_summary. Cette table est classée par mois, origine et 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 n'est 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, et non par point de départ et appareil et par date. Vous pouvez ainsi voir 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'origine https://www.google.com: 6,63% de ces chargements de pages 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 considérablement plus élevé sur phone suggère que nous pourrions essayer d'optimiser ces chargements de page pour qu'ils puissent être diffusés à partir du cache amélioré.
Cependant, il est également important de prendre en compte la fraction des chargements de page déjà traitée par le cache amélioré, c'est-à-dire le taux d'accès au cache amélioré. La requête suivante suggère que cette origine spécifique est peut-être déjà bien optimisée, étant donné son taux de succès supérieur à 60% pour les mobiles 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 semble donc que le taux de back_forward élevé sur les téléphones ne soit pas dû à une utilisation réduite du cache amélioré, mais plutôt à la façon dont les utilisateurs naviguent en arrière et avancent davantage sur les téléphones.
Types de navigation dans le tableau de bord CrUX
Le moyen le plus simple de voir les types de navigation consiste à utiliser le tableau de bord CrUX, accessible pour une origine en cliquant sur ce lien. Comme vous pouvez le voir sur la capture d'écran suivante, seules les données d'un mois sont disponibles au départ, mais au fil du temps, l'historique se remplira pour vous permettre de voir les modifications des types d'un mois sur l'autre.
Comme vous pouvez le voir également, nous avons mis en évidence les types de navigation plus rapides que les sites doivent chercher à optimiser, en haut de cette page du tableau de bord.
Conclusion
Nous espérons que la répartition par type de navigation dans CrUX vous sera utile, et qu'elle vous aidera à comprendre et à optimiser les performances de votre site. En utilisant efficacement la mise en cache HTTP, le cache amélioré et le prérendu, les sites peuvent obtenir des chargements de page beaucoup plus rapides que ceux nécessitant un retour vers le serveur.
Nous sommes également heureux de rendre les données disponibles dans tous les points d'accès CrUX afin que les utilisateurs puissent les utiliser comme ils le souhaitent et voir la répartition par URL des données exposées dans les API CrUX.
Nous aimerions connaître votre avis sur cet ajout à CrUX sur les réseaux sociaux ou sur le groupe de discussion CrUX.