Ce que coûte vraiment un site lent
La lenteur ne se paie pas en secondes, elle se paie en visiteurs partis avant d'être comptés. Les seuils publics, les cinq causes réelles, et par quoi commencer.
Un site lent ne vous envoie pas de facture. C'est précisément ce qui le rend coûteux : la dépense est invisible.
Un visiteur qui abandonne pendant le chargement ne remplit aucun formulaire, ne laisse aucune trace exploitable, et n'apparaît nulle part dans vos statistiques comme un client perdu. Il apparaît, au mieux, comme une visite très courte. Vous ne pouvez pas manquer ce que vous ne mesurez pas.
La lenteur se paie en visiteurs partis avant d’être comptés, et cette dépense n’apparaît dans aucune statistique. Les seuils sont publics : affichage du plus gros élément en 2,5 secondes ou moins, réactivité sous 200 millisecondes, stabilité visuelle à 0,1 ou moins, mesurés au 75e percentile (Core Web Vitals). Les images non redimensionnées et les scripts tiers expliquent la majorité des cas, et se corrigent sans refonte.
Les seuils ne sont pas une affaire d'opinion
Il existe des barres publiques, publiées par Google, et elles sont chiffrées. Ce sont les Core Web Vitals, évaluées au 75e percentile des chargements, séparément sur mobile et sur ordinateur.
| Indicateur | Ce qu'il mesure | Seuil « bon » |
|---|---|---|
| LCP | Le temps avant l'affichage du plus gros élément visible | 2,5 secondes ou moins |
| INP | Le délai de réaction du site à une interaction | 200 millisecondes ou moins |
| CLS | La stabilité visuelle, les éléments qui sautent pendant le chargement | 0,1 ou moins |
Deux précisions qui changent la lecture de ce tableau.
Le 75e percentile, pas la moyenne. Il ne s'agit pas d'être rapide en général : il s'agit que trois chargements sur quatre passent la barre. Une moyenne flatteuse peut masquer un quart de visiteurs mal servis.
Sur mobile, sur un vrai réseau. C'est là que se joue la majorité des visites, et c'est là que les sites échouent. Un site testé sur l'ordinateur du développeur, en fibre, ne mesure rien d'utile.
Le CLS mérite un mot à part, parce qu'il est le plus sous-estimé. Il ne mesure pas la vitesse mais les sauts de mise en page : le bouton qui se déplace au moment où vous appuyez dessus, le texte qui descend parce qu'une image arrive en retard. C'est agaçant à un point qui fait partir, et ça n'a rien à voir avec la puissance de votre hébergement.
Où mesurer, gratuitement
- PageSpeed Insights : donnez une adresse, il rend les trois indicateurs et une liste de correctifs classés par gain. C'est le point de départ.
- Les données de terrain, dans ce même rapport, quand elles existent : ce sont les mesures des vrais visiteurs, sur leurs vrais appareils. Elles priment toujours sur la mesure de laboratoire.
- La Search Console, rubrique « Signaux web essentiels » : elle regroupe vos pages par type de problème, ce qui évite de corriger cent fois la même chose.
Un conseil de méthode : mesurez trois fois, à des moments différents. Une mesure isolée attrape des variations de réseau et fait prendre du bruit pour un diagnostic.
Pourquoi mon site est lent : les cinq causes, par ordre de fréquence
Les images
C'est la première cause, et de très loin. Une photographie sortie d'un appareil pèse plusieurs mégaoctets, alors qu'elle sera affichée dans un cadre de quelques centaines de pixels. Le visiteur télécharge la totalité.
Trois gestes règlent l'essentiel : redimensionner aux dimensions réelles d'affichage, servir un format moderne (WebP, AVIF), et différer le chargement des images situées plus bas dans la page. C'est la correction avec le meilleur rapport effort sur gain, et elle ne demande aucune reconstruction.
Les scripts tiers
Chaque outil ajouté charge du code hébergé ailleurs : mesure d'audience, chat en direct, bannière de consentement, pixels publicitaires, polices distantes, carte interactive. Chacun paraît anodin. Additionnés, ils dominent souvent le temps de chargement, et vous ne contrôlez ni leur poids ni leur disponibilité.
L'inventaire est instructif : listez tout ce qui se charge et demandez, pour chaque ligne, qui l'utilise et pour quoi. Il en reste rarement la moitié.
Les extensions empilées
Sur une installation qui vit depuis quelques années, on trouve régulièrement des extensions installées pour un besoin ponctuel et jamais retirées. Chacune charge son code sur toutes les pages, y compris celles qui n'en ont pas l'usage.
L'hébergement
Un hébergement mutualisé bon marché partage une machine entre des centaines de sites. Le temps de réponse du serveur devient le plancher de tout le reste : si le serveur met une seconde à répondre, aucune optimisation d'image ne vous ramènera sous ce seuil.
C'est souvent la ligne la plus rentable d'un budget, et souvent la plus rognée.
Le socle lui-même
Quand tout ce qui précède a été traité et que la page reste lourde, la cause est structurelle : le site charge un socle générique conçu pour couvrir tous les usages possibles, dont les vôtres ne sont qu'une petite partie. Il n'y a alors plus rien à retirer, parce que le poids n'est pas dans ce que vous avez ajouté. Voir WordPress ou site sur mesure.
« Site ralenti », « site en surcharge » : deux messages, deux problèmes
Les deux formulations reviennent souvent et ne décrivent pas la même panne.
Un site ralenti répond, mais lentement. Les pages s'affichent, l'affichage traîne, les seuils du tableau plus haut ne sont pas tenus. C'est un problème d'optimisation, et ce sont les cinq causes ci-dessus.
Un site en surcharge ne répond plus. Le serveur rend une erreur au lieu
d'une page : 503 Service indisponible quand il est saturé ou en maintenance,
429 Trop de requêtes quand il refuse le débit demandé. Aucune optimisation
d'image ne corrige cela, parce que le problème n'est pas le poids de la page,
c'est la capacité à la servir.
La distinction change ce qu'on regarde. Sur un site ralenti, on suit les six étapes de la section suivante. Sur un site en surcharge, on cherche d'abord ce qui consomme : un pic de trafic réel, un robot d'aspiration, une tâche planifiée qui tourne aux heures de visite, une extension qui interroge la base à chaque page. La formule d'hébergement ne vient qu'après, quand la consommation est légitime.
Et il y a une conséquence côté Google, qu'il vaut mieux connaître avant que la
situation dure. Sa documentation est explicite : « Les erreurs du serveur 5xx
et 429 invitent les robots d'exploration Google à ralentir temporairement
l'exploration. » Et si elles persistent, « les URL déjà indexées sont
conservées, mais finissent par être supprimées de l'index »
(Effet des codes d'état HTTP sur les robots d'exploration Google).
Un site indisponible quelques heures ne se paie pas. Un site en surcharge
récurrente finit par disparaître des résultats.
Le coût, dans l'ordre où il se paie
En visiteurs perdus. C'est la dépense principale et la seule qui compte vraiment. Elle est invisible parce que ceux qui partent ne sont jamais comptés comme des clients manqués.
En crédibilité. Un site lent signale un manque de soin. Le raccourci est injuste, il est fait quand même, et il est fait par des gens qui comparent trois entreprises en trois minutes.
En classement. L'expérience de page fait partie des signaux utilisés par Google. Il faut être précis sur ce point : la vitesse départage des pages déjà pertinentes, elle ne rend pas visible une page qui n'existe pas. Si vous êtes absent des résultats, le problème n'est pas la vitesse : voir pourquoi votre site n'apparaît pas sur Google.
En budget publicitaire. Si vous achetez du trafic, chaque visiteur perdu pendant le chargement est un clic payé pour rien. C'est la seule ligne du tableau qui se chiffre directement, et c'est souvent celle qui déclenche la décision.
Par quoi commencer, concrètement
- Mesurer. PageSpeed Insights sur vos trois pages les plus consultées, en mobile, trois fois.
- Les images. Redimensionner, convertir, différer. Vous verrez le gain immédiatement, et c'est presque toujours le plus gros.
- L'inventaire des scripts. Retirer ce dont personne ne se sert. Aucun développement, juste des décisions.
- Les extensions inutilisées, si le site en utilise.
- L'hébergement, si le temps de réponse du serveur reste haut après les trois étapes précédentes.
- Remesurer. Sans cette étape, vous ne saurez pas ce qui a produit l'effet, et vous referez la même chose au hasard la prochaine fois.
Les étapes 2 et 3 suffisent dans la majorité des cas, et elles ne demandent ni refonte ni budget de développement. C'est ce qu'il faut essayer avant d'envisager quoi que ce soit de plus lourd.
Quand la lenteur n'est plus le sujet
Si les six étapes sont faites et que le site reste sous les seuils, il ne s'agit plus d'optimisation. Le poids est dans le socle, et on ne rend pas léger par correctif ce qui a été construit lourd.
À ce moment-là, la question devient celle du coût de possession : combien coûtera chaque année de rattrapage, comparé à une reconstruction qui n'aura plus rien à rattraper. Voir la refonte de site internet.
Vous voulez savoir où vous en êtes sans y passer la journée ? Envoyez-nous l'adresse de votre site : nous regardons ce qui pèse, ce qui se corrige sans tout refaire, et ce qui relève de la structure. C'est aussi le premier temps de toute refonte.
Votre cas n’est pas le cas général.
Un article répond à une question ; un premier échange d’une vingtaine de minutes répond à la vôtre. Il n’engage rien et ne se termine pas par un devis automatique.
Décrire votre situation