La conversation sur la vitesse d'un site tourne presque toujours autour d'un score. Quelqu'un lance un outil, obtient 63 sur 100, et le chiffre devient l'objectif.

C'est la mauvaise cible. Le score est un indicateur indirect. Ce qui compte, c'est le nombre de personnes qui abandonnent avant d'avoir vu votre offre — et ces gens-là ne remplissent pas de formulaire pour vous prévenir.

Voici comment la vitesse coûte réellement de l'argent, ce qui la dégrade en pratique, et quoi mesurer.

L'abandon est invisible dans vos statistiques

Le problème structurel : un visiteur qui part avant le chargement complet n'apparaît souvent pas comme une visite. Le script d'analyse se charge tard — s'il n'a jamais démarré, la visite n'existe pas dans votre tableau de bord.

Vos statistiques décrivent donc les gens qui ont attendu. Ceux qui sont partis sont absents du rapport. C'est pour ça qu'un site lent semble avoir un taux de rebond correct : les plus impatients ont été filtrés avant d'être comptés.

Conséquence : vous ne pouvez pas évaluer un problème de vitesse à partir de vos analytiques seules. Il faut des données de terrain, qui mesurent l'expérience réelle, y compris celle des connexions lentes.

Les trois mesures qui comptent

Google en suit trois. Elles décrivent trois moments différents de l'expérience.

LCP — le temps avant de voir quelque chose d'utile. Techniquement, l'affichage du plus gros élément visible. Cible : moins de 2,5 secondes. C'est presque toujours l'image ou la vidéo d'en-tête.

INP — le délai entre un clic et la réaction. Cible : moins de 200 millisecondes. C'est du JavaScript qui occupe le fil principal pendant que l'utilisateur essaie d'interagir. Un menu qui met une demi-seconde à s'ouvrir donne l'impression d'un site cassé, même si la page s'est affichée vite.

CLS — le contenu qui bouge pendant le chargement. Cible : moins de 0,1. Vous lisez un paragraphe, une image finit de charger au-dessus, tout descend, vous cliquez sur le mauvais lien. Sur mobile, c'est la cause la plus fréquente de rage devant un site.

Ces trois-là ne se corrigent pas par les mêmes moyens. Un site peut être excellent sur LCP et catastrophique sur INP — typiquement un site statique bien optimisé sur lequel on a empilé six scripts tiers.

Laboratoire contre terrain : la distinction qui change tout

C'est le malentendu le plus coûteux du domaine.

Un test Lighthouse dans votre navigateur est une simulation. Il exécute la page sur votre machine, avec une connexion bridée artificiellement, une fois. Le résultat est reproductible et utile pour le diagnostic.

Google, lui, classe à partir de données de terrain : les mesures agrégées de vrais visiteurs, sur leurs vrais appareils et leurs vraies connexions, sur 28 jours.

Les deux divergent souvent, et dans un sens précis : le laboratoire est optimiste. Votre ordinateur portable en fibre n'est pas le téléphone de trois ans sur un réseau cellulaire moyen. Un site peut afficher 95 en laboratoire et échouer sur le terrain.

En pratique : servez-vous du laboratoire pour trouver les causes, du terrain pour savoir si vous avez un problème.

Ce qui ralentit réellement les sites

Après avoir diagnostiqué beaucoup de sites, les causes se répètent. Par ordre d'impact décroissant.

Les images non optimisées

De loin la première cause. Une photo de 4 Mo sortie d'un appareil, téléversée telle quelle, redimensionnée en CSS. Le navigateur télécharge les 4 Mo puis l'affiche en 800 pixels de large.

La correction est mécanique : redimensionner à la taille réellement affichée, servir en AVIF ou WebP, déclarer width et height pour réserver l'espace — ce dernier point corrige aussi le CLS.

Sur la plupart des sites d'entreprise, corriger uniquement les images règle la moitié du problème.

Les scripts tiers

Chaque outil ajouté — analytique, chat, pixel publicitaire, bandeau de consentement, carte, widget d'avis — charge du code que vous ne contrôlez pas, depuis un serveur que vous ne contrôlez pas.

Ils sont la cause dominante des mauvais INP. Le fil principal est occupé, donc l'interface ne répond pas.

L'exercice utile est brutal : listez chaque script tiers et demandez qui l'utilise réellement. Sur un site typique, un tiers d'entre eux ont été ajoutés pour une campagne terminée depuis longtemps.

Les polices web

Une police personnalisée bloque l'affichage du texte pendant son chargement, ou provoque un saut visuel quand elle remplace la police de secours.

Deux réglages règlent presque tout : font-display: swap pour afficher immédiatement le texte, et le préchargement de la police utilisée dans l'en-tête. Limitez aussi le nombre de graisses — chaque variante est un fichier.

Le JavaScript excessif

Un site de contenu qui expédie 500 Ko de JavaScript pour afficher du texte et des images paie un coût sans contrepartie. Le navigateur doit télécharger, analyser et exécuter tout ça avant que la page devienne interactive.

C'est le symptôme d'un choix d'architecture, pas d'un réglage. Un site rendu côté serveur ou généré statiquement envoie du HTML déjà complet ; le JavaScript ne sert plus qu'aux parties réellement interactives.

L'hébergement

Souvent accusé en premier, rarement coupable en premier. Un hébergement partagé lent ajoute du délai au premier octet, mais si votre page pèse 8 Mo, le serveur n'est pas votre problème.

Vérifiez le poids de la page avant de changer d'hébergeur.

Le lien avec le référencement

La vitesse est un facteur de classement, mais un facteur de départage — pas un levier principal. Une page rapide et hors sujet ne battra jamais une page lente et pertinente.

Ce qui compte davantage, et dont on parle moins : la vitesse affecte le budget d'exploration. Un robot qui reçoit vos pages lentement en explore moins par visite. Sur un petit site, sans conséquence. Sur un site de plusieurs centaines de pages, ça retarde l'indexation des nouvelles pages.

Et l'effet le plus direct n'a rien à voir avec Google : la vitesse affecte le taux de conversion. Ce gain existe même si votre classement ne bouge pas d'un rang.

Quoi mesurer, et dans quel ordre

1. Regardez d'abord les données de terrain. Search Console publie un rapport Core Web Vitals fondé sur les visiteurs réels. C'est votre verdict. S'il est vert, votre problème de vitesse est théorique.

2. Testez sur mobile, pas sur ordinateur. La majorité de votre trafic est mobile, et c'est là que les écarts se creusent.

3. Regardez le poids total de la page avant les scores. Sous 1 Mo, vous êtes en bonne posture. Au-delà de 3 Mo, vous avez un problème d'actifs, pas de configuration.

4. Isolez le plus gros contributeur. L'onglet réseau des outils de développement, trié par taille, désigne le coupable en quelques secondes. C'est presque toujours une image ou un script tiers.

5. Corrigez la plus grosse cause, puis remesurez. Une correction à la fois — sinon vous ne saurez pas ce qui a fonctionné.

Ce qui ne mérite pas votre temps

Chasser le 100. L'écart entre 85 et 100 est marginal pour l'utilisateur et coûteux à obtenir. L'écart entre 40 et 85 est énorme.

Optimiser une page que personne ne visite. Commencez par vos pages d'entrée les plus fréquentées.

Changer d'hébergeur avant d'avoir regardé le poids de la page.

Le score de la page d'accueil. Vos visiteurs arrivent souvent par une page de service ou un article. Mesurez les pages d'entrée réelles.

Ce qu'il faut retenir

La vitesse ne se juge pas sur un score mais sur une question : combien de personnes n'ont jamais vu votre offre parce que la page a mis trop de temps ?

Ces gens-là n'apparaissent pas dans vos statistiques. C'est ce qui rend le problème facile à ignorer — et coûteux à laisser traîner.

Commencez par les images, éliminez les scripts tiers dont plus personne ne se sert, puis remesurez sur le terrain. Ça règle la majorité des cas sans refonte.

Si vous préférez que ce soit fait plutôt qu'expliqué, voyez notre service de maintenance et de performance.