GuideDécider
Mon site est lent : d’où ça vient, ce qu’on répare, ce qu’on refait
En bref
Google juge un chargement « bon » quand le plus grand élément de la page s’affiche en 2,5 secondes ou moins (seuil relu le 10 octobre 2026). On distingue quatre causes de lenteur (serveur tardif, page trop lourde, scripts en retard, page qui saute) ; un test dans le navigateur montre de quel côté est la vôtre.
Un guide Refontly Mis à jour le 5 minutes de lecture
ExempleAiguilles placées pour l’illustration : aucune mesure
Une page bien réglée. Les quatre aiguilles restent dans la zone claire. C’est une page d’exemple : aucun site réel n’est mesuré ici.
Le serveur répond tard. Avant d’afficher quoi que ce soit, le navigateur attend la première réponse du serveur : web.dev donne comme repère 0,8 s ou moins pour une réponse bonne, plus de 1,8 s pour une mauvaise. Cette attente compte dans l’affichage du plus grand élément : elle pousse aussi la grande aiguille.
La page est trop lourde. Le plus grand élément, une image par exemple, met longtemps à arriver : la grande aiguille passe dans la zone sombre. Google juge l’affichage bon à 2,5 s ou moins, mauvais au-delà de 4 s.
Des scripts occupent le navigateur. Des scripts trop longs retardent la réaction aux clics : c’est le petit cadran de droite. Google la juge bonne à 200 ms ou moins, mauvaise au-delà de 500 ms.
La page saute en se chargeant. Une image sans dimensions, une publicité ou une vidéo insérée en route, une police qui change : le contenu se décale. Google juge les décalages bons à 0,1 ou moins, mauvais au-delà de 0,25.
Google mesure trois choses, les Core Web Vitals : l’affichage du plus grand élément (LCP), la réaction aux clics (INP) et les décalages de la page pendant son chargement (CLS). Le chronomètre y ajoute la réponse du serveur.
Comment savoir si mon site est vraiment lent ?
Ouvrez PageSpeed Insights, tapez l’adresse d’une de vos pages, puis lisez trois choses, dans cet ordre. C’est l’outil de Google : il s’ouvre dans le navigateur, sans rien installer.
-
Les vrais visiteurs
Les 28 derniers jours, chez de vrais visiteurs. Si le test simulé diverge, Google conseille de regarder d’abord ceux-là.
-
Mobile, puis ordinateur
Les deux se jugent à part. Pour être « bon », le seuil doit être atteint pour 75 % des visites, sur les trois mesures à la fois (sur deux mesures si l’INP manque de données).
-
Le test simulé
Un chargement simulé sur un appareil, dit « de laboratoire ». Sa note sur 100 (Lighthouse) n’est pas l’une des trois mesures : Google la juge bonne à partir de 90. Sans donnée réelle, c’est ce test qu’on lit.
Sources : Google Search Central, « Understanding Core Web Vitals and Google search results » (mise à jour le 10 décembre 2025) ; Google for Developers, « About PageSpeed Insights » (mise à jour le 21 octobre 2024) ; web.dev (Google), « Web Vitals » (mise à jour le 31 octobre 2024) ; web.dev (Google), « Optimize Largest Contentful Paint » (mise à jour le 31 mars 2025).
D’où vient la lenteur, et qu’est-ce qui se répare ?
Quatre causes se distinguent : chacune se lit sur son cadran et se répare à sa façon.
Les quatre causes, ce que Google en dit, ce qu’on répare, ce qui fait refaire
| La cause | Le repère de Google | Ce qu’on répare | Ce qui fait refaire |
|---|---|---|---|
| Le serveur répond tard Le navigateur attend la première réponse avant d’afficher quoi que ce soit. | Réponse du serveur, repère de web.dev : bonne à 0,8 s ou moins, mauvaise au-delà de 1,8 s. Ce n’est pas l’une des trois mesures. | Les redirections en série, le cache (des copies toutes prêtes des pages), l’hébergement. | Quand chaque page est fabriquée à la demande et que le cache est le seul remède. |
| La page est trop lourde Le plus grand élément, une image par exemple, met du temps à arriver. | Affichage du plus grand élément (LCP) : bon à 2,5 s ou moins, mauvais au-delà de 4 s. | Alléger l’image principale, et vérifier qu’aucun script ne retarde son affichage. | Pas à soi seul : une image se remplace. |
| Des scripts occupent le navigateur La page s’affiche, mais répond aux clics avec retard. | Réaction (INP) : bonne à 200 ms ou moins, mauvaise au-delà de 500 ms. Elle remplace le FID depuis le 12 mars 2024. | Retirer ou alléger les scripts dont la page n’a pas besoin. | Quand ces scripts font fonctionner le site : les retirer le casserait. |
| La page saute en se chargeant Le contenu se décale pendant le chargement. | Décalages (CLS) : bons à 0,1 ou moins, mauvais au-delà de 0,25. | Réserver la place des images (largeur et hauteur) ; publicités, vidéos et polices : chacune son réglage. | Pas à soi seul : ce sont des réglages, page par page. |
Les repères sont ceux de Google ; celui du serveur est un repère indicatif de web.dev. Les deux dernières colonnes sont notre lecture, pas la sienne. Les numéros sont ceux du chronomètre.
Sources : web.dev (Google), « Time to First Byte (TTFB) » (mise à jour le 18 novembre 2025) ; web.dev (Google), « Optimize Time to First Byte » (mise à jour le 28 novembre 2025) ; web.dev (Google), « Optimize Largest Contentful Paint » (mise à jour le 31 mars 2025) ; web.dev (Google), « Interaction to Next Paint is officially a Core Web Vital » (billet du 12 mars 2024) ; web.dev (Google), « Optimize Interaction to Next Paint » (mise à jour le 2 septembre 2025) ; web.dev (Google), « Optimize Cumulative Layout Shift » (mise à jour le 7 février 2025).
À quel moment vaut-il mieux refaire que réparer ?
Notre critère, pas celui de Google
On répare
tant que chaque réglage fait baisser la mesure.
On refait
quand le temps gagné d’un côté réapparaît de l’autre.
Ce n’est pas un seuil chiffré. Aucune source n’en donne un au-delà duquel refaire coûte moins cher que réparer, et nous n’en inventons pas : c’est le critère de Refontly, pas celui de Google. Il s’appuie sur web.dev : alléger une partie du chargement peut simplement déplacer le temps sur une autre. Pour juger le site entier, pas seulement sa vitesse : Mon site fait vieux.
L’autre raison tient à la construction. Par défaut, un site WordPress fabrique chaque page à la demande : un réglage règle un réglage, il ne change pas la façon dont le site est fabriqué. Sur mobile, en août 2026, parmi les sites dont HTTP Archive a des données de vrais visiteurs, 48,7 % des sites WordPress détectés avaient une évaluation « bonne » de Google, contre 71,0 % des sites Astro, l’outil avec lequel nous construisons ; la plateforme n’est pas la seule cause.
Sources : web.dev (Google), « Optimize Largest Contentful Paint » (mise à jour le 31 mars 2025) ; HTTP Archive, « Tech Report » (données d’août 2026, sur mobile) ; Search Engine Journal (Roger Montti), « Core Web Vitals: WordPress And Astro Versus Everyone Else » (publié le 27 mai 2026).
Questions rapides
- Google me pénalise-t-il parce que mon site est lent ?
- Ce n’est pas ainsi que Google le présente : il utilise les Core Web Vitals dans son classement, mais cherche d’abord le contenu le plus pertinent, même quand la page est lente.
- PageSpeed Insights n’affiche aucune donnée réelle : est-ce grave ?
- Non : un site récent ou peu visité peut n’en avoir aucune. Lisez alors le test simulé, en sachant que c’est une simulation.
- Pourquoi d’autres pages parlent-elles du FID ?
- Depuis le 12 mars 2024, la réactivité se mesure avec l’INP : le FID n’est plus un Core Web Vital.
Sources
Chaque fait cité ci-dessus vient de ces pages publiques, relues le 10 octobre 2026.
- Google Search Central, « Understanding Core Web Vitals and Google search results », mise à jour le 10 décembre 2025.
- web.dev (Google), « Web Vitals », mise à jour le 31 octobre 2024.
- Google for Developers, « About PageSpeed Insights », mise à jour le 21 octobre 2024.
- web.dev (Google), « Optimize Largest Contentful Paint », mise à jour le 31 mars 2025.
- web.dev (Google), « Time to First Byte (TTFB) », mise à jour le 18 novembre 2025.
- web.dev (Google), « Optimize Time to First Byte », mise à jour le 28 novembre 2025.
- web.dev (Google), « Interaction to Next Paint is officially a Core Web Vital », billet du 12 mars 2024.
- web.dev (Google), « Optimize Interaction to Next Paint », mise à jour le 2 septembre 2025.
- web.dev (Google), « Optimize Cumulative Layout Shift », mise à jour le 7 février 2025.
- Google Search Central, « Understanding page experience in Google Search results », mise à jour le 22 septembre 2026, lue le 10 octobre 2026.
- HTTP Archive, « Tech Report », données d’août 2026, sur mobile.
- Search Engine Journal (Roger Montti), « Core Web Vitals: WordPress And Astro Versus Everyone Else », publié le 27 mai 2026.