Pourquoi mon site est-il si lent ? Les vraies causes et comment les corriger

En bref : les suspects habituels, par ordre

La plupart des sites lents le sont pour la même poignée de raisons, et vous trouverez généralement la vôtre dans la liste ci-dessous. Les plus gros gains viennent presque toujours d'images trop lourdes et de scripts tiers que vous aviez oublié d'avoir ajoutés. Commencez par là, puis descendez dans la liste. Un test de vitesse ponctuel sur votre propre machine vous induira en erreur, c'est pourquoi la dernière étape, et la plus importante, consiste à mesurer la vitesse que vos vrais visiteurs ressentent sur leurs propres téléphones et réseaux.

• Images et médias lourds. Les photos non compressées et les fichiers surdimensionnés sont la première cause de chargements lents. Compressez, redimensionnez et utilisez des formats modernes.
• Trop de scripts tiers. Widgets de chat, pixels publicitaires, outils d'A/B testing et analytics lourds ajoutent chacun une taxe. Cela s'accumule vite.
• CSS et JavaScript bloquant le rendu. Le navigateur se fige sur les ressources qu'il doit charger avant de pouvoir afficher quoi que ce soit. Différez ce qui n'est pas indispensable d'emblée.
• Hébergement lent et absence de cache ou de CDN. Un hébergement mutualisé bon marché et un cache manquant signifient que chaque visiteur attend un serveur d'origine lent.
• Des Core Web Vitals dans le rouge. Même un site « rapide » peut sembler saccadé si le contenu saute partout ou si les boutons ne répondent pas. Ce sont les indicateurs que Google et vos utilisateurs remarquent.
• Mesurer la mauvaise chose. Un score de laboratoire sur une seule machine rapide n'est pas la vitesse que vos vrais visiteurs obtiennent. Surveillez les utilisateurs réels pour repérer le parcours lent qui vous coûte vraiment.

Images et médias lourds

Si votre site est lent, les images sont le premier endroit où regarder. Une seule photo de bannière exportée directement depuis un téléphone ou un outil de design peut peser trois ou quatre mégaoctets. Empilez-en quelques-unes sur une même page et vous avez bâti un site qui rame sur mobile, aussi propre que soit votre code.

La solution tient en trois volets. D'abord, redimensionnez les images à la taille à laquelle elles sont réellement affichées. Une photo montrée sur 600 pixels de large n'a pas besoin de faire 4000 pixels de large. Ensuite, compressez-les. Les outils et les chaînes de build peuvent réduire la plupart des images de moitié ou plus sans perte de qualité visible. Enfin, utilisez des formats modernes comme le WebP ou l'AVIF, bien plus légers que les vieux JPEG et PNG à qualité égale.

Deux gains faciles supplémentaires : chargez en différé (lazy load) les images situées sous la ligne de flottaison, pour que le navigateur ne les récupère que lorsque le visiteur s'en approche en faisant défiler la page, et définissez toujours une largeur et une hauteur explicites sur les images afin que la page ne saute pas pendant leur chargement. Ce dernier point compte plus qu'il n'y paraît, et nous y reviendrons en parlant des Core Web Vitals.

La vidéo, c'est la même histoire, en pire. Si vous devez en utiliser, hébergez-la sur une plateforme conçue pour le streaming et ne chargez le lecteur que lorsque quelqu'un interagit avec lui.

Trop de scripts tiers (la taxe cachée)

C'est la cause qui se cache au grand jour. Au fil d'une année, un site accumule discrètement un widget de chat, un outil de heatmap, un snippet d'A/B testing, deux pixels publicitaires, une bannière de cookies, un chargeur de polices et une balise d'analytics ou trois. Chacun paraissait inoffensif au moment de l'ajouter. Ensemble, ils sont souvent l'élément le plus lourd de la page, et le plus lent, parce qu'ils sollicitent des serveurs que vous ne contrôlez pas.

Les scripts tiers sont une taxe pour deux raisons. Ils ajoutent des octets à télécharger et à analyser, et ils ajoutent des allers-retours réseau vers d'autres domaines qui peuvent eux-mêmes être lents. Une seule balise marketing poussive peut empêcher le reste de votre page de devenir interactif, et vous ne pouvez généralement pas rendre ces serveurs externes plus rapides : votre seul levier est de supprimer ou de différer le script.

Faites l'inventaire de ce que vous avez. Ouvrez le panneau réseau de votre navigateur, chargez la page et triez par domaine. Vous trouverez presque à coup sûr des requêtes vers des services que vous aviez oubliés ou que vous n'utilisez plus depuis des mois. Supprimez tout ce dont vous n'avez pas activement besoin. Pour le reste, chargez-les de façon asynchrone ou une fois la page interactive, et envisagez une alternative plus légère. Les pires coupables sont rarement ceux que vous auriez devinés.

Une bonne habitude : traitez chaque nouveau script comme un coût, pas comme un ajout gratuit. Avant de coller un snippet sur votre site, demandez-vous s'il justifie son poids. Si vous lancez un nouveau projet, un coup d'œil rapide à une checklist de lancement de site vous aide à éviter de greffer cinq outils que vous devrez ensuite arracher.

CSS et JavaScript bloquant le rendu

Même avec des images légères et peu de scripts, une page peut sembler lente à cause de l'ordre dans lequel le navigateur fait les choses. Lorsque le navigateur rencontre une feuille de style ou un script dans l'en-tête de votre page, il doit souvent s'arrêter, télécharger ce fichier et le traiter avant de pouvoir afficher quoi que ce soit à l'écran. C'est ce blocage que les visiteurs perçoivent comme une page blanche.

Le but est de permettre au navigateur de montrer quelque chose d'utile le plus tôt possible. Intégrez en ligne le petit morceau de CSS nécessaire au rendu de ce qui est visible en premier (le contenu « au-dessus de la ligne de flottaison »), et chargez le reste ensuite. Pour le JavaScript, utilisez les attributs defer ou async afin que les scripts ne bloquent pas le premier affichage, et découpez les gros bundles pour que le navigateur ne télécharge que le code dont une page donnée a réellement besoin.

Les frameworks et les constructeurs de sites modernes gèrent une bonne partie de cela pour vous, mais pas tout. Les polices sont un coupable courant : une police web personnalisée qui empêche le texte de s'afficher laisse les visiteurs face à du vide, ou provoque un clignotement quand le texte bascule. Dites au navigateur d'afficher immédiatement un texte de repli pendant que la police se charge. Petit changement, vraie différence.

Hébergement, cache et CDN

Parfois, la page elle-même est correcte et c'est le serveur derrière elle qui pose problème. Sur un hébergement mutualisé bas de gamme, votre site partage une machine avec des centaines d'autres, et quand l'un d'eux est très sollicité, tout le monde ralentit. Le premier octet de votre page peut mettre une seconde ou plus à arriver avant même que quoi que ce soit d'autre commence. Si votre temps jusqu'au premier octet est systématiquement lent, aucune compression d'image ne vous sauvera.

Le cache est ici la solution au plus fort levier. Un cache stocke une copie déjà prête de vos pages pour que le serveur ne les reconstruise pas à chaque requête. Pour un site de contenu ou un blog, la mise en cache de pages entières peut transformer une origine poussive en quelque chose qui répond presque instantanément. La plupart des plateformes et des systèmes de gestion de contenu intègrent un cache ou en proposent un via une extension.

Un réseau de diffusion de contenu (CDN) est l'autre grand levier. Un CDN garde des copies de vos fichiers statiques (images, CSS, JavaScript) sur des serveurs répartis dans le monde, de sorte qu'un visiteur à Sydney charge depuis une ville proche au lieu d'attendre que les octets traversent un océan depuis votre origine à Francfort. Pour une audience mondiale, cela seul peut réduire sensiblement le temps de chargement, et si votre hébergement n'en inclut pas, de nombreux CDN sont gratuits pour démarrer.

Et avant que tout cela ne compte, encore faut-il que le serveur soit en ligne. Un site hors service est infiniment lent, et les pannes ont le don de survenir aux pires moments sans que personne ne s'en aperçoive pendant des heures. Si vous ne vous êtes jamais demandé ce que votre hébergement garantit réellement, nos notes sur la disponibilité d'un site expliquent pourquoi une série de petites pannes finit discrètement par représenter bien plus de temps perdu que la plupart des propriétaires ne le supposent. Savoir à l'instant où votre origine s'éteint, ou commence à répondre lentement, est le socle sur lequel repose tout le reste.

Les Core Web Vitals expliqués simplement

Google mesure la vitesse d'un site à travers un ensemble d'indicateurs appelés Core Web Vitals, qui apparaissent dans la recherche et dans le rapport d'expérience Chrome. Ils valent la peine d'être compris car ils correspondent de près à ce qu'un vrai visiteur ressent réellement, et pas seulement au temps de téléchargement brut. Il y en a trois, et leurs seuils sont publics sur web.dev.

Le Largest Contentful Paint (LCP) mesure le temps nécessaire pour que le plus grand élément visible (généralement votre image de bannière ou votre titre) finisse de se charger. Visez moins de 2,5 secondes. L'Interaction to Next Paint (INP) mesure la rapidité avec laquelle la page répond quand quelqu'un tape ou clique, avec un objectif sous 200 millisecondes. Le Cumulative Layout Shift (CLS) mesure à quel point la page saute pendant son chargement, et vous le voulez sous 0,1. Vous pouvez lire les définitions complètes sur la page officielle des Core Web Vitals.

En termes simples : le LCP, c'est « à quelle vitesse la page est-elle apparue », l'INP, c'est « à quelle vitesse réagit-elle quand je la touche », et le CLS, c'est « la mise en page est-elle restée en place ou le bouton a-t-il bougé juste au moment où j'allais le toucher ». Ce CLS rejoint directement les images sans dimensions et les publicités qui se chargent en retard, ce qui explique pourquoi définir une largeur et une hauteur sur les images compte autant. Si un terme vous est inconnu ici, le glossaire en réunit les principaux au même endroit.

Deux des trois indicateurs concernent la réactivité et la stabilité, pas seulement la vitesse de téléchargement. C'est justement ce qu'un unique passage de Lighthouse sur votre ordinateur portable a tendance à masquer, ce qui nous amène à la section la plus importante.

Les données de laboratoire mentent : surveillez vos vrais utilisateurs

Voici le hic qui sape la plupart des efforts sur la vitesse. Quand vous lancez un outil comme Lighthouse et obtenez un score éclatant, c'est un test de laboratoire : une page, une machine rapide, une connexion stable, exécuté une seule fois. Vos vrais visiteurs n'ont rien à voir avec cela. Ils sont sur des téléphones de milieu de gamme, sur le wifi d'un hôtel, dans un train, avec une douzaine d'onglets ouverts en arrière-plan. La vitesse qu'ils obtiennent peut être radicalement différente de ce que rapporte votre ordinateur portable, et un script qui se charge sans problème chez vous peut être ce qui ralentit tous les autres.

C'est pourquoi un score unique, aussi vert soit-il, ne suffit pas. Le seul moyen de connaître la vitesse que les gens ressentent réellement est de la mesurer de leur côté, sur leurs appareils et leurs réseaux, en continu. Quand vous pouvez observer la vitesse que vos vrais visiteurs obtiennent, vous cessez d'optimiser pour un chiffre que personne d'autre ne voit et vous commencez à corriger le parcours lent qui vous coûte des visiteurs : la page rapide sur votre machine mais qui se fige sur un téléphone, le script impeccable en fibre mais qui bloque tout en données mobiles.

L'endroit le plus simple par où commencer est la question la plus élémentaire de toutes : le site répond-il seulement en ce moment, et à quelle vitesse ? Vous ne pouvez pas corriger un ralentissement dont vous n'entendez jamais parler, et les pannes comme les réponses lentes ont l'habitude de passer inaperçues pendant des heures. Un peu de surveillance de disponibilité qui contrôle votre origine à intervalles réguliers vous dira quand les temps de premier octet augmentent ou que le serveur se tait, ce qui est le socle sous toutes les autres corrections de cet article.

Une fois que vous surveillez vos vrais utilisateurs, le travail change. Au lieu de courir après un score de laboratoire parfait, vous guettez les pages et les appareils où la vitesse décroche, vous les corrigez et vous confirmez que la correction a tenu pour de vraies personnes. Pour un cadre plus large sur ce qu'il faut suivre et pourquoi, notre guide des bonnes pratiques d'analyse web explique comment relier les données de vitesse et de comportement à des résultats qui comptent.