Comment mesurer correctement la vitesse d’un site

Pour mesurer correctement la vitesse d’un site, combinez deux types de données : les tests en laboratoire, qui chargent votre page dans des conditions contrôlées et vous aident à déboguer, et les données terrain, qui montrent la vitesse réelle de votre site pour vos vrais visiteurs. Utilisez les mêmes outils, les mêmes pages et les mêmes réglages avant et après chaque modification, répétez chaque test plusieurs fois et jugez le résultat sur des médianes et des données d’utilisateurs réels plutôt que sur un score isolé. Ce guide explique quel outil utiliser pour quoi, et comment réaliser une comparaison avant/après fiable.

Données de laboratoire et données terrain

Presque toutes les confusions autour de la vitesse d’un site viennent d’un mélange entre ces deux types de données.

Les données de laboratoire proviennent d’un test réalisé sur un seul appareil, avec un seul profil réseau et depuis un seul lieu. Lighthouse en est l’exemple le plus connu. Il se trouve derrière les données PageSpeed Insights de Google, qu’utilise corewebvitals.page, et il est intégré aux Chrome DevTools. Les tests de laboratoire sont reproductibles et fournissent des diagnostics détaillés : ils sont donc idéaux pour trouver les causes et vérifier qu’une correction fonctionne. Mais ils restent une simulation : une seule visite, avec un profil de bridage précis, depuis l’endroit où le test s’exécute.

Les données terrain, aussi appelées real-user monitoring (RUM), proviennent de vrais visiteurs, sur leurs propres téléphones, ordinateurs portables et réseaux. Google les collecte auprès des utilisateurs de Chrome dans le Chrome UX Report (CrUX). Vous les retrouvez dans la Search Console, et des outils comme corewebvitals.page les affichent pour n’importe quelle URL. Ce sont ces données que Google utilise pour son évaluation de l’expérience de page, et elles reflètent la réalité, y compris les appareils lents et les visiteurs éloignés. Leur inconvénient est la lenteur du retour : CrUX publie ses données sur une fenêtre glissante de 28 jours, si bien qu’une modification faite aujourd’hui met des semaines à apparaître pleinement.

Utilisez les données de laboratoire pour travailler, et les données terrain pour décider si ce travail a porté ses fruits.

Le bon outil pour chaque tâche

Inutile d’avoir une grande boîte à outils. Quatre outils couvrent presque tout.

corewebvitals.page

corewebvitals.page affiche les deux types de données pour le mobile et le desktop, à partir des données PageSpeed Insights de Google : les données terrain de CrUX sur les 28 derniers jours, si votre site a assez de trafic, et un test de laboratoire Lighthouse. Lisez d’abord les données terrain. Le score de performance de 0 à 100 ne concerne que la partie laboratoire et n’est pas ce que Google utilise pour le classement.

Search Console

Le rapport Core Web Vitals de Google Search Console regroupe vos URL par statut (bonne, à améliorer, mauvaise) à partir des données terrain. C’est le meilleur endroit pour voir quels modèles de pages posent problème sur l’ensemble du site, plutôt que de tester les URL une par une.

Chrome DevTools

Les panneaux Performance et Réseau montrent précisément ce qui se passe pendant un chargement : quelle requête bloque le rendu, quel script monopolise le thread principal, combien de temps le serveur met à répondre. Le panneau Lighthouse lance le même type de test de laboratoire en local. Utilisez une fenêtre de navigation privée pour que les extensions du navigateur ne faussent pas les résultats.

Vérifications en ligne de commande

Pour le temps de réponse du serveur, curl vous donne une valeur nette et reproductible, sans la surcharge d’un navigateur :

for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/
done

Cette commande affiche le temps jusqu’au premier octet pour cinq requêtes consécutives. Elle est particulièrement utile pour vérifier les changements de cache et de serveur. Le guide pour réduire le TTFB explique comment décomposer davantage cette valeur.

Quelles métriques regarder

Concentrez-vous sur quelques métriques qui décrivent ce que vivent les visiteurs :

• Largest Contentful Paint (LCP) : le moment où le contenu principal apparaît. Une bonne valeur est de 2,5 s ou moins.
• Interaction to Next Paint (INP) : la rapidité avec laquelle la page réagit aux clics et aux touchers. Une bonne valeur est de 200 ms ou moins. Mesurable uniquement dans les données terrain.
• Cumulative Layout Shift (CLS) : l’ampleur des sauts de mise en page. Une bonne valeur est de 0,1 ou moins.
• Time to First Byte (TTFB) : la rapidité avec laquelle le serveur commence à répondre. web.dev recommande 0,8 s ou moins.

Google évalue les trois Core Web Vitals (en anglais) au 75e percentile des chargements de pages, séparément pour le mobile et le desktop. Autrement dit, trois visites sur quatre doivent respecter le seuil. Le guide sur les Core Web Vitals explique ce qui influence chaque métrique et comment la corriger.

Le poids total de la page et le temps de chargement complet sont moins utiles qu’il n’y paraît. Une page peut finir de se charger tard à cause d’un widget de chat que personne ne remarque, alors qu’une image hero lente, que tout le monde remarque, influence à peine le temps de chargement total.

Pourquoi vos résultats varient autant

Si vous lancez trois fois le même test de laboratoire et obtenez trois scores différents, rien n’est cassé. Les raisons habituelles :

• Cache froid ou cache rempli. La première requête après un déploiement ou une purge est souvent bien plus lente que les suivantes, sur votre serveur comme sur un éventuel CDN.
• La charge du serveur. Un test aux heures de pointe est en concurrence avec les vrais visiteurs.
• Les scripts tiers. Les publicités, les gestionnaires de balises et les widgets de chat chargent un contenu différent à chaque fois.
• Le lieu du test. Les tests de laboratoire basés sur les données PageSpeed Insights de Google, y compris ceux de corewebvitals.page, s’exécutent depuis un centre de données Google. Si votre serveur est sur un autre continent, le test mesure cette distance.
• La machine de test. Lighthouse dans les DevTools dépend du processeur de votre propre ordinateur et de tout ce qui tourne en parallèle.

Une comparaison avant/après fiable

Quand vous modifiez quelque chose, comme une configuration de cache, un nouveau thème ou un CDN, suivez une routine fixe pour que la comparaison soit équitable.

1. Choisissez des pages représentatives. Prenez une page de chaque modèle important : page d’accueil, page catégorie ou liste, fiche produit ou article. Incluez votre landing page la plus visitée.
2. Notez les conditions. Même outil, même profil d’appareil (mobile et desktop séparément), même lieu de test, et si possible même moment de la journée.
3. Préchauffez, puis mesurez. Chargez chaque page une fois et ignorez ce résultat, sauf si vous voulez justement mesurer la performance d’une première visite. Lancez ensuite au moins cinq tests par page.
4. Utilisez la médiane. Retenez la valeur centrale de vos tests, pas la meilleure. Notez le LCP, le CLS, le TTFB et le Total Blocking Time pour les tests de laboratoire.
5. Ne changez qu’une chose à la fois. Si vous changez d’hébergement et de thème en même temps, vous ne saurez pas lequel a aidé.
6. Répétez exactement la même routine après la modification. Comparez les médianes page par page.
7. Confirmez avec les données terrain. Vérifiez les données terrain sur corewebvitals.page et dans la Search Console au cours des semaines suivantes. Un gain en laboratoire qui n’apparaît pas chez les vrais utilisateurs n’est pas un vrai gain.

Si vous utilisez un CDN ou un cache edge, vérifiez que la page testée a bien été servie depuis le cache lors des tests « après ». Sinon, vous mesurez votre origine, et non la modification.

Comment fast.site vous aide

fast.site se place devant votre hébergement existant sous la forme d’un réseau edge avec mise en cache, optimisation des images et sécurité. Vous gardez votre hébergeur et faites pointer les serveurs de noms de votre domaine vers fast.site ; après vérification, les requêtes sont servies par l’edge.

Pour la mesure, deux points comptent. D’abord, chaque réponse contient des en-têtes qui indiquent ce qui s’est passé : fs-cache affiche HIT, MISS ou BYPASS, et fs-cache-age et fs-cache-hits indiquent depuis combien de temps et combien de fois la copie en cache a été utilisée. Il est ainsi facile de confirmer que votre test « après » provient bien du cache. L’article vérifier le cache montre comment faire.

Ensuite, les statistiques du tableau de bord affichent les requêtes, le taux de cache hit, la bande passante servie par l’edge et par l’origine, le TTFB et les taux d’erreurs pour votre propre trafic. Combinées aux données terrain de corewebvitals.page, elles vous donnent une vue avant/après fondée sur vos vrais visiteurs plutôt que sur un test isolé.

La meilleure façon de juger l’effet est de le mesurer sur votre propre site avec la routine décrite plus haut. Vous pouvez par exemple le faire pendant un essai gratuit de 7 jours. Les offres et le trafic inclus figurent sur la page des tarifs.

Questions fréquentes

Pourquoi mon score PageSpeed change-t-il à chaque fois ?

Le score de performance provient d’un seul test de laboratoire, influencé par la charge du serveur, l’état du cache, les scripts tiers et les variations du réseau. De petits écarts entre deux tests sont normaux. Lancez plusieurs tests et utilisez la médiane, et fiez-vous à la section des données terrain pour avoir une image réelle.

Faut-il absolument un score PageSpeed de 100 ?

Non. Le score est un résumé de laboratoire et n’est pas utilisé comme signal de classement. Ce qui compte, c’est que les vrais visiteurs obtiennent de bons Core Web Vitals, ce que vous voyez dans les données terrain. Courir après les derniers points demande souvent beaucoup d’efforts pour aucune différence perceptible.

Pourquoi n’y a-t-il aucune donnée terrain pour mon site ?

CrUX ne publie des données que lorsqu’une URL ou une origine a reçu suffisamment de visites d’utilisateurs de Chrome au cours des 28 derniers jours. Les petits sites ou les nouvelles pages n’atteignent souvent pas ce seuil. Dans ce cas, appuyez-vous sur les tests de laboratoire et sur votre propre suivi jusqu’à ce que les données soient suffisantes.

Combien de temps avant que les améliorations apparaissent dans la Search Console ?

Les données terrain sont collectées sur une fenêtre glissante de 28 jours : une correction apparaît donc progressivement, et pleinement seulement après environ quatre semaines. La Search Console peut avoir besoin de temps supplémentaire pour revalider les groupes d’URL. Les tests de laboratoire montrent l’effet immédiatement, c’est pourquoi on les utilise d’abord pour vérifier une correction.

Faut-il tester sur mobile ou sur desktop ?

Les deux, séparément. Google les évalue séparément, et les résultats mobiles sont généralement moins bons à cause de processeurs et de réseaux plus lents. Si vous n’avez le temps que pour un seul, commencez par le mobile.