La performance web est le domaine où l'écart est le plus grand entre ce qu'on mesure et ce qu'on améliore. Il est parfaitement possible d'atteindre un score de laboratoire excellent sur un site dont l'expérience réelle reste médiocre — et l'inverse existe aussi. Cette dissociation n'est pas un défaut des outils : elle vient de ce qu'ils mesurent des choses différentes.
Un test de laboratoire simule un chargement dans des conditions fixées : un appareil donné, une connexion donnée, un cache vide. C'est reproductible, donc utile au diagnostic. Les données de terrain, elles, agrègent les visites réelles — tous appareils, toutes connexions, tous états de cache confondus. Ce sont ces dernières qui déterminent l'évaluation d'un site, et elles sont lues au 75e centile : améliorer l'expérience de la moitié des visiteurs ne suffit pas si le quart le plus mal loti reste au-delà des seuils.
Les trois métriques retenues comme signaux — le temps d'affichage du plus grand élément, la réactivité aux interactions et la stabilité visuelle — ont été choisies parce qu'elles correspondent à des irritants concrets : attendre que la page apparaisse, cliquer sans réaction, voir le contenu bouger sous le curseur. Ce ne sont pas des abstractions techniques mais la traduction chiffrée d'une expérience.
Sur WordPress, la difficulté est particulière. Le socle est rarement en cause : les problèmes viennent de l'accumulation — un thème lourd, une dizaine d'extensions chargeant chacune ses ressources sur toutes les pages, des polices distantes, des images non dimensionnées. Aucun de ces éléments n'est catastrophique isolément ; leur somme l'est. La bonne approche consiste donc moins à optimiser qu'à retirer.
Cette rubrique privilégie les leviers qui déplacent réellement les métriques de terrain, en signalant au passage les optimisations populaires dont l'effet mesuré est négligeable.