Quiconque s’occupe d’un site finit tôt ou tard par tous les essayer : Pingdom, GTmetrix, WebPageTest et PageSpeed Insights. On saisit la même adresse dans quatre outils et on obtient quatre verdicts différents : un temps de chargement d’une seconde, une note « A », un waterfall très long, un score orange. Aucun de ces outils ne se trompe, mais ils répondent à des questions différentes, dans des conditions différentes et avec des métriques différentes. Choisir le bon, et savoir lequel prendre comme référence, fait la différence entre une analyse utile et une collection de chiffres impossibles à comparer.
Dans cet article, nous voyons ce qu’ils sont, ce qu’ils mesurent, en quoi ils diffèrent et quelle combinaison est aujourd’hui la référence du secteur pour qui travaille sérieusement sur la performance web.
Deux façons de mesurer : le temps de chargement et l’expérience
Avant les outils, une distinction essentielle. Pendant des années, la vitesse d’un site s’est exprimée par un seul chiffre : le temps de chargement complet, c’est-à-dire le moment où le navigateur a téléchargé toutes les ressources de la page, accompagné de son poids et du nombre de requêtes. Ce sont des indicateurs techniques utiles, mais ils disent peu de chose de ce que perçoit l’utilisateur : une page peut afficher son contenu principal en une seconde et continuer à charger des scripts tiers pendant cinq autres, ou rester blanche longtemps et tout terminer juste après.
Les métriques modernes sont au contraire centrées sur l’utilisateur : quand le contenu principal apparaît (LCP), avec quelle rapidité la page répond aux interactions (INP) et quelle stabilité elle conserve (CLS). Ce sont les Core Web Vitals, que Google évalue sur des données d’utilisateurs réels. Les outils dont nous parlons se situent à différents points entre ces deux mondes, ce qui explique une bonne part de leurs différences.
Pingdom
Pingdom est né comme service de surveillance de disponibilité : il vérifie à intervalles réguliers qu’un site répond et prévient quand ce n’est pas le cas. Il fait aujourd’hui partie de l’offre de SolarWinds et couvre aussi le monitoring d’utilisateurs réels et le monitoring de transactions. Son outil gratuit le plus connu reste toutefois son test de vitesse : on choisit un emplacement parmi ceux disponibles en Europe, en Amérique, en Asie et en Océanie, on saisit l’adresse et on obtient un rapport.
Le test de vitesse se concentre sur les métriques traditionnelles : temps de chargement, poids de la page, nombre de requêtes, répartition par type de contenu et par domaine, waterfall des ressources et note fondée sur des règles de bonnes pratiques comme la compression et la mise en cache. Il est clair et immédiat, et utile pour comprendre combien de ressources une page charge et d’où elles viennent. Ce n’est pas le bon outil pour évaluer l’expérience perçue ou les Core Web Vitals, en revanche : son temps de chargement mesure le moment où la page a fini de tout télécharger, pas celui où elle est devenue utilisable.
GTmetrix
GTmetrix est un service canadien créé pour rendre les rapports de performance accessibles. Depuis 2020, il repose sur Lighthouse : sa « GTmetrix Grade » combine le score de performance de Lighthouse avec un score de structure qui lui est propre, et le rapport montre le LCP, le Total Blocking Time, le CLS, un waterfall détaillé, la vidéo de chargement et un historique des tests pour chaque URL.
Ce qu’il faut connaître, ce sont les réglages par défaut. Avec un compte gratuit, le test part, sauf modification, d’un emplacement au Canada, avec un navigateur desktop et une connexion non limitée. Pour un site francophone visité surtout depuis des smartphones, c’est un scénario très favorable : la latence transatlantique dégrade le TTFB, mais l’absence de limites réseau et la puissance du desktop améliorent tout le reste. Les offres payantes permettent de choisir l’emplacement, les appareils mobiles et les profils de connexion, et ajoutent un monitoring périodique. GTmetrix produit des rapports clairs et faciles à partager, mais sa note doit être lue en sachant dans quelles conditions elle a été obtenue.
WebPageTest
WebPageTest est l’outil de référence des spécialistes. Né en 2008 comme projet open source et aujourd’hui géré par Catchpoint, il exécute des tests avec de vrais navigateurs depuis des dizaines d’emplacements dans le monde, y compris sur des appareils mobiles, en appliquant des limitations réseau au niveau des paquets qui reproduisent de façon réaliste la latence et la bande passante d’une connexion mobile.
Sa force, c’est la profondeur. Il lance plusieurs chargements et indique la médiane, distingue la première visite d’une visite répétée avec un cache chaud, montre le waterfall complet avec les temps DNS, de connexion et TLS de chaque requête, la vue des connexions, le filmstrip et la vidéo de chargement, la timeline du thread principal et les Core Web Vitals avec l’élément responsable identifié. Il permet aussi d’écrire des scripts de navigation, de bloquer des domaines un à un pour mesurer le poids des tiers et de comparer plusieurs tests côte à côte. Il demande plus d’expertise pour être interprété, mais c’est l’outil qui explique vraiment comment une page se charge.
PageSpeed Insights
PageSpeed Insights est le service de Google qui réunit deux choses : une analyse de laboratoire exécutée avec Lighthouse sur les serveurs de Google, avec un profil mobile ou desktop, et les données d’utilisateurs réels de Chrome collectées par le Chrome UX Report sur les 28 derniers jours, pour l’URL et pour l’ensemble de l’origine. Des quatre, c’est le seul qui affiche directement l’évaluation des Core Web Vitals sur des données de terrain, c’est-à-dire sur les mêmes données que Google utilise comme signal d’expérience de page.
La partie laboratoire est plus basique que celle de WebPageTest et ne permet de choisir ni les emplacements ni les conditions, mais son profil mobile, avec un smartphone milieu de gamme simulé et une connexion 4G lente, est volontairement strict. Nous avons traité les différences entre PageSpeed Insights et Lighthouse dans un article dédié.
La comparaison en un tableau
| Pingdom | GTmetrix | WebPageTest | PageSpeed Insights | |
|---|---|---|---|---|
| Type de données | Laboratoire | Laboratoire | Laboratoire | Laboratoire et terrain |
| Moteur | Propre | Lighthouse | Propre, vrais navigateurs | Lighthouse et CrUX |
| Principales métriques | Temps de chargement, poids, requêtes | Note, LCP, TBT, CLS | Core Web Vitals, waterfall, filmstrip | Core Web Vitals d’utilisateurs réels, score Lighthouse |
| Emplacements | Quelques-uns, au choix | Un seul avec l’offre gratuite | Des dizaines, au choix | Serveurs de Google |
| Appareil et réseau | Desktop | Desktop sans limites réseau, par défaut | Desktop et mobile, réseau configurable | Mobile ou desktop simulé |
| Usage typique | Vérification rapide, disponibilité | Rapports partageables | Diagnostic approfondi | Évaluation de Google, données d’utilisateurs réels |
Pourquoi ils donnent des résultats aussi différents
Les différences ne sont pas un défaut d’un outil par rapport aux autres : elles dépendent de quatre variables qui changent complètement la mesure.
- L’emplacement. Un test depuis Vancouver vers un serveur à Milan ajoute plus d’une centaine de millisecondes de latence à chaque échange réseau, et pèse surtout sur le TTFB. Un test depuis Francfort n’en ajoute que quelques-unes.
- L’appareil et le réseau. Un desktop sur une connexion non limitée masque presque tous les problèmes de poids du JavaScript et des images ; un smartphone milieu de gamme en 4G lente les rend évidents.
- La métrique. Le temps de chargement complet de Pingdom, le Largest Contentful Paint de WebPageTest et le score de Lighthouse mesurent des choses différentes, même quand ils sont tous exprimés en secondes.
- La note. La note de Pingdom, celle de GTmetrix et le score de PageSpeed Insights sont calculés avec des formules différentes. Les comparer, c’est comme comparer des notes d’écoles différentes.
S’y ajoute un facteur moins innocent. Certains outils de test peuvent être reconnus à leur User-Agent ou à leur adresse IP, et certaines configurations leur servent une page différente de celle que reçoivent les utilisateurs : c’est ce que nous avons documenté dans le cas de LiteSpeed Cache, qui inclut explicitement Pingdom, GTmetrix et les services de Google dans ses propres listes. Un excellent résultat de laboratoire qui ne trouve aucune confirmation dans les données d’utilisateurs réels doit toujours être vérifié.
Quelle est la référence du secteur
Si la question est de savoir quel outil prendre comme référence, la réponse a deux volets, parce que deux questions comptent.
Pour évaluer l’expérience, la référence est constituée des données d’utilisateurs réels du Chrome UX Report, disponibles dans PageSpeed Insights et, pour l’ensemble du site, dans le rapport Core Web Vitals de la Search Console. Non pas parce que Google serait infaillible, mais parce que ce sont des données collectées dans les navigateurs de vrais utilisateurs et que Google lui-même s’en sert. Aucun score de laboratoire, d’aucun outil, ne remplace cette évaluation.
Pour diagnostiquer, les références sont Lighthouse et WebPageTest. Lighthouse, via PageSpeed Insights, Chrome DevTools ou les pipelines d’intégration continue, est le langage commun : ses métriques et ses audits sont ceux que connaissent les développeurs, les agences et les clients. WebPageTest est l’outil professionnel pour l’analyse approfondie, quand il faut comprendre exactement ce qui se passe sur le réseau et dans le navigateur, depuis un emplacement précis et sur un appareil réaliste.
GTmetrix et Pingdom ont leur place : le premier pour des rapports rapides et partageables, à condition de définir un emplacement et un appareil cohérents avec votre audience ; le second surtout pour la surveillance de disponibilité et une vue immédiate du poids et des requêtes. Ni l’un ni l’autre, seul, ne doit guider les décisions sur les Core Web Vitals.
Lequel utiliser, question par question
- « Mon site réussit-il les Core Web Vitals ? » PageSpeed Insights, section des données d’utilisateurs réels, et Search Console.
- « Pourquoi le LCP est-il lent sur mobile ? » WebPageTest depuis un emplacement proche de votre audience, avec un profil mobile et plusieurs exécutions ; à défaut, Lighthouse dans DevTools.
- « Combien pèsent les scripts tiers ? » WebPageTest, en comparant le test normal avec un test où les domaines externes sont bloqués.
- « La mise en production d’aujourd’hui a-t-elle dégradé quelque chose ? » Lighthouse dans un pipeline d’intégration continue, avec des seuils de performance définis.
- « Comment évolue-t-il dans le temps ? » Les données d’utilisateurs réels de CrUX et un monitoring synthétique périodique, toujours avec la même configuration, que ce soit GTmetrix, WebPageTest ou l’API PageSpeed Insights.
- « Le site est-il en ligne ? » Un service de surveillance de disponibilité comme Pingdom.
Erreurs à éviter
- Tester depuis un emplacement éloigné de votre audience. Un site destiné au marché francophone doit être mesuré depuis l’Europe, de préférence près du data center et des utilisateurs.
- Se contenter du profil desktop. Si la plupart des visites viennent de smartphones, un test desktop sur un réseau rapide décrit le meilleur site possible, pas le site réel.
- Comparer les notes d’outils différents. Un « A » de GTmetrix et un 70 de PageSpeed Insights ne se contredisent pas : ils mesurent des choses différentes dans des conditions différentes.
- Prendre le temps de chargement comme objectif. Réduire le temps de chargement complet n’améliore pas forcément ce que perçoit l’utilisateur ; les décisions doivent se fonder sur des métriques centrées sur l’utilisateur.
- S’appuyer sur un seul test. Toute mesure de laboratoire a une variabilité naturelle : plusieurs exécutions et la médiane, toujours avec la même configuration, sont le minimum pour une comparaison sérieuse.
Notre méthode
Dans notre travail quotidien, nous utilisons ces outils à la suite. Nous partons des données d’utilisateurs réels de CrUX, dans PageSpeed Insights et Search Console, pour comprendre quelles pages et quelles métriques sont critiques et sur quel type d’appareil. Nous passons ensuite au laboratoire : WebPageTest depuis l’Europe avec un profil mobile pour le diagnostic du réseau et du chargement, Lighthouse dans DevTools pour le thread principal et le JavaScript. Après chaque intervention, nous vérifions en laboratoire l’absence de régressions et, dans les semaines qui suivent, que les données d’utilisateurs réels confirment le résultat, en tenant compte de la fenêtre de 28 jours.
Dans chaque rapport, nous indiquons l’outil, l’emplacement, l’appareil, le profil réseau et le nombre d’exécutions derrière chaque valeur. C’est la seule façon de rendre comparables des mesures prises à des moments différents et d’éviter que la discussion ne passe du site au thermomètre.
En résumé
Pingdom mesure surtout le temps de chargement, le poids et les requêtes, et a été créé pour la surveillance de disponibilité. GTmetrix propose des rapports clairs fondés sur Lighthouse, mais avec des réglages par défaut très favorables. WebPageTest est l’outil le plus complet pour le diagnostic, avec de vrais navigateurs et des emplacements et des réseaux configurables. PageSpeed Insights est le seul à montrer les données d’utilisateurs réels sur lesquelles Google évalue les Core Web Vitals, à côté d’une analyse Lighthouse avec un profil mobile strict.
La référence recommandée n’est pas un outil unique mais une combinaison : les données d’utilisateurs réels de CrUX pour savoir comment les utilisateurs s’en sortent, Lighthouse et WebPageTest pour comprendre pourquoi et vérifier chaque intervention. Tout le reste n’est utile que si l’on sait exactement quelle question l’on pose, et dans quelles conditions.
