Pourquoi mon site internet est-il lent ?

Un site internet est lent, le plus souvent, pour une poignée de raisons : des images trop lourdes, trop d'extensions ou de scripts ajoutés au fil du temps, un hébergement sous-dimensionné ou des polices de caractères mal chargées. Bonne nouvelle : ces causes se mesurent avec des outils gratuits, et la plupart se corrigent sans tout refaire.

Pourquoi la vitesse compte

Un visiteur qui attend devant une page blanche, sur son téléphone et avec une connexion moyenne, finit par repartir. La lenteur coûte des demandes de contact ou des ventes sans que vous vous en rendiez compte : ceux qui sont partis ne se plaignent pas, ils vont voir ailleurs. Google, de son côté, tient compte de l'expérience offerte par la page parmi de nombreux critères. La vitesse ne fait pas tout, mais un site pénible à utiliser part avec un handicap.

Les causes habituelles d'un site lent

Des images trop lourdes

C'est le coupable le plus courant. Une photo prise au téléphone pèse plusieurs mégaoctets et mesure des milliers de pixels de large, alors qu'elle s'affiche dans un cadre de quelques centaines de pixels. Le navigateur télécharge tout, puis réduit l'image à l'écran. Les remèdes :

• redimensionner chaque image à sa taille réelle d'affichage, avec des variantes pour mobile et grand écran ;
• utiliser des formats modernes comme WebP ou AVIF, plus légers à qualité égale ;
• ne charger les images placées bas dans la page qu'à l'approche du visiteur (chargement différé) ;
• déclarer leurs dimensions dans le code, pour que la mise en page ne saute pas pendant le chargement.

Trop d'extensions

Sur un site construit avec un système comme WordPress, chaque extension ajoutée (galerie, formulaire, partage sur les réseaux, animations) peut charger ses propres fichiers sur toutes les pages, même là où elle ne sert pas. Certains thèmes « tout-en-un » embarquent aussi des dizaines de fonctions jamais utilisées. Faites l'inventaire : désactivez puis supprimez ce qui ne sert plus, remplacez les extensions lourdes par des solutions plus simples et gardez le reste à jour.

Un hébergement à bout de souffle

Avant d'afficher quoi que ce soit, le navigateur attend la réponse du serveur. Si cette attente est longue sur toutes les pages, l'hébergement est souvent en cause : offre trop juste pour le trafic, serveur surchargé, version de PHP ancienne, absence de cache, ou serveur éloigné de vos visiteurs. Un site dynamique sans cache recalcule chaque page à chaque visite, ce qui pèse vite. Si vous envisagez de changer, voici les critères d'un bon hébergement.

Les scripts tiers

Fenêtre de discussion, mesure d'audience, pixels publicitaires, vidéos intégrées, cartes, widgets d'avis : chacun charge du code depuis un serveur extérieur que vous ne maîtrisez pas. Pris isolément, ils semblent légers ; additionnés, ils peuvent retarder l'affichage ou rendre la page lente à réagir. Gardez ceux qui ont une vraie utilité, chargez-les après le contenu principal, et remplacez une vidéo ou une carte intégrée par une image cliquable qui ne charge le lecteur qu'à la demande.

Les polices de caractères

Chaque police, et chaque graisse (normal, gras, italique…), est un fichier à télécharger. Trois familles déclinées en quatre graisses, cela fait déjà douze fichiers. Limitez-vous à une ou deux familles et aux graisses réellement employées, hébergez-les sur votre propre serveur quand c'est possible, et demandez au navigateur d'afficher le texte immédiatement avec une police de secours (règle font-display: swap).

Les Core Web Vitals, c'est quoi ?

Les Core Web Vitals, ou « Signaux Web essentiels », sont trois mesures définies par Google pour décrire ce que vit réellement un visiteur. Chacune a un seuil public à partir duquel elle est jugée bonne.

LCP : l'affichage du contenu principal

Le Largest Contentful Paint mesure le moment où le plus grand élément visible, souvent l'image d'en-tête ou le titre principal, apparaît à l'écran. Il est jugé bon lorsqu'il ne dépasse pas 2,5 secondes. Une image d'en-tête trop lourde ou un serveur qui répond lentement le dégradent directement.

INP : la réactivité aux actions

L'Interaction to Next Paint mesure le délai entre une action du visiteur (un clic, un appui sur l'écran, une frappe au clavier) et la réaction visible de la page. Il est jugé bon jusqu'à 200 millisecondes. Trop de scripts qui s'exécutent en même temps l'allongent. Cette mesure a remplacé en 2024 l'ancien indicateur FID.

CLS : la stabilité de la mise en page

Le Cumulative Layout Shift mesure les déplacements inattendus pendant le chargement : le bouton qui glisse au moment où vous alliez cliquer, le paragraphe poussé par un bandeau. Le score est jugé bon jusqu'à 0,1. Les images sans dimensions déclarées, les encarts insérés tardivement et les polices qui changent la taille du texte en sont les causes habituelles.

Google considère qu'une page atteint ces objectifs lorsque les seuils sont respectés pour au moins trois visites sur quatre (le 75e centile), en distinguant mobile et ordinateur.

Mesurer la vitesse de votre site

PageSpeed Insights

Ce service gratuit de Google analyse une adresse en quelques secondes. Il affiche deux types de résultats : les données de terrain, issues de vrais visiteurs utilisant Chrome, quand le site en reçoit suffisamment ; et un test de laboratoire, réalisé sur le moment, accompagné d'une liste de pistes d'amélioration. Testez la page d'accueil, mais aussi vos pages les plus importantes, en commençant par la version mobile.

Google Search Console

Une fois votre site déclaré dans la Search Console, le rapport « Signaux Web essentiels » classe vos pages en trois groupes (bonnes, à améliorer, médiocres) d'après les données réelles, et permet de suivre l'évolution dans le temps. Un site peu visité peut manquer de données pour y figurer : appuyez-vous alors sur les tests de PageSpeed Insights.

Un conseil : la note sur 100 du test de laboratoire varie d'un essai à l'autre et ne sert qu'à repérer des pistes. Ce sont les trois mesures ci-dessus, et l'impression d'un visiteur qui ouvre le site sur son téléphone, qui comptent vraiment.

Corriger ou refaire ?

Beaucoup de lenteurs se règlent par des corrections ciblées : compresser les images, retirer des extensions, activer le cache, passer à une version récente de PHP, différer les scripts tiers. Le gain est souvent net pour un effort raisonnable.

Quand le site repose sur un thème très lourd, sur un empilement d'extensions dont aucune ne peut être retirée sans casser quelque chose, ou sur une technologie qui n'est plus maintenue, les rustines finissent par coûter plus cher qu'une base saine. C'est le moment d'envisager une refonte qui repart sur des fondations légères. C'est d'ailleurs le parti pris des sites que je construis : un code écrit sans surcouche, et des images préparées pour le web avant leur mise en ligne.

Dans tous les cas, la vitesse s'entretient. Une nouvelle photo envoyée sans compression ou un script ajouté à la hâte suffisent à faire reculer les résultats d'un site qui était rapide.

En résumé

• Images, extensions, hébergement, scripts tiers et polices expliquent l'essentiel des lenteurs.
• Les Core Web Vitals sont bons avec un LCP jusqu'à 2,5 s, un INP jusqu'à 200 ms et un CLS jusqu'à 0,1.
• PageSpeed Insights donne un diagnostic immédiat ; la Search Console suit les visiteurs réels dans la durée.
• Des corrections ciblées suffisent souvent ; une refonte s'impose quand la base elle-même est trop lourde.

Pour que votre site reste rapide après chaque modification, un suivi technique régulier de votre site permet de repérer et de corriger les dérives avant vos visiteurs.