WebPageTest vs PageSpeed Insights : comparatif complet

Pourquoi le bon outil change tout

Un audit de performance qui s'appuie sur le mauvais outil produit deux symptômes typiques : un score Lighthouse à 95 dans PageSpeed Insights alors que les utilisateurs réels expérimentent un LCP à 4s sur mobile, ou inversement un site qui passe les Core Web Vitals en terrain mais reste opaque dès qu'on cherche à comprendre pourquoi une régression vient de tomber. La cause est presque toujours la même : on a confondu lab data et field data, ou on a interprété un chiffre synthétique comme une vérité d'expérience utilisateur.

C'est le débat WebPageTest vs PageSpeed Insights — et il ne se règle pas en désignant un gagnant. Les deux outils sont complémentaires, à condition de savoir lequel répond à quelle question.

La différence fondamentale : lab data vs field data

WebPageTest

Lab data

Paris · Moto G4 · 4G Waterfall

HTML

CSS

JS

IMG (LCP)

API

tracker

Filmstrip 100ms / frame

LCP Bon

1.2s

1 test depuis Paris · Moto G4 · 4G, déterministe

PageSpeed Insights

Lab + Field

Field · CrUX

D-28

aujourd'hui

P75

CrUX P75

2.4s À améliorer

Lab · Lighthouse

0

Perf

0

A11y

0

BP

0

SEO

0

Score lab (Lighthouse) + données terrain (CrUX, 28j), dans un seul rapport

C'est l'axe qui structure tout le reste. Tout ce qui suit (méthodologie, métriques, cas d'usage) en découle.

Lab data : la page est chargée dans un navigateur contrôlé, avec un profil réseau et CPU fixés (ex. Slow 4G, CPU 4× ralenti). Une exécution donne un chiffre reproductible. C'est ce que produisent WebPageTest et Lighthouse. Avantage : déterministe, idéal pour comparer un avant/après ou détecter une régression sur un commit. Limite : un seul scénario synthétique, qui ne reflète pas la diversité des terminaux et connexions réels.

Field data : les métriques sont collectées sur les chargements réels de vrais utilisateurs Chrome (CrUX, Chrome User Experience Report), agrégées sur une fenêtre glissante de 28 jours et restituées au 75e percentile. C'est ce que PageSpeed Insights affiche dans son bloc "Données utilisateur réelles" — et c'est ce que Google utilise comme signal pour la Page Experience. Avantage : c'est la réalité. Limite : 28 jours de latence, et impossible de drill-down sur une session précise.

Subtilité importante à garder en tête : WPT ne produit que du lab data, tandis que PSI produit les deux — un run Lighthouse (lab) plus le bloc CrUX (field) dans le même rapport. La comparaison n'est donc pas "lab vs field" comme on le simplifie souvent ; c'est "lab pur, très profond" (WPT) face à "lab + field, accessibles en un clic" (PSI).

Conséquence pratique : PSI vous dit s'il y a un problème, WPT vous dit pourquoi. Une optimisation ne se valide définitivement qu'en field data — mais elle se construit en lab data.

WebPageTest : ce qu'il fait mieux

Cascade réseau

Avant 4,490ms

index.html

320ms

styles.css

280ms

app.js

850ms

vendor.js

1200ms

fonts.ttf

520ms

hero.png

980ms

jQuery.js

340ms

Après optimisation 590ms

index.html

120ms

styles.css

70ms

app.js

180ms

vendor.js

Supprimé

fonts.woff2

80ms

hero.avif

140ms

jQuery.js

Supprimé

Gain total : -87% 3,900ms économisées

Html Css Js Font Image

WebPageTest (WPT), aujourd'hui édité par Catchpoint, est un outil de lab data pur — pas de données terrain ici, mais la profondeur de diagnostic la plus poussée du marché. C'est la référence du test synthétique, à plusieurs étages.

Côté infrastructure, le plan Starter gratuit donne accès à 30 localisations dans le monde — dont la Chine continentale — sur des terminaux physiques réels (Moto G4, iPhone, profils Chrome desktop). Le plan Pro en débloque 35 au total, avec priorité de file et localisations premium. C'est ce qui permet de constater qu'un site qui charge en 1,2s depuis Paris peut afficher 4,8s depuis Mumbai sur le même Moto G4 — un écart invisible avec un outil mono-localisation. Pour un site qui sert plusieurs zones géographiques, c'est non négociable.

Côté diagnostic visuel, le waterfall détaille chaque requête par DNS, connexion, TLS, TTFB et téléchargement : vous voyez immédiatement la requête qui bloque le LCP, le preload qui n'a pas été honoré, le script tiers qui retarde un autre asset critique. Le filmstrip enregistre l'état visuel de la page toutes les 100 ms (configurable jusqu'à 60 fps) et produit une vidéo : vous identifiez précisément quand le hero apparaît, quand un layout shift se produit, à quelle frame le bouton "Ajouter au panier" devient cliquable. PSI ne fournit qu'un visuel de fin de chargement.

Au-delà des Core Web Vitals, WPT expose le Speed Index (introduit par Pat Meenan en 2012, mesure de remplissage visuel pondéré), le TTFB, le Start Render, le Total Blocking Time, et vos propres User Timings — toute marque créée via performance.mark() apparaît automatiquement dans le rapport. Vous pouvez aussi injecter du JavaScript custom pour mesurer ce qui n'a pas de métrique standard (temps avant que le panier devienne interactif, taille DOM à un instant T, présence d'un élément spécifique). Pour filtrer le bruit, le test en multi-runs (3 par défaut, configurable) avec médiane est la norme — et plusieurs URLs peuvent être comparées côte à côte avec filmstrips synchronisés, utile pour benchmarker face à un concurrent.

Restent les deux fonctionnalités qui mettent WPT dans une catégorie à part : le scripting et l'API. Le scripting permet d'auditer une page derrière un login, ou une PDP atteinte après plusieurs clics depuis la home — vous naviguez, remplissez un formulaire, cliquez, attendez, et n'enregistrez les métriques que sur la page cible :

logData 0
setCookie https://example.com session=abc123
navigate https://example.com/login
setValue id=email user@example.com
setValue id=password ***
clickAndWait id=submit
logData 1
navigate https://example.com/dashboard

logData 0 désactive l'enregistrement pendant le setup, logData 1 le réactive sur la page qu'on veut réellement mesurer. C'est totalement impossible dans PSI. L'API REST (plan Pro) permet d'automatiser tout cela : tests dans une pipeline CI, alimentation d'un dashboard interne, déclenchement à chaque deploy. C'est aussi ce qui permet d'intégrer WPT à des plateformes comme SpeedCurve ou Calibre.

PageSpeed Insights : ce qu'il fait mieux

⏱️ ↓

0 ms

TTFB

🖼️ ↓

0 s

LCP

📐 ↓

0

CLS

🎯 ↑

0 /100

Score

PageSpeed Insights (PSI), édité par Google, a une particularité unique : c'est le seul outil grand public qui combine lab data (un run Lighthouse) et field data (le bloc CrUX) dans un même rapport. Ses deux atouts tiennent dans cette dualité — accessibles en un clic, sans installation.

Côté field, le bloc "Données utilisateur réelles" en haut du rapport affiche le LCP, l'INP et le CLS mesurés sur les visites Chrome réelles de votre URL (ou de votre origine si la page n'a pas assez de trafic), au 75e percentile sur 28 jours. C'est exactement la donnée utilisée par Google pour le signal Page Experience — aucun audit lab ne peut la produire.

Côté lab, PSI fait tourner Lighthouse 13 dans un environnement Google avec un profil mobile fixé (Moto G4 émulé, Slow 4G, CPU 4× ralenti) et restitue le score 0-100 par catégorie (Performance, Accessibilité, Bonnes pratiques, SEO) avec une liste d'audits actionnables — chaque audit accompagné d'une estimation de gain (ms gagnées, Ko économisés) et d'une explication de la cause racine. C'est exactement ce que produit lighthouse https://example.com en local, mais sans rien installer.

L'accès est total : URL, bouton "Analyser", 30 secondes, aucun compte, aucune compétence technique requise. C'est l'outil que vous partagez avec un product manager ou un client. L'API v5 (clé Google gratuite) prolonge cette accessibilité côté monitoring : 25 000 requêtes par jour et 400 par 100 secondes, largement de quoi auditer un catalogue de plusieurs centaines d'URLs au quotidien — inenvisageable avec WPT en plan gratuit. Et comme l'API renvoie les deux (Lighthouse + CrUX), un seul appel suffit à suivre lab et terrain en parallèle.

Comparatif point par point

Cas d'usage : lequel pour quoi

Une fois la matrice posée, le verdict se fait par scénario, pas par outil.

Limites et pièges à connaître

Aucun outil ne dit toute la vérité. Trois pièges reviennent systématiquement.

Le score Lighthouse n'est pas un signal SEO direct. Un 95 dans PSI n'a aucune influence sur le ranking — ce qui compte pour Google, c'est le bloc CrUX du même rapport, c'est-à-dire les données terrain au P75. Optimiser pour faire monter le score sans toucher au terrain est un travail décoratif.

Un seul run WPT ne vaut rien. Le réseau est bruyant, le CPU d'un agent partagé fluctue ; toujours lancer au moins 3 runs et prendre la médiane. Sur des optimisations à 100-200 ms, un seul run peut produire un faux positif (ou un faux négatif) qui vous fait perdre une journée.

Enfin, CrUX peut être vide. Pour qu'une URL ait sa propre donnée CrUX, il lui faut un seuil minimum de trafic Chrome. Sur une page peu visitée, PSI bascule sur la donnée origine (l'ensemble du site) — ou n'affiche rien. C'est invisible si on lit trop vite.

💡 Bonnes pratiques pour interpréter PSI : toujours vérifier que le bloc "Données utilisateur réelles" est bien sur l'URL et pas sur l'origine entière (un toggle existe). Si CrUX est vide, ne pas conclure que la perf est bonne ou mauvaise — l'absence de donnée est une absence de donnée. Et garder en tête que l'[INP a remplacé FID dans les Core Web Vitals en mars 2024](https://pauld.fr/conseils/core-web-vitals-inp-mars-2024) : si votre dashboard interne suit encore FID, vous suivez une métrique morte.

L'écosystème autour de WPT et PSI

Réduire l'outillage de performance à ces deux outils, c'est passer à côté de la moitié du paysage. Les voisins à connaître, avec leur créneau respectif :

Recommandations pratiques

Le bon setup dépend moins de vos préférences que de votre contexte d'usage :

FAQ

Sources

• WebPageTest Documentation
• Catchpoint WebPageTest — pricing & plans
• PageSpeed Insights — Google for Developers
• CrUX (Chrome User Experience Report) — documentation
• web.dev — Core Web Vitals
• web-vitals library — GitHub