Les données brutes du rapport UX Chrome (CrUX) sont disponibles dans BigQuery, une base de données sur Google Cloud. L'utilisation de BigQuery nécessite un projet GCP et des connaissances de base en SQL.
Dans ce guide, vous allez apprendre à utiliser BigQuery pour écrire des requêtes sur l'ensemble de données CrUX afin d'extraire des résultats pertinents sur l'état des expériences utilisateur sur le Web :
- Comprendre comment les données sont organisées
- Écrire une requête de base pour évaluer les performances d'une origine
- Écrire une requête avancée pour suivre les performances au fil du temps
Organisation des données
Commencez par examiner une requête de base :
SELECT COUNT(DISTINCT origin) FROM `chrome-ux-report.all.202206`
Pour exécuter la requête, saisissez-la dans l'éditeur de requête, puis cliquez sur le bouton "Exécuter la requête" :
Cette requête comporte deux parties :
SELECT COUNT(DISTINCT origin)signifie que vous interrogez le nombre d'origines dans la table. En gros, deux URL font partie de la même origine si elles ont le même schéma, le même hôte et le même port.FROM chrome-ux-report.all.202206spécifie l'adresse de la table source, qui comporte trois parties :- Le nom du projet Cloud
chrome-ux-reportdans lequel toutes les données CrUX sont organisées - L'ensemble de données
all, qui représente les données de tous les pays - La table
202206, qui correspond à l'année et au mois des données au format AAAAMM
- Le nom du projet Cloud
Il existe également des ensembles de données pour chaque pays. Par exemple, chrome-ux-report.country_ca.202206 ne représente que les données d'expérience utilisateur provenant du Canada.
Dans chaque ensemble de données, il existe des tables pour chaque mois depuis octobre 2017. De nouvelles tables pour le mois calendaire précédent sont publiées régulièrement.
La structure des tables de données (également appelée schéma) contient les éléments suivants :
- L'origine, par exemple
origin = 'https://www.example.com', qui représente la distribution globale de l'expérience utilisateur pour toutes les pages de ce site Web - La vitesse de connexion au moment du chargement de page, par exemple
effective_connection_type.name = '4G'(supprimée à partir de février 2025) - Le type d'appareil, par exemple
form_factor.name = 'desktop' - Les métriques UX elles-mêmes
Les données de chaque métrique sont organisées sous forme de tableau d'objets. En notation JSON, first_contentful_paint.histogram.bin se présente comme suit :
[
{"start": 0, "end": 100, "density": 0.1234},
{"start": 100, "end": 200, "density": 0.0123},
...
]
Chaque compartiment contient une heure de début et de fin en millisecondes, ainsi qu'une densité représentant le pourcentage d'expériences utilisateur dans cette plage de temps. En d'autres termes, 12, 34% des expériences FCP pour cette origine, cette vitesse de connexion et ce type d'appareil hypothétiques sont inférieures à 100 ms. La somme de toutes les densités de compartiment est de 100%.
Parcourez la structure des tables dans BigQuery.
Évaluer les performances
Nous pouvons utiliser nos connaissances du schéma de table pour écrire une requête qui extrait ces données sur les performances.
SELECT
fcp
FROM
`chrome-ux-report.all.202502`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
form_factor.name = 'phone' AND
fcp.start = 0
Le résultat est 0.01115, ce qui signifie que 1,115% des expériences utilisateur sur cette origine sont comprises entre 0 et 100 ms sur la 4G et sur un téléphone. Si nous voulons généraliser notre requête à n'importe quelle connexion et à n'importe quel type d'appareil, nous pouvons les omettre de la clause WHERE et utiliser la fonction d'agrégation SUM pour additionner toutes leurs densités de compartiment respectives :
SELECT
SUM(fcp.density)
FROM
`chrome-ux-report.all.202206`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
fcp.start = 0
Le résultat est 0.05355, soit 5,355% sur tous les appareils et types de connexion. Nous pouvons modifier légèrement la requête et additionner les densités de tous les compartiments qui se trouvent dans la plage FCP "rapide" de 0 à 1 000 ms :
SELECT
SUM(fcp.density) AS fast_fcp
FROM
`chrome-ux-report.all.202206`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
fcp.start < 1000
Cela nous donne 0.6977. En d'autres termes, 69,77% des expériences utilisateur FCP sur web.dev sont considérées comme "rapides" selon la définition de la plage FCP.
Suivre les performances
Maintenant que nous avons extrait les données sur les performances d'une origine, nous pouvons les comparer aux données historiques disponibles dans les tables plus anciennes. Pour ce faire, nous pouvons réécrire l'adresse de la table pour un mois antérieur ou utiliser la syntaxe de caractère générique pour interroger tous les mois :
SELECT
_TABLE_SUFFIX AS yyyymm,
SUM(fcp.density) AS fast_fcp
FROM
`chrome-ux-report.all.*`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
fcp.start < 1000
GROUP BY
yyyymm
ORDER BY
yyyymm DESC
Nous constatons ici que le pourcentage d'expériences FCP rapides varie de quelques points de pourcentage chaque mois.
| aaaamm | fast_fcp |
|---|---|
| 202206 | 69,77% |
| 202205 | 70,71% |
| 202204 | 69,04% |
| 202203 | 69,82% |
| 202202 | 67,75% |
| 202201 | 58,96% |
| 202112 | 41,69% |
| … | … |
Grâce à ces techniques, vous pouvez rechercher les performances d'une origine, calculer le pourcentage d'expériences rapides et les suivre au fil du temps. Ensuite, essayez d'interroger deux origines ou plus et de comparer leurs performances.
Questions fréquentes
Voici quelques-unes des questions fréquentes concernant l'ensemble de données CrUX BigQuery :
Quand dois-je utiliser BigQuery plutôt que d'autres outils ?
BigQuery n'est nécessaire que lorsque vous ne pouvez pas obtenir les mêmes informations à partir d'autres outils tels que CrUX Vis et PageSpeed Insights. Par exemple, BigQuery vous permet de segmenter les données de manière significative et même de les joindre à d'autres ensembles de données publics tels que HTTP Archive pour effectuer une exploration de données avancée.
L'utilisation de BigQuery est-elle soumise à des limites ?
Oui, la limite la plus importante est que, par défaut, les utilisateurs ne peuvent interroger que 1 To de données par mois. Au-delà, le tarif standard de 5 $/To s'applique.
Où puis-je trouver des informations sur BigQuery ?
Pour en savoir plus, consultez la documentation BigQuery.