Un jour, j'ai reçu un mail d'un client qui commençait par cette phrase : « On a perdu 12 000 euros cette semaine et je crois que c'est la faute de notre site. » Le site en question mettait un peu plus de six secondes à afficher sa page d'accueil sur mobile. Six secondes. Le temps de dire bonjour à quelqu'un, de remplir un verre d'eau, de se demander si on ne va pas plutôt aller voir ailleurs.
On a passé trois semaines dessus. À la fin, la page se chargeait en 1,4 seconde. Le taux de conversion du tunnel de commande est passé de 1,8 % à 3,2 % en deux mois. Je ne vous raconte pas ça pour m'envoyer des fleurs : je vous le raconte parce que l'optimisation de la vitesse de chargement d'un site web n'est pas un sujet de technicien, c'est un sujet d'argent qui sort par la porte pendant que vous dormez.
Points clés à retenir
- La vitesse de chargement se mesure sur trois indicateurs principaux : LCP, INP et CLS. Les seuils « bons » sont connus et publics : LCP sous 2,5 s, INP sous 200 ms, CLS sous 0,1.
- Dans la grande majorité des sites que j'ai audités, le problème numéro un était les images non optimisées, pas le serveur.
- Le plafond de verre d'un hébergement mutualisé à bas prix : vous serez bloqué autour de 1,5 à 2 secondes de temps de réponse, quoi que vous fassiez d'autre.
- Un CDN ne répare rien. Il masque. Si votre back-end met trois secondes à répondre, un CDN le rendra trois secondes à répondre depuis plus d'endroits.
- Optimiser une fois ne sert à rien. Il faut mesurer chaque mois, sinon le site regrossit tout seul.
- Le gain réel le plus rapide et le moins cher reste la compression des images. C'est là que je commence toujours.
Pourquoi la vitesse de chargement d'un site web impacte directement vos ventes
Le seuil des 3 secondes, on le lit partout. Il est vrai, mais il cache une réalité plus gênante : c'est une moyenne, et vos visiteurs ne vivent pas dans une moyenne. Un utilisateur sur une 4G correcte et un utilisateur sur un wifi de gare ne subissent pas le même site. Le second abandonne bien avant trois secondes.
Ce qui m'a le plus surpris en auditant, c'est le décalage entre la perception du dirigeant et celle du visiteur. Le dirigeant teste depuis son bureau, sur fibre, avec un ordinateur à 2 500 euros. Il trouve son site « rapide ». Pendant ce temps, plus de la moitié du trafic arrive sur un téléphone d'entrée ou milieu de gamme, souvent en 4G dégradée.
Ce que vous perdez concrètement
Sur un site e-commerce, le lien entre vitesse et panier moyen est brutal. J'ai comparé sur mon propre projet les sessions mobiles lentes (plus de 4 s de LCP) et les sessions rapides (moins de 2 s) : le taux d'ajout au panier était deux fois plus faible sur les lentes. Deux fois. Pas 10 %, pas 15 %.
Il y a trois raisons mécaniques à ça :
- L'utilisateur croit que le site est cassé et repart sur un concurrent, sans jamais savoir que votre page allait s'afficher.
- Le navigateur met du temps à rendre la page cliquable, donc les premiers clics tapent à côté et l'utilisateur se décourage.
- Google, depuis que l'Index Mobile First est la norme, juge votre site sur sa version mobile en priorité. Une version mobile lente, c'est un plafond de positionnement.
Le mythe du visiteur patient
Personne n'est patient. Moi non plus. J'ai déjà fermé l'onglet d'un site de matériel de randonnée parce qu'il mettait quatre secondes à afficher une photo de sac à dos. Le pire, c'est que le sac était parfait. Je suis allé l'acheter ailleurs.
Mesurer avant d'optimiser : la seule règle qui compte vraiment
La première erreur que j'ai faite, quand j'ai commencé à m'intéresser à ce sujet, c'était de vouloir tout optimiser en même temps. J'ai activé un CDN, minifié le CSS, installé trois plugins de cache, compressé des images à la chaîne. Résultat : le site ne s'affichait plus correctement sur Safari, et j'avais gagné 200 ms. Deux cents millisecondes. Pour une semaine de casse.
Depuis, je procède toujours dans le même ordre.
- On mesure l'état actuel, sur mobile, en conditions réelles.
- On identifie le goulot d'étranglement, pas les dix goulots.
- On corrige une chose. On remesure. On garde ou on annule.
- On recommence au point 1 la semaine suivante.
Les trois indicateurs à regarder en priorité
Vous n'avez pas besoin de dix métriques. Trois suffisent, et elles sont publiques :
- LCP (Largest Contentful Paint) : le temps avant que l'élément principal de la page s'affiche. Cible : moins de 2,5 s.
- INP (Interaction to Next Paint), qui a remplacé le FID comme indicateur de réactivité : le délai entre un clic et la réaction visible. Cible : moins de 200 ms.
- CLS (Cumulative Layout Shift) : les décalages de mise en page pendant le chargement. Cible : moins de 0,1.
Un site qui a un bon LCP et un mauvais CLS donne cette sensation désagréable où la page bouge sous le doigt. L'utilisateur clique sur « Ajouter au panier » et c'est le bouton « Voir la fiche » qui s'est déplacé dessous. Ça, ça ne se voit pas dans un graphique de trafic, mais ça se paie en commandes perdues.
Quel outil utiliser pour tester la vitesse de son site ?
Le plus fiable et le plus gratuit reste PageSpeed Insights : il vous donne à la fois les données de terrain (issues d'utilisateurs réels, les « Core Web Vitals ») et les données de laboratoire. Les données de terrain sont celles qui comptent, parce qu'elles mesurent vos visiteurs, pas un serveur dans une salle climatisée.
Pour aller plus loin, l'onglet Réseau des outils de développement de votre navigateur montre exactement ce qui se télécharge et l'ordre d'arrivée. C'est là que j'ai découvert, sur un client, qu'une police de caractères de 900 Ko était chargée entièrement pour afficher un seul mot en gras.
Les optimisations qui marchent vraiment, classées par rapport gain/effort
Tout ne se vaut pas. Voici mon classement, tiré de ce que j'ai personnellement mesuré sur une quinzaine de sites différents.
| Levier | Gain typique observé | Effort | Quand le faire |
|---|---|---|---|
| Compression et redimensionnement des images | 1 à 3 s sur une page riche en visuels | Faible | Toujours, en premier |
| Mise en cache navigateur et serveur | 200 à 800 ms sur les visites répétées | Faible à moyen | Dès qu'on a du trafic récurrent |
| Passage à un hébergement correct | 300 ms à 1,5 s de temps de réponse | Moyen (coût récurrent) | Quand le TTFB dépasse 800 ms |
| Suppression des scripts tiers inutiles | Très variable, parfois plus de 2 s | Faible | Quand la page charge plus de 10 domaines externes |
| Réécriture du thème ou du template | 500 ms à 2 s | Élevé | En dernier recours |
Les images, le coupable numéro un
Sans exagération, dans neuf audits sur dix que j'ai menés, les images pesaient plus lourd que tout le code réuni. Un site vitrine classique chargeait 8 Mo, dont 6,2 Mo d'images. Après redimensionnement aux dimensions réellement affichées et conversion en WebP, on est tombés à 900 Ko au total. Le LCP est passé de 4,1 s à 1,6 s.
La méthode qui marche :
- Redimensionner à la taille d'affichage réelle, pas à la taille de l'appareil photo.
- Convertir en WebP ou en AVIF. Le gain par rapport à un JPEG est souvent de 30 à 50 %.
- Ajouter
loading="lazy"sur tout ce qui est sous la ligne de flottaison, sauf sur l'image principale. Et ça, je le vois encore trop souvent : une image lazy-loaded en haut de page retarde le LCP au lieu de l'avancer. - Indiquer les dimensions en dur pour éviter le décalage de mise en page.
Le cache et le CDN, deux choses différentes
On confond souvent les deux. Le cache, c'est garder une version déjà générée de votre page pour ne pas la reconstruire à chaque visite. Le CDN, c'est servir vos fichiers depuis un serveur proche du visiteur.
Le cache serveur a sauvé plus de projets que n'importe quel CDN, à mon sens. Un site qui met 1,8 s juste pour que le serveur génère la page passe à 150 ms avec un bon cache de page. Ça, c'est un gain réel et immédiat.
Le CDN, lui, ne vous sauvera pas d'un back-end lent. J'ai vu des gens souscrire à une formule à 200 euros par mois en pensant régler un problème qui venait d'une requête SQL mal indexée. Ils ont gagné 100 ms et perdu 2 400 euros sur l'année.
Les scripts tiers, le tueur silencieux
Chaque outil d'analyse, chaque widget de chat, chaque bouton de réseau social ajoute une requête vers un domaine externe. Certains mettent plus d'une seconde à répondre, et le navigateur bloque pendant ce temps.
Sur un site que j'ai repris, il y avait onze scripts tiers. Onze. On en a gardé quatre. Le gain a été de 1,9 s sur mobile, sans toucher à une seule ligne de code métier.
La question à se poser pour chacun : « Si ce script disparaissait demain, est-ce que je perdrais de l'argent ? » Si la réponse est non ou « je ne sais pas », coupez. Vous pourrez toujours le remettre.
Et le chargement différé du JavaScript, ça vaut le coup ?
Oui, mais avec précaution. Différer un script qui doit s'exécuter immédiatement peut casser des fonctionnalités. Testez toujours sur un environnement de recette avant de déployer. Sur un site que j'ai optimisé, différer le script du panier a cassé le bouton d'ajout pour environ 4 % des visiteurs. On ne l'a vu qu'après deux jours.
Ce qui ne sert à rien (ou presque)
Il faut que je vous le dise, parce que vous allez tomber dessus en cherchant des conseils.
Les plugins de « boost de vitesse » qui promettent de tout régler en un clic : la plupart du temps, ils ajoutent du JavaScript et empirent la situation. J'en ai testé trois sur un même site, et deux sur trois ont dégradé le LCP. Le troisième l'a amélioré de 80 ms, ce qui ne justifie pas 79 euros par an.
Minifier le HTML, quand votre page pèse 8 Mo à cause des images, c'est repeindre une pièce pendant que la maison brûle. Ça ne fait pas de mal, mais ça ne change rien de perceptible.
Et le passage à HTTP/3 : intéressant sur les connexions instables, mais ce n'est jamais le levier qui débloque une situation. Si votre site met cinq secondes, HTTP/2 ou HTTP/3, le visiteur partira quand même.
Faire durer les gains dans le temps
Voilà le point que tout le monde rate. Vous optimisez, vous passez de 6 s à 1,5 s, vous êtes content. Six mois plus tard, le marketing a ajouté un carrousel, la direction a voulu un chatbot, quelqu'un a uploadé des photos en 4000 pixels de large. Vous êtes revenu à 4 s.
Un site web, ça grossit comme un grenier. Il faut y retourner régulièrement.
Ce que je fais désormais sur mes projets : un contrôle mensuel des Core Web Vitals, cinq minutes, et une règle simple posée à toute l'équipe — aucune image ne part en production sans passer par un outil de compression. C'est bête, mais c'est ce qui a tenu le plus longtemps.
Le vrai indicateur à surveiller n'est pas votre score PageSpeed du jour, c'est sa stabilité dans le temps. Un site qui reste sous 2,5 s de LCP pendant douze mois consécutifs, ça n'arrive jamais par hasard.
Et si je devais ne garder qu'une seule chose de toutes ces années à bricoler des sites trop lents, ce serait celle-ci : la vitesse n'est pas un projet qu'on termine. C'est une hygiène qu'on entretient, ou qu'on abandonne. Le jour où vous arrêterez de regarder, votre site recommencera tranquillement à grossir, une image mal compressée après l'autre.
