# De PageSpeed Insights au CrUX Report : dix ans de mesure de la performance web

> Chaque nouvel outil de mesure de Google a redéfini ce que les développeurs WordPress considèrent comme « rapide ». Retour sur une décennie d'évolution des instruments.

- Auteur : Clément Hadrot
- Publié le : 2024-03-02
- Mis à jour le : 2024-03-02
- Catégorie : Performance
- URL : https://wpmoderne.dev.wordpress-developpement.fr/performance/pagespeed-insights-crux-dix-ans-mesure/

## L’essentiel

- PageSpeed Insights notait des règles techniques, pas l'expérience réelle
- Le CrUX Report a introduit des données de vrais visiteurs
- Les Core Web Vitals ont unifié la mesure autour de trois axes

« Optimisez la mise en cache du navigateur », « réduisez le temps de réponse du serveur » : ces recommandations génériques, produites par les premières versions de Google PageSpeed Insights, ont façonné pendant des années la façon dont les développeurs WordPress abordaient la performance, souvent en cochant des cases sans toujours comprendre l'impact réel sur un visiteur.

Retracer l'évolution des outils de mesure successifs de Google permet de comprendre pourquoi la définition même de « site rapide » a changé plusieurs fois en une décennie, et pourquoi les pratiques d'optimisation d'aujourd'hui ne ressemblent plus à celles d'il y a dix ans.

## La première génération : des règles, pas des mesures réelles

Les premières versions de PageSpeed Insights fonctionnaient sur un principe simple : une analyse statique de la page, comparée à une liste de bonnes pratiques génériques (minification des fichiers, compression des images, mise en cache des ressources statiques). Le score obtenu ne reflétait pas une mesure de temps de chargement réel, mais un taux de conformité à ces règles, ce qui pouvait conduire à des optimisations sans effet perceptible pour un visiteur réel, tout en négligeant des aspects que ces règles ne couvraient pas.

## L'arrivée de Lighthouse : simuler un chargement réel

Avec l'intégration de Lighthouse, l'approche a changé de nature : l'outil charge réellement la page dans un navigateur automatisé, dans des conditions réseau et processeur simulées, et mesure des métriques concrètes comme le temps avant le premier rendu ou le temps avant que la page devienne interactive. Cette approche, plus proche de l'expérience réelle qu'une simple liste de règles, reste cependant une simulation en laboratoire, réalisée dans des conditions contrôlées qui ne reflètent pas toujours la diversité des appareils et des connexions des visiteurs réels d'un site.

> L'essentiel à retenir : PageSpeed Insights notait des règles techniques, pas l'expérience réelle ; Le CrUX Report a introduit des données de vrais visiteurs ; Les Core Web Vitals ont unifié la mesure autour de trois axes

## Le CrUX Report : des données de vrais visiteurs

Le Chrome User Experience Report a marqué un tournant en introduisant des données agrégées, collectées auprès de visiteurs réels utilisant le navigateur Chrome, ayant accepté de partager leurs statistiques d'usage. Contrairement aux mesures en laboratoire, ce rapport reflète des conditions réseau et des appareils réellement rencontrés par les visiteurs d'un site donné, avec toute la diversité que cela implique : connexions mobiles lentes, ordinateurs anciens, réseaux saturés.

Cette bascule vers des données de terrain a changé la façon dont les développeurs WordPress interprètent leurs résultats : un score excellent en laboratoire, obtenu sur une machine de développement puissante et une connexion rapide, peut coexister avec des données de terrain nettement moins favorables, révélant un écart entre l'environnement de test et la réalité du trafic du site.

## Les Core Web Vitals : une unification autour de trois axes

Annoncés par Google en mai 2020, les Core Web Vitals ont regroupé la mesure de la performance perçue autour de trois axes principaux : la vitesse de chargement du contenu principal (LCP), la stabilité visuelle pendant le chargement (CLS), et la réactivité aux interactions, mesurée à l'origine par le First Input Delay (FID). Cette unification a donné un vocabulaire commun aux développeurs, aux outils de mesure et aux moteurs de recherche, remplaçant une multitude d'indicateurs disparates par un socle partagé.

Le FID lui-même est aujourd'hui remis en question par Google, qui prépare son remplacement par l'Interaction to Next Paint (INP), une métrique plus complète qui mesure la réactivité sur l'ensemble des interactions d'une session plutôt que sur la seule première interaction. Cette transition, encore en cours au moment de la rédaction de cet article, illustre bien que la mesure de la performance web reste un chantier vivant, jamais figé une fois pour toutes.

## Ce que cette histoire enseigne aux développeurs WordPress

- Un score d'outil de mesure n'est jamais une fin en soi, mais un indicateur d'un moment donné, avec sa propre méthodologie et ses propres limites.
- Les données de terrain (CrUX) et les données de laboratoire (Lighthouse) répondent à des questions différentes et se complètent, elles ne se substituent pas l'une à l'autre.
- Une métrique qui semble définitive aujourd'hui peut être révisée demain : rester attentif aux annonces officielles de Google évite d'optimiser pour un indicateur en cours d'abandon.

## En résumé

Dix ans après les premières versions de PageSpeed Insights, la mesure de la performance web a gagné en rigueur et en réalisme, en s'appuyant progressivement sur des données de visiteurs réels plutôt que sur de simples règles génériques. Suivre cette évolution reste indispensable pour tout développeur WordPress qui veut optimiser ce qui compte réellement, et non ce qu'un outil mesurait il y a une décennie.
