Les données brutes du rapport d'expérience utilisateur Chrome (CrUX) sont disponibles sur BigQuery, une base de données sur Google Cloud. L'utilisation de BigQuery nécessite un projet GCP et des connaissances de base de SQL.
Dans ce guide, découvrez comment utiliser BigQuery pour écrire des requêtes sur l'ensemble de données CrUX et extraire des résultats pertinents concernant l'état de l'expérience 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
- Rédiger 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 se compose de deux parties:
SELECT COUNT(DISTINCT origin)
consiste à interroger le nombre d'origines de la table. Pour faire simple, deux URL ont 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.202206
spécifie l'adresse de la table source, qui se compose de trois parties:- Nom du projet Cloud
chrome-ux-report
dans lequel toutes les données CrUX sont organisées - L'ensemble de données
all
, représentant les données de tous les pays - Le tableau
202206
, l'année et le mois des données au format AAAAMM
- Nom du projet Cloud
Il existe également des jeux de données pour chaque pays. Par exemple, chrome-ux-report.country_ca.202206
ne représente que les données sur l'expérience utilisateur provenant du Canada.
Dans chaque jeu de données, il y a des tables pour chaque mois depuis 201710. Les nouvelles tables du 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 répartition globale de l'expérience utilisateur pour toutes les pages de ce site Web - Vitesse de connexion au moment du chargement de la page (par exemple,
effective_connection_type.name = '4G'
) - Type d'appareil (par exemple,
form_factor.name = 'desktop'
) - Les métriques de l'expérience utilisateur elles-mêmes
- first_paint (FP)
- first_contentful_paint (FCP)
- dom_content_loading (DCL)
- onload (OL)
- expérimentale.first_input_delay (FID)
Les données de chaque métrique sont organisées sous la forme d'un tableau d'objets. En notation JSON, first_contentful_paint.histogram.bin
ressemblerait à ceci:
[
{"start": 0, "end": 100, "density": 0.1234},
{"start": 100, "end": 200, "density": 0.0123},
...
]
Chaque classe contient une heure de début et une heure de fin en millisecondes et une densité représentant le pourcentage d'expériences utilisateur au cours de cette période. 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 bins est de 100%.
Parcourir la structure des tables dans BigQuery
Évaluez les performances
Nous pouvons mettre à profit notre connaissance du schéma de la table pour écrire une requête qui extrait ces données de performances.
SELECT
fcp
FROM
`chrome-ux-report.all.202206`,
UNNEST(first_contentful_paint.histogram.bin) AS fcp
WHERE
origin = 'https://web.dev' AND
effective_connection_type.name = '4G' 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 durent entre 0 et 100 ms en 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 dans la clause WHERE
et utiliser la fonction d'agrégateur SUM
pour additionner toutes leurs densités de bin 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
Résultat : 0.05355
, soit 5,355% pour tous les appareils et types de connexions. Nous pouvons modifier légèrement la requête et additionner les densités de tous les bins compris dans la plage FCP "rapide" comprise entre 0 et 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
Nous obtenons ainsi 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 de performances d'une origine, nous pouvons les comparer aux données historiques disponibles dans les anciennes tables. Pour ce faire, nous pourrions réécrire l'adresse de la table vers un mois antérieur ou utiliser la syntaxe 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
Ici, nous constatons 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% |
... | ... |
Ces techniques vous permettent de rechercher les performances d'une origine, de calculer le pourcentage d'expériences rapides et d'en effectuer le suivi au fil du temps. L'étape suivante consiste à interroger deux origines ou plus et à comparer leurs performances.
Questions fréquentes
Voici quelques questions fréquentes sur l'ensemble de données CrUX BigQuery:
Quand utiliser BigQuery plutôt que d'autres outils ?
BigQuery n'est nécessaire que si vous ne pouvez pas obtenir les mêmes informations avec d'autres outils tels que le tableau de bord CrUX 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 l'archive HTTP, afin d'effectuer une exploration avancée de données.
Existe-t-il des limites à l'utilisation de BigQuery ?
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 en savoir plus sur BigQuery ?
Pour en savoir plus, consultez la documentation BigQuery.