La note de vitesse de votre site ne mesure pas ce que vivent vos visiteurs
Un message arrive un jeudi soir. Une capture d'écran, un cercle rouge, un nombre : 38. Sous le cercle, le mot « Mobile », puis une liste de recommandations en anglais. Le message qui accompagne tient en une phrase : votre site est trop lent, il faudrait envisager de le refaire.
Vous ouvrez votre site sur votre téléphone. Il s'affiche. Vous descendez, vous ouvrez deux pages, vous ne remarquez rien d'anormal.
Alors qui a raison ?
Ni la capture d'écran, ni votre test. Ce nombre rouge n'est pas une durée : personne n'a jamais attendu 38 de quoi que ce soit. Et votre propre visite est le cas le plus favorable qui puisse exister, pour des raisons que nous verrons plus loin.
Ce que vit votre visiteur se décrit par cinq mesures : des durées et des quantités. Le nombre coloré n'en est aucune. C'est une moyenne pondérée de cinq autres valeurs, produites par une simulation. La note et l'attente réelle peuvent donc bouger séparément.
Voici les cinq mesures, l'ordre dans lequel on corrige, et ce qu'il faut cesser de regarder.
Le rapport que vous avez reçu contient deux mesures qui n'ont rien en commun
L'outil qui produit cette note s'appelle PageSpeed Insights. Il est publié par Google, il est gratuit, et sa réponse se lit en deux parties. C'est la première chose à savoir.
Le bloc du haut ne mesure rien au moment où vous cliquez. Il rapporte ce qu'ont vécu vos visiteurs réels pendant les vingt-huit derniers jours : des personnes sur leur propre appareil, leur propre connexion, à leur propre distance de votre serveur. Google appelle cela les données de terrain, et ce sont des durées.
Le bloc du bas est une simulation lancée à l'instant, sur une machine appartenant à Google. Rien de ce qu'il contient ne vient de vos visiteurs. C'est de là que sortent le nombre coloré et la liste de recommandations. Google appelle cela les données de laboratoire.
Google est explicite sur la portée de chacune : la performance varie selon l'appareil, le réseau et les autres tâches en cours, et seule la mesure de terrain capte cette réalité.
Retenez la conséquence. Le bloc du haut décrit vos clients, le bloc du bas décrit un banc d'essai. Tant que les deux restent confondus, aucune décision prise à partir de ce rapport ne repose sur ce que vivent vos visiteurs.
Le laboratoire tourne sur un téléphone qui n'est pas celui de vos clients
La description de cette simulation est publique, et elle vaut la peine d'être lue.
Pour le test mobile, l'outil imite un téléphone de milieu de gamme d'il y a quelques années et ralentit artificiellement le réseau. Pour le test sur ordinateur, il imite un poste fixe relié par câble. Dans les deux cas, la demande part d'un centre de données de Google situé en Amérique du Nord, en Europe ou en Asie.
Relisez cette description en pensant à vos visiteurs. Ni leur téléphone, ni leur opérateur, ni leur position ne figurent dans ce test. Si votre clientèle est en Algérie, la distance entre elle et votre serveur n'est pas celle que la simulation a mesurée.
Cela ne rend pas l'outil inutile. Un banc d'essai a une vertu précise : il est constant. Il applique la même contrainte aujourd'hui et dans trois semaines, ce qui vous permet de comparer une page à elle-même avant et après une correction. C'est le seul usage qu'il faut en faire.
Ce qu'il ne peut pas vous dire, c'est ce qu'attend une personne réelle. Pour cela, vous avez deux voies : les données de terrain, quand elles existent, et votre propre téléphone.
Les données de terrain n'existent pas pour tout le monde, et c'est à vérifier en premier
Le bloc du haut est parfois absent. Cette absence passe pour un défaut d'affichage. Ce n'en est pas un : les conditions d'entrée sont documentées, et elles sont au nombre de trois.
Votre page doit être publiquement accessible, avec les mêmes critères qu'un moteur de recherche : elle répond correctement, elle n'est pas marquée comme à ne pas indexer.
Elle doit avoir reçu assez de visiteurs. Google ne publie pas le seuil, et indique seulement qu'il correspond au minimum d'échantillons nécessaire pour que la distribution ait un sens statistique.
Les visiteurs comptés sont un sous-ensemble. La collecte porte sur Chrome, sur ordinateur et sur Android, chez les personnes ayant accepté l'envoi des statistiques d'utilisation. Chrome sur iPhone n'en fait pas partie.
Deux conséquences, à avoir en tête avant de conclure quoi que ce soit.
Une page peu visitée n'a pas de données de terrain. L'outil bascule alors sur l'ensemble du site et vous montre la moyenne de toutes vos pages, ce qui n'est pas la mesure de celle que vous regardez. Si le site entier reste sous le seuil, il n'affiche rien. Et une part de vos visiteurs n'est jamais comptée, quel qu'en soit le nombre.
Si votre bloc du haut est vide, vous n'avez pas un mauvais site. Vous avez un site que cet instrument ne mesure pas. La seule mesure honnête devient alors la vôtre — nous y venons à la fin.
Cinq mesures décrivent ce qu'attend réellement un visiteur
Elles se lisent dans l'ordre de ce qui se passe à l'écran.
1. Rien ne peut s'afficher tant que votre serveur n'a pas répondu
Entre le moment où le doigt quitte le lien et celui où le premier fragment de réponse arrive, il ne se passe rien. L'écran reste sur la page précédente, ou blanc. Les rapports nomment ce délai Time to First Byte, abrégé en TTFB : le temps jusqu'au premier octet.
Il additionne les redirections éventuelles, la traduction de votre nom de domaine en adresse technique, l'établissement de la connexion sécurisée, puis le temps que met votre serveur à fabriquer la page.
Google recommande de viser huit dixièmes de seconde ou moins. Il ne range pas ce délai parmi les trois mesures qu'il désigne comme essentielles, et l'atteindre n'est pas indispensable si le reste tient. Mais tout le reste attend derrière.
2. Votre page est arrivée quand son plus grand élément s'affiche
Votre visiteur ne considère pas la page comme arrivée quand le premier pixel s'affiche. Il l'attend quand le plus grand élément apparaît : la photo de couverture, le bloc de titre, l'image du produit. Google mesure exactement cela sous le nom de Largest Contentful Paint, abrégé en LCP : l'affichage du plus grand élément de contenu visible. Le repère est de deux secondes et demie.
Cette mesure a une propriété précieuse : elle se décompose en quatre segments — la réponse du serveur, le temps que met le navigateur à découvrir cet élément, la durée de son téléchargement, son affichage une fois reçu. Dans une répartition saine, la réponse du serveur et le téléchargement pèsent environ quarante pour cent chacun.
Un segment anormalement long vous désigne le responsable. C'est la seule des cinq qui vous dise d'elle-même où chercher.
3. Une page se juge aussi à ce qui ne bouge pas
Vous commencez à lire un paragraphe, une image finit de charger au-dessus, et le texte descend de trois lignes. Vous visez un bouton, une bannière s'insère, et votre doigt tombe sur autre chose.
Google mesure ces déplacements involontaires sous le nom de Cumulative Layout Shift, abrégé en CLS : le cumul des décalages de mise en page. Le calcul combine la surface d'écran concernée et la distance parcourue par les éléments, et le repère est de 0,1. Les déplacements qui suivent votre geste dans la demi-seconde ne sont pas comptés : ouvrir un menu déroulant ne vous pénalise pas.
Les causes se ramènent presque toujours à quatre : des images insérées sans dimensions déclarées, une police d'écriture qui remplace la police provisoire sans faire la même largeur, des encarts ou des modules externes qui se redimensionnent en arrivant, et du contenu ajouté après l'affichage.
4. Un geste sans effet visible passe pour une panne
Vous touchez le bouton du menu. Rien ne se produit. Vous touchez une deuxième fois. Le menu s'ouvre, puis se referme aussitôt, parce que le premier appui vient d'être traité.
Google mesure ce délai sous le nom d'Interaction to Next Paint, abrégé en INP : le temps entre une interaction et le dessin de l'image suivante. Il n'observe que trois gestes — un clic de souris, une pression sur un écran tactile, une frappe au clavier. Le défilement et le survol ne sont pas comptés. Le repère est de deux dixièmes de seconde.
Elle a remplacé en mars 2024 une mesure plus ancienne, qui n'observait que le tout premier geste. Et sa particularité explique un malentendu tenace : aucun outil de laboratoire ne peut la produire, puisque personne ne clique dans un laboratoire. Elle n'existe que dans les données de terrain.
5. Le poids que vous envoyez ne dépend que de vous
Cette cinquième mesure ne rapporte aucun point nulle part. Elle pèse pourtant sur les quatre autres, et c'est celle que vous contrôlez le plus directement : le nombre de kilo-octets que votre page fait descendre pour s'afficher.
Le téléchargement du plus grand élément représentait déjà, plus haut, quarante pour cent environ de l'attente. Sur une connexion mobile, c'est le segment qui s'allonge le plus, et il ne dépend ni de votre code ni de votre hébergeur : il dépend du nombre d'octets que vous avez décidé d'envoyer.
C'est aussi la seule des cinq qui coûte quelque chose à votre visiteur, en consommation de forfait.
| La mesure | Ce qu'elle décrit à l'écran | Le repère publié par Google | Où la lire |
|---|---|---|---|
| Réponse du serveur (TTFB) | Le temps où il ne se passe rien | 0,8 s ou moins ; mauvais au-delà de 1,8 s. N'est pas une des trois mesures essentielles | Terrain et laboratoire |
| Contenu principal (LCP) | Le moment où la photo ou le titre apparaît | 2,5 s ou moins | Terrain et laboratoire |
| Stabilité de la page (CLS) | Le texte qui descend, le bouton qui se dérobe | 0,1 ou moins ; mauvais au-delà de 0,25 | Terrain et laboratoire |
| Réactivité (INP) | L'attente entre le doigt et l'effet | 0,2 s ou moins ; mauvais au-delà de 0,5 s | Terrain uniquement |
| Poids transféré | Ce que la page fait descendre pour s'afficher | Aucun repère publié : c'est une décision, pas une note | Panneau réseau du navigateur |
Le nombre coloré n'est pas une mesure, c'est une moyenne pondérée
La documentation de Google donne sa formule, et elle explique l'essentiel des malentendus.
Le score combine cinq valeurs de laboratoire : le temps total de blocage compte pour trente pour cent, l'affichage du contenu principal pour vingt-cinq, la stabilité de la mise en page pour vingt-cinq, le premier affichage pour dix, un indice d'apparition progressive pour dix. Chaque valeur est convertie en note sur cent selon une courbe établie sur des sites réels, puis les notes sont moyennées.
Quatre conséquences, toutes lisibles dans cette formule.
La réactivité n'y est pas. La mesure la plus proche de votre agacement quotidien, le délai entre un geste et son effet, ne peut pas être produite en laboratoire. Elle est absente du nombre qu'on vous montre.
Près d'un tiers du score dépend du temps de blocage, c'est-à-dire de l'occupation du navigateur par les traitements en cours, donc surtout par les scripts. Retirer un module inutilisé peut faire monter la note sans que le changement se voie autant à l'écran.
Le score varie d'un lancement à l'autre. Google en donne les causes : les affichages alternés, les publicités qui changent, l'acheminement sur le réseau, la machine utilisée, les extensions installées. Sa documentation invite à penser la performance comme une distribution de scores plutôt que comme un nombre unique.
Aucun seuil ne vous est demandé. Google indique que ces signaux sont utilisés par ses systèmes de classement, et ajoute aussitôt que la recherche montre d'abord le contenu le plus pertinent, même quand l'expérience de page est moyenne, et que de bons résultats ne garantissent aucune position.
La couleur, enfin, est une tranche : vert au-dessus de quatre-vingt-dix, rouge en dessous de cinquante. Passer du rouge à l'orange peut correspondre à une seconde gagnée comme à un gain imperceptible.
L'ordre des corrections ne se lit pas dans la liste de recommandations
Cette liste est triée par gain estimé sur le score, pas par ce que vos visiteurs ressentent. Voici l'ordre qui tient.
Vos images, d'abord. L'élément le plus grand d'une page est le plus souvent une image. Trois gestes : déclarer ses dimensions dans le code, pour que rien ne bouge quand elle arrive ; l'exporter à la taille réellement affichée, et non en pleine résolution d'appareil photo ; vérifier que la première image visible n'est pas en chargement différé, réglage qui rend service partout ailleurs et retarde précisément celle qu'il ne faut pas retarder.
Vos polices d'écriture, ensuite. Une police personnalisée arrive après le texte. Entre-temps le navigateur affiche une police de remplacement, ou rien, et la substitution déplace la mise en page. Limitez le nombre de graisses chargées, hébergez-les avec le site plutôt que de les appeler ailleurs, et réglez explicitement le comportement d'attente.
Les scripts venus de l'extérieur, en troisième. Le module de discussion, la balise de statistiques, le fil de réseau social, le bandeau de consentement. Chacun occupe le navigateur pendant le chargement, et plusieurs insèrent du contenu après coup : les deux mécanismes derrière le temps de blocage et les décalages. La règle est simple à énoncer, difficile à appliquer : chaque module doit être rattaché à une personne qui s'en sert. Ceux dont personne ne réclame les données sortent.
Votre hébergement, en dernier. Non parce qu'il compte peu, mais parce que c'est la décision la plus lourde et que les trois précédentes rapportent souvent davantage. Le signal qui la justifie est net : la réponse du serveur reste élevée sur toutes vos pages, y compris sur une page presque vide. Regardez alors les redirections en chaîne, la mise en cache, et la distance entre votre serveur et vos visiteurs.
Une règle gouverne les quatre : une modification à la fois, une mesure avant et une mesure après, sur la même page, à la même heure, depuis le même appareil. Sans cela, vous aurez peut-être gagné, mais vous ne saurez pas grâce à quoi — ni quoi refaire sur la page suivante.
Trois réflexes coûtent plus qu'ils ne rapportent
Activer une extension d'optimisation sans avoir mesuré avant. Ces modules font plusieurs choses à la fois : ils compressent, diffèrent des scripts, mettent en cache. Activés d'un bloc, ils ne vous laissent ni point de comparaison ni moyen d'attribuer un gain — et le jour où une page s'affiche incorrectement, vous ignorez laquelle des options en est la cause. Mesurez, notez, activez une option, remesurez.
Poursuivre la note parfaite. Les derniers points se paient sur les valeurs de laboratoire les plus éloignées de l'expérience réelle, et se reperdent au premier module ajouté. Une page à cent dont le bloc de terrain est vide ne vous apprend rien sur vos clients. Une page à soixante-cinq dont le contenu principal apparaît sous deux secondes et demie chez de vrais visiteurs est en meilleur état.
Lancer le rapport une fois et ne jamais le rejouer. Les données de terrain avancent par fenêtre glissante de vingt-huit jours, et l'outil de suivi que Google met à disposition des propriétaires de sites observe lui aussi une correction sur vingt-huit jours. Une mesure prise le lendemain ne dit rien. Posez-vous un rappel à un mois, un autre à trois.
Questions fréquentes
Combien de temps faut-il pour qu'une correction se voie ?
Sur le banc d'essai, immédiatement : relancez le test, le nombre bouge. Dans les données de terrain, comptez plusieurs semaines, puisque la fenêtre de mesure couvre vingt-huit jours glissants et contient encore vos visiteurs d'avant la correction. La vérification proposée par Google aux propriétaires de sites s'étend sur la même durée.
Un site plus rapide se positionne-t-il mieux dans Google ?
Google indique que ces signaux sont utilisés par ses systèmes de classement, sans donner de seuil ni d'engagement. Il précise dans le même document que la pertinence du contenu passe d'abord, et que de bons résultats sur ces mesures ne garantissent aucune position. La vitesse se travaille pour vos visiteurs ; ce qu'elle produit ailleurs ne s'annonce pas à l'avance.
Mon rapport n'affiche aucune donnée de terrain. Faut-il s'en inquiéter ?
Non. Cela signifie que la page, et peut-être le site, n'atteint pas le nombre de visiteurs nécessaire pour que Google publie une distribution. C'est une information sur votre audience, pas sur votre site. Mesurez vous-même, sur un vrai téléphone, et tenez votre propre relevé.
Faut-il refaire le site pour gagner en vitesse ?
Les trois premiers leviers décrits ici — images, polices, scripts extérieurs — relèvent du contenu et du réglage, pas de la reconstruction. Commencez par eux et mesurez. Une refonte répond à d'autres questions que la vitesse, et se décide sur ces questions-là.
Mon site est rapide sur mon téléphone. Pourquoi la note est-elle mauvaise ?
Parce que vous testez le meilleur cas possible. Vous connaissez l'adresse, votre navigateur garde en mémoire les images et les polices du site, vous êtes souvent sur le wifi du bureau, et vous n'avez pas la connexion de la personne qui vous découvre depuis une voiture. Refaites le test en navigation privée, en données mobiles, sur une page que vous n'avez pas ouverte récemment.
Les visiteurs sur iPhone apparaissent-ils dans ces mesures ?
Pas dans les données de terrain publiées par Google : la collecte porte sur Chrome, sur ordinateur et sur Android. Si une part importante de votre clientèle utilise un iPhone, le bloc du haut ne décrit qu'une partie de vos visiteurs. Raison de plus pour faire vos propres relevés, sur les appareils que vos clients utilisent réellement.
Pour aller plus loin
Ce qu'un audit doit contenir pour qu'on puisse en décider quelque chose — la note en couverture y tient souvent lieu de diagnostic : voici les six pièces qui, elles, tranchent.
Les quatre décisions à prendre avant la première dépense publicitaire — à lire avant d'envoyer du trafic payant vers une page dont vous ne connaissez pas encore l'attente réelle.
Ce qui sépare un chatbot d'un agent, et comment lire ce qu'on vous vend — le module de discussion figure parmi les scripts extérieurs qui occupent le navigateur : autant savoir ce qu'il fait avant de l'installer.
Ce soir, quinze minutes et une feuille
Prenez votre téléphone. Coupez le wifi, passez en données mobiles. Ouvrez une session de navigation privée — dans Chrome, les trois points en haut à droite, puis « Nouvel onglet de navigation privée ». Saisissez l'adresse de votre page d'accueil et comptez à voix haute, un nombre par seconde, jusqu'à ce que la grande image apparaisse. Cette mesure est grossière. Elle est la vôtre, et elle est faite là où sont vos clients.
Ensuite, sur un ordinateur, ouvrez pagespeed.web.dev et saisissez l'adresse complète d'une page précise, pas seulement votre nom de domaine. Ne lisez que le premier bloc, celui qui annonce les vingt-huit derniers jours de visiteurs réels. Relevez-y ce qu'il indique pour l'affichage du contenu principal et pour la réactivité. S'il est absent, écrivez-le sur votre feuille : c'est déjà un résultat.
Enfin, ouvrez votre propre page dans un onglet de ce navigateur — pas la page de résultats de l'outil. Appuyez sur la touche F12, choisissez l'onglet réseau, puis rechargez sans refermer ce panneau. Tout en bas, une ligne de résumé indique le nombre de fichiers demandés et le poids transféré. Notez ce poids.
Vous avez maintenant une feuille avec une date, une durée comptée à voix haute, les valeurs de terrain ou une mention d'absence, et un poids. C'est votre point de départ.
La prochaine fois qu'on vous montrera un cercle rouge, vous saurez quoi lui demander.
Sources
Les définitions, les repères et les modes de calcul décrits ici sont ceux publiés par Google. Ils ont été reformulés, non recopiés. Ces outils évoluent en continu : ce qui suit vaut à la date de consultation et se revérifie à la source.
Google, web.dev, « Web Vitals », web.dev/articles/vitals, consultée le 11 août 2026.
Google, web.dev, « Optimize Largest Contentful Paint », web.dev/articles/optimize-lcp, consultée le 11 août 2026.
Google, web.dev, « Interaction to Next Paint (INP) », web.dev/articles/inp, consultée le 11 août 2026.
Google, web.dev, « Cumulative Layout Shift (CLS) », web.dev/articles/cls, consultée le 11 août 2026.
Google, web.dev, « Time to First Byte (TTFB) », web.dev/articles/ttfb, consultée le 11 août 2026.
Google, web.dev, blog, « Interaction to Next Paint becomes a Core Web Vital on March 12 », web.dev/blog/inp-cwv-march-12, consultée le 11 août 2026.
Google, Chrome for Developers, « CrUX methodology », developer.chrome.com/docs/crux/methodology, consultée le 11 août 2026.
Google, « About PageSpeed Insights », developers.google.com/speed/docs/insights/v5/about, consultée le 11 août 2026.
Google, Chrome for Developers, « Lighthouse performance scoring », developer.chrome.com/docs/lighthouse/performance/performance-scoring, consultée le 11 août 2026.
Google, Search Central, « Understanding page experience in Google Search results », developers.google.com/search/docs/appearance/page-experience, consultée le 11 août 2026.
Google, Aide Search Console, « Rapport Signaux web essentiels », support.google.com/webmasters/answer/9205520, consultée le 11 août 2026.
INSEN STUDIO
On regarde votre situation ensemble ?
Vous repartez avec une lecture claire, avec ou sans nous.
Demander un audit digital
