Pourquoi mon site est-il si lent ? Causes et solutions
Dernière mise à jour:
Votre site se charge, finalement. Les visiteurs n'attendent pas "finalement". Si vous avez regardé votre page d'accueil ramer sur votre téléphone en vous demandant ce qui cloche, voici les vraies causes, dans l'ordre où elles comptent le plus, et ce que chaque correction implique réellement. Pas de conseils vagues. Les vrais coupables, classés.
Quel est le moyen le plus rapide de savoir pourquoi mon site est lent ?
Passez votre site dans Google PageSpeed Insights (pagespeed.web.dev). C'est gratuit, l'outil teste la vraie page et vous donne vos Core Web Vitals ainsi qu'une liste priorisée de ce qui ralentit la page. Testez la page la plus importante (souvent l'accueil ou une page produit clé) sur mobile, car c'est là que la lenteur fait le plus mal.
PageSpeed donne trois chiffres à connaître. Le Largest Contentful Paint (LCP) est le temps avant l'apparition du contenu principal. Google le juge bon sous 2,5 secondes. Le Cumulative Layout Shift (CLS) mesure les sauts de la page pendant le chargement. Bon : sous 0,1. L'Interaction to Next Paint (INP) mesure la rapidité de réponse au tap ou au clic. Bon : sous 200 millisecondes. Si l'un d'eux est dans le rouge, le rapport pointe directement la cause. Commencez là avant de changer quoi que ce soit, sinon vous devinez.
Un avertissement sur le score lui-même : le grand chiffre en haut varie beaucoup d'un test à l'autre. Ne courez pas après le 100. Lisez plutôt les sections "Diagnostics" et "Opportunities", c'est là que sont les vraies instructions.
Les vraies causes d'un site lent, classées
La plupart des sites lents le sont pour l'une de six raisons, et elles apparaissent en général dans cet ordre d'impact. Les voici avec la correction de chacune.
| Cause | Fréquence | Correction habituelle | Effort |
|---|---|---|---|
| Images trop lourdes | Très courant | Compresser + redimensionner + servir en WebP | Faible |
| Hébergement lent ou surchargé | Courant | Passer à un hébergement plus rapide et bien dimensionné | Moyen |
| Trop de JavaScript / extensions lourdes | Courant | Supprimer ou différer les scripts non essentiels | Moyen |
| Pas de cache ni de CDN | Courant | Activer le cache + un réseau de diffusion de contenu | Faible à moyen |
| CSS et polices bloquant le rendu | Modéré | Différer le CSS non critique, précharger les polices clés | Moyen |
| Constructeurs/thèmes surchargés | Modéré | Remplacer le thème lourd ou reconstruire léger | Élevé |
Les images trop lourdes sont la cause numéro un
Les images sont l'élément le plus lourd de la plupart des pages, et les images non optimisées sont la raison la plus courante d'un site qui paraît lent. Une photo sortie directement d'un téléphone peut peser 4 à 8 mégaoctets. Sur une page qui devrait peser quelques centaines de kilooctets au total, une seule image de ce type bloque tout.
La correction tient en trois gestes ensemble : redimensionnez l'image à la taille réelle d'affichage (une photo de 4000 pixels de large affichée dans un emplacement de 800 pixels gaspille 80 % de ses données), compressez-la, et servez-la dans un format moderne comme WebP, en général 25 à 35 % plus léger que le JPEG équivalent. Ajoutez au passage les attributs largeur et hauteur pour que la page ne saute pas au chargement des images, ce qui corrige aussi une partie de votre score CLS.
L'hébergement bon marché ou surchargé est la cause qu'on néglige
Voici celle qu'on diagnostique le plus mal. Les propriétaires passent des jours à compresser des images et à alléger du code, et le site reste lent, parce que le goulot d'étranglement est le serveur lui-même. Sur un hébergement mutualisé bon marché, votre site partage une machine avec des centaines d'autres qui se disputent la même mémoire et le même processeur. Quand un voisin reçoit un pic de trafic, votre site ralentit, et vous n'y pouvez rien de votre côté.
Vous le repérez dans PageSpeed sous la forme d'un temps de réponse serveur élevé (aussi appelé Time to First Byte). Si le serveur met plus d'environ 600 millisecondes rien que pour commencer à envoyer la page, le problème vient de l'hébergement, pas de vos images. Il y a un second facteur d'hébergement : l'emplacement physique du serveur. Un serveur loin de vos visiteurs ajoute de la latence à chaque requête, ce qui explique l'utilité d'un réseau de diffusion de contenu (voir plus bas) même quand le serveur lui-même va bien.
C'est la cause que nous voyons le plus souvent derrière un site qui "fonctionnait bien avant". Notre hébergement géré rapide tourne sur une infrastructure correctement dimensionnée, avec certificat SSL gratuit, sauvegardes quotidiennes et surveillance, pour qu'un voisin bruyant ne décide pas de la vitesse de chargement de votre entreprise.
Trop de JavaScript et trop d'extensions
Chaque script chargé par la page doit être téléchargé, analysé et exécuté avant que la page soit pleinement interactive. Un site qui a accumulé une dizaine d'extensions au fil des ans, un widget de chat, trois outils d'analytics, un constructeur de popups, des flux sociaux, transporte beaucoup de code qui s'exécute à chaque visite. C'est souvent ce qui se cache derrière un mauvais score INP : la page semble prête mais ne répond pas au tap parce que le navigateur est encore occupé.
La correction est un audit, pas une devinette. Listez chaque script et chaque extension, puis demandez-vous pour chacun s'il justifie son poids. Supprimez ce que vous n'utilisez pas. Pour ce qui reste, différez ou chargez en asynchrone tout ce qui n'est pas nécessaire au premier affichage, pour que la page visible apparaisse avant la fin des scripts d'arrière-plan.
Pas de mise en cache, pas de CDN
Sans mise en cache, votre serveur reconstruit la page entière de zéro pour chaque visiteur, même quand rien n'a changé. La mise en cache stocke une copie prête et la sert à la place, ce qui est beaucoup plus rapide et plus léger pour le serveur. Un CDN va plus loin en gardant des copies de votre site sur des serveurs partout dans le monde, pour qu'un visiteur à Paris ou à Lyon reçoive vos pages depuis un emplacement proche plutôt qu'un continent plus loin.
Les deux sont en général des gains rapides. Beaucoup d'hébergeurs incluent la mise en cache, et Cloudflare propose un CDN gratuit qui couvre la plupart des besoins des petites entreprises. Si vous n'utilisez ni l'un ni l'autre, c'est souvent le plus gros gain de vitesse au meilleur prix.
Le CSS et les polices qui bloquent le rendu
Celle-ci est plus subtile. Les navigateurs n'affichent pas votre page tant qu'ils n'ont pas chargé le CSS, et souvent les polices, situés dans l'en-tête de la page. Si ces fichiers sont volumineux ou chargés depuis un tiers lent, votre visiteur fixe un écran blanc pendant le téléchargement. Les polices personnalisées tirées d'un service externe sont un coupable fréquent.
Les corrections sont techniques mais bien établies : intégrez le peu de CSS nécessaire au haut de la page, différez le reste, hébergez vos polices vous-même au lieu d'appeler un tiers, et réglez font-display: swap pour que le texte apparaisse aussitôt dans une police de repli au lieu d'attendre. C'est le type de travail qui fait le plus bouger votre score LCP une fois les images et l'hébergement réglés.
Constructeurs de pages lourds et thèmes surchargés
Certains constructeurs glisser-déposer populaires et thèmes polyvalents génèrent d'énormes quantités de code pour prendre en charge chaque fonctionnalité dont vous pourriez avoir besoin un jour. Vous payez le tout à chaque chargement de page, même les fonctions que vous ne touchez jamais. Si votre site repose sur un thème lourd et que vous avez tout corrigé mais qu'il reste poussif, la fondation elle-même est peut-être la limite.
Il n'y a pas de correction légère ici. La réponse honnête est qu'un site léger et conçu pour son usage battra toujours un site surchargé, et qu'à un certain point reconstruire sur une base propre coûte moins cher que de rapiécer sans fin autour de la surcharge. C'est une décision plus lourde, et c'est le moment où la plupart des propriétaires font appel à de l'aide.
Quand arrêter de bricoler et faire appel à un professionnel ?
Faites appel à de l'aide quand vous avez lancé PageSpeed, corrigé les problèmes évidents d'images et de cache, et que le site reste lent, ou quand le rapport pointe l'hébergement, les ressources bloquant le rendu ou la surcharge du thème, plus difficiles à corriger sans risque sur un site en production. Dans ces cas, l'essai-erreur risque de casser le site.
Quelques signes qu'il est temps : la lenteur a commencé après un changement d'hébergeur ou une hausse de trafic (hébergement), le score est plombé par "reduce unused JavaScript" ou "eliminate render-blocking resources" (code), ou vous avez tout simplement perdu la possibilité de modifier le site correctement. Web Roots gère exactement cela via la migration et le sauvetage de site, en déplaçant un site lent vers un hébergement plus rapide sans interruption et sans perte de classement, et via la conception et le développement web quand la vraie solution est une reconstruction plus légère.
Comment garder mon site rapide après l'avoir corrigé ?
La vitesse n'est pas une correction unique, elle se dégrade avec le temps à mesure que vous ajoutez images, pages et outils. Gardez-la avec quelques habitudes : compressez chaque image avant de la téléverser, passez en revue les extensions deux fois par an et supprimez ce que vous n'utilisez pas, gardez le cache activé, et relancez PageSpeed après tout changement important pour repérer une régression la semaine même plutôt que des mois plus tard quand les clients commencent à partir.
Un hébergement fiable fait beaucoup de cela discrètement en arrière-plan. Sur un hébergement web géré avec surveillance, la lente dérive qui prend la plupart des sites au dépourvu est repérée et traitée avant de devenir la raison pour laquelle quelqu'un s'en va.
Votre site reste lent après les corrections faciles ? Nous trouvons la vraie cause et la corrigeons, y compris en vous déplaçant vers un hébergement plus rapide sans interruption ni perte de classement. Parlez à Web Roots pour accélérer votre site.