Google a fermé Test My Site il y a quelques années, et peu de monde l’a remarqué. L’outil, accessible à l’adresse testmysite.withgoogle.com, proposait en une page épurée de saisir une URL et d’obtenir un score de « performance mobile » sur 100, avec une poignée de recommandations basiques. L’expérience était léchée, conçue pour un public non technique. C’était aussi un miroir déformant.
J’ai ressorti des archives une capture de l’outil sur trois de mes side-projects de l’époque. Le verdict était quasi identique à chaque fois : un score en ergonomie mobile, un score en vitesse sur mobile, un score en vitesse sur ordinateur. Le détail des optimisations égrenait des évidences : « utiliser le cache navigateur », « optimiser les images », « éliminer les scripts qui bloquent le rendu ». Des conseils utiles pour un site vitrine WordPress en 2016. Sauf que mes projets tournaient déjà sur du rendu côté serveur avec React, et que le goulot d’étranglement réel n’était pas le cache, mais l’hydratation d’un bundle de 400 Ko sur un réseau 4G.
Un artefact de la croisade AMP
Test My Site n’est pas apparu par hasard. L’outil a été lancé au moment où Google poussait massivement les pages AMP, ces versions allégées de pages web servies depuis un cache CDN maison avec une priorité de préchargement exclusive. Si vous saisissiez l’URL d’une page classique, l’outil s’empressait de vous suggérer d’en créer une version AMP pour améliorer votre score. Le message implicite : sans AMP, votre site mobile resterait lent. C’était une stratégie d’adoption déguisée en diagnostic.
⚠️ Attention : Depuis 2021, AMP n’est plus un prérequis pour figurer dans le carrousel Top Stories de Google. Le format a été relégué à l’état de framework comme un autre. Les scores de Test My Site appartiennent à cette époque révolue.
Ce que l’outil ne montrait pas, c’est le coût réel du passage en AMP. Migrer ses templates, maintenir un balisage parallèle, abandonner une partie de son JavaScript : des choix d’architecture lourds qu’on ne prend pas en lisant un score sur 100. Pour les sites e-commerce ou les applis web dotées d’une couche de state management React avec Zustand, la compatibilité AMP relevait du saut dans le vide.
Le score unique, ce glouton cognitif
Le vrai défaut de Test My Site tenait à son interface. En mettant en avant un chiffre global, l’outil effaçait l’information différenciante. Un score de 73/100 ne dit pas si le LCP (Largest Contentful Paint) est à 2,3 secondes ou à 5 secondes. Il ne distingue pas un TTFB décent d’un First Input Delay qui explose sur mobile bas de gamme. Or, quand on audite une page qui génère du chiffre d’affaires, c’est précisément ce niveau de granularité qui permet d’identifier un middleware de cache défaillant ou une cascade de requêtes API non résolues.
Le piège s’aggravait avec le bouton « Recevoir le rapport par email ». Google vous envoyait un résumé lissé et vous inscrivait à une liste de diffusion « pour améliorer votre site ». Une boucle de feedback qui renforçait la dépendance au score plutôt qu’à la compréhension des métriques sous-jacentes. En agence, j’ai vu des chefs de projet brandir ce rapport en réunion comme preuve de performance, alors que le LCP réel de la page dépassait les 4 secondes.
Mesurer ce que les utilisateurs subissent vraiment
Aujourd’hui, un audit de Core Web Vitals ne ressemble plus du tout à une page unique avec un score. Il combine trois sources distinctes : les données de laboratoire (Lighthouse en simulation réseau stable), les données de terrain (Chrome User Experience Report dans la Search Console), et les métriques mesurées en continu via un RUM (Real User Monitoring) maison ou outillé. Chacune répond à une question différente.
Les données de laboratoire disent « cette page, dans des conditions contrôlées, affiche tel LCP ». Les données de terrain disent « les vrais visiteurs, sur 4G faiblarde et avec le cache froid, ont subi tel INP le mois dernier ». Un écart entre les deux révèle souvent une infrastructure de cache qui fonctionne mal en conditions réelles, un CDN qui se dégrade sur certaines zones géographiques, ou un troisième script publicitaire qui s’invite dans le fil de chargement.
La mort du score simpliste et ce qui l’a remplacée
Quand PageSpeed Insights a intégré les données CrUX, puis que les Core Web Vitals sont devenus un signal de classement documenté, l’outil grand public n’avait plus de raison d’être. Google l’a retiré sans bruit. La page testmysite.withgoogle.com redirige désormais vers la documentation des Core Web Vitals. Le message a changé : on ne note plus une page sur 100, on mesure des seuils.
Le changement est profond. Là où Test My Site suggérait « optimiser les images », le rapport Lighthouse pointe le fichier exact dont le temps de transfert dépasse 80 ms. Là où l’ancien outil parlait de « polices lisibles », le diagnostic INP isole un gestionnaire d’événement qui monopolise le thread principal 200 ms. Ces informations sont actionnables par un développeur, directement dans les DevTools, sans passer par une interface intermédiaire.
Quand le diagnostic accélère plus que le conseil
J’ai un souvenir précis d’un incident qui illustre la distance entre ces deux mondes. Un client avait suivi à la lettre les recommandations de Test My Site en 2018 : cache navigateur activé, images compressées, AMP déployé. Résultat : 92/100 sur l’outil. Pourtant, le taux de rebond mobile restait élevé. Une session de debug avec WebPageTest a montré que la version AMP servait des polices web depuis un sous-domaine non pré-connecté, ajoutant 600 ms au LCP. L’outil grand public n’avait aucun moyen de le détecter, car il mesurait le chargement de la ressource AMP dans le cache Google, pas dans le navigateur de l’utilisateur.
La leçon ne porte pas sur AMP en particulier. Elle porte sur la confiance aveugle dans un score produit par la plateforme qui contrôle une partie de l’écosystème. En 2026, la performance web s’audite avec des chaînes d’outils qu’on maîtrise bout en bout : un script browser.execute_script("window.performance.getEntriesByType('navigation')") dans un Selenium, des métriques remontées par une edge function, des seuils d’alerte sur le LCP déployés dans un monitoring applicatif. Rien qui se résume à une note sur 100 dans une interface épurée.
Les rares situations où un score simple reste utile
Une note globale n’est pas complètement inutile pour autant. Elle peut servir de déclencheur de conversation avec une équipe non technique : un score synthétique, expliqué comme un indicateur parmi d’autres, aide à débloquer une décision de refonte. Certains outils SaaS modernes, comme DebugBear ou Treo, proposent des indices composites mais avec la traçabilité complète vers les métriques individuelles. L’important, c’est que le chiffre ne cache pas la méthode.
Si vous devez utiliser une note, demandez la décomposition derrière. Un LCP à 2,5 secondes avec un sous-score de 90 et un CLS à 0,3 avec un sous-score de 20, ça donne un score global moyen qui masque le vrai problème de stabilité visuelle. C’est exactement ce que Test My Site ne permettait pas de faire : cliquer sur un score ne renvoyait pas à la métrique précise, mais à une liste générique de « bonnes pratiques ».
Questions fréquentes
Test My Site est-il disponible aujourd’hui ? Non. L’outil a été arrêté par Google et redirige vers la documentation des Core Web Vitals. Le dernier snapshot visible sur archive.org date de 2020, avant la migration définitive de l’URL.
Un score PageSpeed Insights sur 100 garantit-il de bonnes performances réelles ? Pas nécessairement. Un score laboratoire de 100 ne reflète ni la variabilité réseau, ni le poids des scripts tiers chargés en production, ni les débits des terminaux bas de gamme. Les données de terrain (CrUX) restent le juge de paix.
Pourquoi Google a-t-il tant poussé AMP à l’époque si ce n’était pas un vrai signal de performance ? AMP servait surtout à garantir une expérience mobile instantanée via le préchargement dans les résultats de recherche, ce qui renforçait l’écosystème Google Discover et le carrousel Actualités. La vitesse n’était qu’un bénéfice collatéral, pas la finalité première.
