為何你的網站載入緩慢，以及如何提升速度

Comment mesurer la vitesse de son site ?

Commencez par PageSpeed Insights, l'outil gratuit de Google. Il affiche deux familles de résultats, qu'il ne faut pas confondre.

Les données de terrain viennent de visiteurs réels (rapport d'expérience utilisateur de Chrome) et couvrent, selon la documentation de PageSpeed Insights consultée le 7 octobre 2026, les 28 derniers jours. Un site trop peu visité n'en a pas.
Les données de laboratoire viennent d'un test simulé avec Lighthouse, sur un appareil de milieu de gamme pour le mobile. Elles servent à repérer et à déboguer les problèmes, mais ne reflètent pas toujours la réalité de vos visiteurs.

Testez toujours la version mobile en premier : c'est elle qui est la plus exigeante.

Testez aussi comme un visiteur à faible débit : dans les outils de développement de Chrome, onglet Réseau, choisissez une limitation « 3G lente » et rechargez la page. Si elle reste inutilisable, vos visiteurs sur réseau mobile médiocre la quittent avant de la voir.

Quels sont les seuils des Core Web Vitals ?

Selon web.dev (page « Web Vitals », dernière mise à jour le 31 octobre 2024, consultée le 7 octobre 2026), trois indicateurs mesurent l'expérience, chacun évalué au 75e centile des visites, c'est-à-dire que trois visites sur quatre doivent atteindre le seuil.

LCP (Largest Contentful Paint) : le moment où le plus gros élément visible s'affiche. Bon : 2,5 secondes ou moins. À améliorer : de 2,5 à 4 secondes. Mauvais : plus de 4 secondes.
INP (Interaction to Next Paint) : le délai entre un clic ou une frappe et la réaction visible de la page. Bon : 200 millisecondes ou moins. À améliorer : de 200 à 500 millisecondes. Mauvais : plus de 500 millisecondes.
CLS (Cumulative Layout Shift) : l'instabilité visuelle, quand un bouton se déplace au moment où vous allez cliquer. Bon : 0,1 ou moins. À améliorer : de 0,1 à 0,25. Mauvais : plus de 0,25.

Le score sur 100 de Lighthouse est un résumé pratique, mais ce sont ces trois seuils qui comptent pour le référencement.

Quelles sont les causes les plus fréquentes d'un site lent ?

Dans l'ordre où il est le plus rentable de les vérifier :

Des images trop lourdes ou mal chargées : photos non compressées, format inadapté, dimensions bien supérieures à l'affichage.
Un serveur lent à répondre : hébergement saturé, pas de cache, pages générées à chaque visite.
Des extensions et des scripts tiers en excès : modules WordPress empilés, widgets de chat, pixels publicitaires, outils de statistiques multiples.
Des polices web mal chargées : trop de graisses et de familles, texte invisible pendant le chargement.
Du code qui bloque l'affichage : feuilles de style et JavaScript volumineux chargés avant le contenu.

Le rapport PageSpeed Insights indique, sous « Opportunités » et « Diagnostics », laquelle de ces causes pèse le plus sur votre page. Commencez par celle qui gagne le plus de temps. Si votre trafic baisse pour une autre raison, voir l'impact des AI Overviews de Google sur le trafic.

Comment corriger chaque cause ?

Les images

Compressez et passez en WebP ou AVIF, avec des dimensions proches de l'affichage réel.
Chargez en différé (loading="lazy") les images situées sous la première fenêtre visible.
Ne différez jamais l'image principale du haut de page : web.dev (page « Optimize LCP », mise à jour le 31 mars 2025, consultée le 7 octobre 2026) déconseille de mettre loading="lazy" sur l'élément du LCP et recommande fetchpriority="high" sur l'image qui le porte.
Indiquez largeur et hauteur de chaque image : la page réserve la place et le CLS reste bas.

Le serveur et le cache

Activez le cache du navigateur et un cache de pages pour ne pas régénérer chaque visite.
Vérifiez la durée de réponse du serveur : la même page web.dev répartit un budget de LCP d'environ 40 % pour la réponse du serveur, 40 % pour le téléchargement de la ressource, et moins de 10 % chacun pour le délai de découverte et le délai d'affichage. Un serveur lent consomme donc une grosse part du budget avant même que l'image ne commence à arriver.

Les extensions et scripts tiers

Listez tout ce qui se charge, puis supprimez ce qui ne sert pas à vos objectifs.
Chargez les scripts restants en différé (defer) et retirez les doublons d'outils de mesure.
Sur WordPress, remplacez un module lourd par quelques lignes de code quand c'est possible.

Les polices

Limitez-vous à une famille et deux graisses.
Hébergez les polices sur votre domaine et utilisez font-display: swap pour que le texte reste lisible pendant le chargement.

Le code bloquant

Minifiez le CSS et le JavaScript.
Chargez en priorité le style de la partie visible, le reste ensuite.
Découpez les longues tâches JavaScript : elles dégradent l'INP.

Que change un hébergement ou un CDN ?

Un hébergement plus rapide agit sur la première part du LCP, le temps de réponse du serveur. Il ne rattrape pas des images de plusieurs mégaoctets ni vingt scripts tiers : si ces causes existent, un meilleur serveur donne un gain limité.

Un CDN (réseau de diffusion de contenu) copie vos fichiers sur des serveurs répartis dans plusieurs régions. Il rapproche l'image du visiteur et sert aussi à optimiser les images à la volée, ce que web.dev cite parmi ses recommandations pour le LCP. Il est surtout utile quand vos visiteurs sont loin du serveur d'origine, par exemple une audience au Bénin avec un hébergement en Europe ou en Amérique du Nord.

Ordre raisonnable : alléger la page d'abord, ajouter le cache ensuite, puis le CDN, et changer d'hébergeur en dernier si le temps de réponse reste mauvais.

Quel effet la vitesse a-t-elle sur le référencement et les ventes ?

Pour le référencement, la documentation Google Search Central sur l'expérience de page (consultée le 7 octobre 2026) indique que Google cherche toujours à montrer le contenu le plus pertinent, même si l'expérience de page est médiocre ; mais, quand beaucoup de contenus utiles existent sur une requête, une bonne expérience de page peut peser sur le classement. Sa page sur les Core Web Vitals précise que ces mesures, avec les autres aspects de l'expérience de page, correspondent à ce que ses systèmes de classement principaux cherchent à récompenser, et recommande de viser de bons scores. Un site rapide ne remplace donc pas un contenu pertinent. Pour les autres blocages techniques, voir les erreurs de référencement les plus coûteuses.

Pour les ventes, l'étude « Milliseconds Make Millions », réalisée par Deloitte pour Google et publiée le 24 mars 2020, a analysé pendant quatre semaines les données mobiles de marques européennes et américaines du commerce, du voyage, du luxe et de la génération de contacts. Un gain de 0,1 seconde sur mobile s'est accompagné de 8,4 % de conversions en plus et de 9,2 % de panier moyen en plus dans le commerce, et de 10,1 % de conversions en plus dans le voyage. Le périmètre est limité et ancien, et l'étude établit une corrélation avec la progression dans l'entonnoir de vente, non une causalité prouvée : ne transposez pas ces pourcentages tels quels à votre boutique.

Quand faut-il refaire le site plutôt que l'optimiser ?

Les retouches suffisent quand le problème vient des images, du cache ou de quelques scripts. Une refonte devient plus rentable dans ces cas :

Le LCP reste au-dessus de 4 secondes après avoir allégé les images et activé le cache.
Le site repose sur un thème ou un constructeur qui charge des centaines de kilooctets de code inutilisé, impossible à retirer.
Chaque correction casse autre chose, faute de code maintenable.
La structure ne permet plus d'ajouter une fonction sans ralentir tout le reste.

Si vous hésitez, une refonte ou migration de site repart d'une base propre en conservant vos adresses et votre référencement. Une fois le site rapide, la maintenance et le support évitent qu'il redevienne lent, extension après extension.

Questions fréquentes

Quelle vitesse viser pour un site ?

Un LCP de 2,5 secondes ou moins, un INP de 200 millisecondes ou moins et un CLS de 0,1 ou moins, pour au moins 75 % des visites, en priorité sur mobile (web.dev, consulté le 7 octobre 2026).

Mon score Lighthouse est bon mais PageSpeed signale « échec » : pourquoi ?

Le score vient du test simulé, alors que l'évaluation des Core Web Vitals vient des visiteurs réels sur 28 jours. Un test simulé sur une bonne connexion peut être bon pendant que de vrais visiteurs, sur mobile, vivent autre chose.

Changer d'hébergeur suffit-il ?

Cela réduit le temps de réponse du serveur, soit environ 40 % du budget de LCP selon web.dev. Si les images et les scripts restent lourds, le site restera lent.

Faut-il tester sur ordinateur ou sur mobile ?

Sur les deux, mais commencez par le mobile : l'ordinateur masque souvent des problèmes qui apparaissent sur un téléphone de milieu de gamme.

Le chargement différé des images est-il toujours bon ?

Non. Il convient aux images situées sous la première fenêtre visible, mais il retarde l'image principale du haut de page et dégrade le LCP.

Combien de temps faut-il pour voir l'effet d'une correction ?

Le test de laboratoire réagit tout de suite. Les données de terrain de PageSpeed Insights se calculent sur 28 jours : l'amélioration apparaît progressivement.

Dois-je supprimer Google Analytics ou mes pixels publicitaires ?

Pas forcément. Gardez ceux dont vous vous servez, retirez les doublons, chargez-les en différé et vérifiez dans PageSpeed Insights combien de temps chacun ajoute.

Sources

web.dev, Web Vitals, consultée le 7 octobre 2026
web.dev, Optimize Largest Contentful Paint, consultée le 7 octobre 2026
Documentation de PageSpeed Insights, About, consultée le 7 octobre 2026
Google Search Central, Core Web Vitals et Google Search, consultée le 7 octobre 2026
Google Search Central, Expérience de page, consultée le 7 octobre 2026
Deloitte, Milliseconds Make Millions, consultée le 7 octobre 2026

Cet article a d'abord été publié sur richardsalanon.com.