PageSpeed Insights donne un score et quelques recommandations génériques. C’est pratique pour un premier diagnostic, mais dès que le problème devient sérieux — un LCP qui traîne, un temps de blocage qui explose sur mobile — cet outil montre ses limites. Il ne dit pas quelle requête bloque le rendu, ni ce qui se passe réellement dans le navigateur seconde par seconde.
WebPageTest, lui, ouvre le capot. Ce service gratuit, disponible sur webpagetest.org, exécute le test sur de vraies machines réparties dans le monde, avec de vrais navigateurs, et restitue un niveau de détail que peu d’outils égalent : filmstrip image par image, waterfall complet, comparaison de connexions, et surtout la possibilité de rejouer un scénario avant/après optimisation. Voici comment s’en servir sérieusement sur un site WordPress.
Lancer un premier test correctement paramétré
Sur la page d’accueil de WebPageTest, ne validez pas le formulaire par défaut sans réfléchir. Quatre réglages comptent vraiment :
- Test Location : choisissez un site proche de vos visiteurs réels, pas seulement le serveur par défaut (souvent Dulles, Virginie).
- Browser : Chrome reste la référence pour comparer avec les données Core Web Vitals de Google.
- Connection : Cable par défaut, mais changez-le selon l’audience visée (voir plus bas pour le mobile).
- Number of Tests to Run : passez à 3 ou 5 pour lisser la variance réseau, WebPageTest affiche alors la médiane.
Activez aussi Capture Video et First View and Repeat View : la seconde visite révèle l’efficacité réelle du cache navigateur et du cache serveur, deux choses que PageSpeed Insights ne distingue pas clairement.
Lire le filmstrip image par image
Une fois le test terminé, l’onglet Filmstrip affiche une série de captures d’écran prises toutes les quelques centaines de millisecondes. C’est la vue la plus parlante pour un client ou un chef de projet : on voit concrètement à quel moment le contenu utile apparaît, plutôt qu’un chiffre abstrait.
Sur un WordPress classique, on repère souvent ce schéma : la page reste blanche pendant 800 ms à 1,2 s (temps serveur + CSS bloquant dans le head), puis le header et la structure apparaissent d’un coup, et enfin l’image mise en avant se charge en dernier, parfois une seconde plus tard. C’est exactement ce décalage que la métrique LCP (Largest Contentful Paint) sanctionne.
Le bouton Filmstrip View permet de comparer deux tests côte à côte, image par image, avec le temps affiché sous chaque vignette. C’est l’outil idéal pour visualiser l’effet d’un changement de thème ou d’un plugin de cache sans attendre la fin du test complet.
Décortiquer le waterfall
L’onglet Details affiche le waterfall : chaque requête HTTP sous forme de barre horizontale, avec ses phases (DNS, connexion, TLS, attente, téléchargement) codées par couleur. Sur un WordPress, quelques lignes reviennent systématiquement en cause :
- Une police Google Fonts chargée de façon synchrone, qui retarde le rendu du texte.
- Des feuilles de style de plugins concaténées en fin de head, après le CSS du thème.
- Des scripts tiers (chat, analytics, pixels publicitaires) qui s’exécutent avant le contenu principal.
- Une image à la une non optimisée, souvent plusieurs centaines de kilo-octets pour un affichage de 800 pixels de large.
Un repère utile : la ligne verticale bleue marque le DOMContentLoaded, la ligne verte le Load. Tout ce qui se termine largement après la ligne bleue et qui bloque visuellement l’affichage mérite d’être différé ou supprimé.
Sur un audit, je commence toujours par trier le waterfall par taille de fichier plutôt que par ordre chronologique. Neuf fois sur dix, le vrai coupable n’est pas la première requête mais une ressource énorme chargée au milieu, invisible tant qu’on ne la cherche pas spécifiquement.
Tester depuis plusieurs localisations
Un piège classique : diagnostiquer la lenteur d’un site uniquement depuis Paris alors que la moitié du trafic vient d’Amérique du Nord ou d’Asie. WebPageTest propose des dizaines de sites de test répartis dans le monde (Dulles, Francfort, Londres, Singapour, Sydney, Mumbai, entre autres).
Lancez le même test depuis deux ou trois localisations pertinentes pour votre audience et comparez le Time to First Byte (TTFB). Un écart important révèle presque toujours l’absence de CDN ou un hébergement mal placé géographiquement. Sur un site hébergé en France sans CDN, il n’est pas rare de mesurer un TTFB proche de 200 ms depuis Paris contre plus de 900 ms depuis Singapour.
Si l’écart est marqué, la solution ne passe pas forcément par un déménagement de serveur : un CDN devant WordPress (avec mise en cache de la page HTML pour les visiteurs anonymes) corrige souvent le problème sans toucher à l’hébergement.
Simuler une connexion 3G ou 4G
Le menu Connection du formulaire de test propose des profils réseau standardisés : 3G, 3G Fast, 4G, mais aussi des profils personnalisés avec débit et latence ajustables. C’est essentiel pour un site dont une part significative du trafic est mobile, car un WordPress qui semble fluide en fibre peut devenir pénible en 4G réelle, avec sa latence variable.
Pour un test représentatif d’un usage mobile courant, le profil 4G (environ 9 Mbps descendant, 170 ms de latence simulée) donne une image plus honnête que le Cable par défaut. Combinez-le avec un site de test proche géographiquement de votre audience mobile réelle pour éviter de cumuler deux biais.
Quelques réglages à ne pas négliger dans ce contexte :
- Activez Emulate Mobile Device pour simuler un vrai user agent et un viewport mobile.
- Gardez au moins 3 exécutions : la variance est plus forte sur les profils mobiles simulés.
- Comparez First View et Repeat View pour évaluer l’effet d’un cache navigateur mal configuré (en-têtes
Cache-Controlabsents ou trop courts).
Comparer avant/après une optimisation
WebPageTest propose un outil dédié, Visual Comparison, accessible depuis le menu Test History en sélectionnant deux tests puis en cliquant sur Visual Comparison. Il superpose les deux filmstrips et les deux courbes de chargement visuel, avec les métriques clés côte à côte : Start Render, LCP, Speed Index, temps de chargement complet.
Pour un audit sérieux, la méthode qui fonctionne :
- Lancer un test « avant », avec 5 répétitions, et noter l’URL du résultat.
- Appliquer une seule optimisation à la fois (par exemple activer la mise en cache de page, ou différer un script).
- Vider tous les caches (WordPress, plugin de cache, éventuel CDN) avant de relancer un test « après » dans les mêmes conditions de localisation et de connexion.
- Comparer via Visual Comparison plutôt que de se fier à un seul chiffre isolé, sensible à la variance réseau.
Cette discipline — une variable à la fois, conditions de test identiques — est ce qui distingue un vrai diagnostic d’une impression subjective de « ça va plus vite ».
En résumé
PageSpeed Insights reste un bon point d’entrée, mais WebPageTest est l’outil à sortir dès que le diagnostic doit devenir précis : filmstrip pour visualiser, waterfall pour identifier la ressource fautive, tests multi-localisations pour trancher entre problème serveur et problème géographique, simulation 3G/4G pour coller à l’usage mobile réel, et comparaison visuelle pour valider chaque optimisation appliquée à un WordPress. Prenez l’habitude de documenter chaque test avec son URL WebPageTest : c’est la meilleure preuve, pour un client comme pour vous-même, qu’une optimisation a produit un effet mesurable.
