Pourquoi votre site est lent : audit réel, chiffres à l'appui
Publié le 16 juillet 2026 · 8 min de lecture
| Métrique | Avant | Après | Gain |
|---|---|---|---|
| Score performance Lighthouse | 0,63 | 0,94 | +0,31 |
| LCP (plus gros élément affiché) | 6 465 ms | 2 642 ms | −59 % |
| FCP (premier affichage) | 3 827 ms | 2 342 ms | −39 % |
| TBT (blocage du navigateur) | 254 ms | 0 ms | −100 % |
| JavaScript téléchargé | 1 251 kB | 520 kB | −58 % |
| Images embarquées | 6,17 Mo | 2,03 Mo | −67 % |
Ce que nous pensions être le problème
Notre diagnostic initial était le suspect habituel : un bundle JavaScript de 1,25 Mo, avec tout le code de notre espace d'administration embarqué dans la page que voient les visiteurs. Coupable idéal, hypothèse raisonnable.
Nous avons découpé le code. Le fichier principal est passé de 1 251 kB à 132 kB. Le score Lighthouse est passé de 0,65 à… 0,65.
Aucun changement. C'est la leçon la plus utile de cet audit, et elle vaut pour votre site : le poids du JavaScript n'est presque jamais ce qui plombe la note perçue. Il coûte de la bande passante, pas des millisecondes de rendu.
Ce qui était vraiment le problème : un logo
Le LCP (Largest Contentful Paint) mesure quand le plus gros élément visible apparaît. Google considère qu'il doit rester sous 2,5 secondes. Le nôtre était à 6,5 secondes.
L'élément en question : notre logo. Un PNG de 1000 × 641 pixels pesant 110 kB, affiché à 64 pixels de haut. Chaque visiteur téléchargeait une image quinze fois trop grande pour l'usage qu'on en faisait.
Converti en WebP à la bonne taille : 8 kB. Le LCP est tombé à 3,9 secondes. Un seul fichier, l'essentiel du gain.
Et ce n'était pas fini. Notre favicon était un JPEG de 1440 × 1440 pesant 207 kB — pour un affichage de 16 pixels. Nos logos clients étaient servis jusqu'en 1600 × 520 pour être affichés à 120 pixels de large : 911 kB au total, ramenés à 59 kB.
Les cinq causes réelles, par ordre d'impact
- Les images surdimensionnées. C'est la cause n°1, de loin, et la plus facile à corriger. Une image affichée à 200 px n'a besoin que de 400 px de large (le double, pour les écrans retina). Tout le reste est du gaspillage pur.
- Les scripts tiers. Google Tag Manager, Analytics, un pixel publicitaire : chacun est un fichier à télécharger et à exécuter avant que votre page ne réponde. Chez nous, ils représentaient 430 kB et 254 ms de blocage.
- Les polices bloquantes. Une feuille de style Google Fonts empêche le navigateur d'afficher quoi que ce soit tant qu'elle n'est pas chargée. Nous en avions deux, dont une en doublon.
- Le format des images. Un JPEG ou un PNG pèse typiquement deux fois plus lourd qu'un WebP à qualité visuelle identique. Sur nos captures de portfolio : 3 120 kB devenus 1 528 kB, sans différence visible à l'écran.
- Le JavaScript. Bon dernier. Il coûte de la bande passante et du cache, ce qui compte — mais bien moins que ce que le secteur raconte.
Ce que vous pouvez vérifier en dix minutes
Vous n'avez besoin d'aucun outil payant, ni de savoir coder.
- Ouvrez PageSpeed Insights (l'outil gratuit de Google) et entrez votre adresse. Regardez d'abord le LCP : au-dessus de 2,5 secondes, il y a un problème.
- Regardez quel élément est identifié comme le LCP. Neuf fois sur dix, c'est une image. Vérifiez son poids réel : au-delà de 100 kB pour une image d'interface, elle est trop lourde.
- Regardez la section « réduire le JavaScript inutilisé ». Si les gros fichiers viennent de domaines tiers (googletagmanager, facebook), le problème n'est pas votre site : c'est ce que vous y avez ajouté.
- Faites la mesure plusieurs fois. Un score Lighthouse varie de plusieurs points d'une mesure à l'autre. Nous avons nous-mêmes annoncé un gain à 0,81 avant de constater, sur cinq mesures, qu'il valait 0,78. Une mesure isolée ne prouve rien.
Pourquoi la vitesse compte vraiment
Google publie les seuils des Core Web Vitals : LCP sous 2,5 s, INP sous 200 ms, CLS sous 0,1. Ce sont des signaux utilisés pour le classement, mais ce n'est pas la vraie raison de s'en occuper.
La vraie raison : un visiteur qui attend s'en va. Et depuis que les IA génératives citent des sources, la vitesse a pris un second rôle — un site lent est un site que les robots explorent moins bien, donc moins susceptible d'être repris comme source.
Le bon réflexe n'est pas de viser 100 sur Lighthouse. C'est de mesurer avant de conclure. Nous avions un diagnostic parfaitement raisonnable, entièrement faux, que seule la mesure a démenti.
Questions fréquentes
Pourquoi mon site est-il lent alors qu'il est récent ?
L'âge n'a rien à voir. Dans la majorité des cas, ce sont des images non optimisées et des scripts tiers (Analytics, pixels publicitaires, chat en ligne). Un site neuf avec un logo de 110 kB et cinq scripts de suivi sera plus lent qu'un site de cinq ans bien construit.
Quel score Lighthouse faut-il viser ?
Au-dessus de 0,90 est un bon objectif ; viser 1,00 relève souvent du perfectionnisme coûteux. Surtout, mesurez plusieurs fois : le score varie sensiblement d'une exécution à l'autre. Une seule mesure ne permet aucune conclusion.
Faut-il supprimer Google Analytics pour aller plus vite ?
Pas nécessairement — mais chargez-le après le consentement de l'utilisateur plutôt que dans l'en-tête de la page. Sur notre site, ce seul changement a fait passer le temps de blocage de 254 ms à 0. Bénéfice double : vous gagnez en vitesse et vous vous conformez au RGPD.
Le format WebP est-il compatible avec tous les navigateurs ?
Oui, tous les navigateurs actuels le prennent en charge. Le gain est typiquement de 50 % de poids à qualité visuelle identique. Sur nos captures de portfolio, nous sommes passés de 3 120 kB à 1 528 kB sans différence perceptible, vérifiée par comparaison à l'échelle 1:1.
La vitesse influence-t-elle vraiment le référencement ?
Oui, les Core Web Vitals sont des signaux utilisés par Google. Mais l'effet direct sur le classement est modeste comparé à l'effet indirect : un visiteur qui attend repart, et ce comportement, lui, pèse lourd. Optimisez pour vos visiteurs, le référencement suivra.