Vitesse de chargement d’un site internet : comprendre les Core Web Vitals

La vitesse de chargement d’un site internet se mesure, chez Google, avec trois indicateurs appelés Core Web Vitals, ou Signaux Web essentiels dans la version française de ses outils. Ils mesurent le temps d’affichage du contenu principal, la rapidité de réaction de la page quand on la touche et la stabilité de la mise en page pendant le chargement. Ils sont relevés sur de vraies visites, séparément sur mobile et sur ordinateur, et les systèmes de classement de Google s’en servent.

Sur un site vitrine, les causes d’un mauvais résultat sont rarement subtiles. Une photo prise au téléphone en haut de la page d’accueil, quatre polices différentes, un widget de chat que personne n’utilise, une bannière de cookies qui fait descendre toute la page : vous pouvez corriger l’essentiel vous-même, sans développeur.

Ce guide explique ce que mesure chaque indicateur, comment tester vos pages et quoi corriger en premier selon votre plateforme. Il complète mon guide du référencement naturel pour les petites entreprises.

LCP, INP, CLS : ce que mesurent les Core Web Vitals

Les Core Web Vitals sont trois indicateurs définis par Google pour mesurer le chargement, la réactivité et la stabilité visuelle d’une page. Chacun a un seuil pour un bon résultat et un autre pour un mauvais ; entre les deux, la page doit être améliorée.

Une page atteint un seuil quand au moins 75 % des visites l’atteignent, ce que Google appelle le 75e centile, et le mobile et l’ordinateur sont évalués séparément (web.dev). Autrement dit, trois visites sur quatre doivent voir le contenu principal en 2,5 secondes au plus, obtenir une réaction à leurs appuis en un cinquième de seconde et voir la page à peine bouger sous leur pouce. Une page ne réussit l’évaluation que si les trois indicateurs sont bons.

La vitesse de chargement compte-t-elle pour le référencement ?

Oui, mais moins que le bruit qui l’entoure ne le laisse croire. La documentation de Google indique que ses systèmes de classement utilisent les Core Web Vitals, et recommande d’obtenir de bons résultats pour réussir dans la recherche. Elle précise aussi que de bons résultats dans ses rapports ne garantissent pas les premières places, et que viser un score parfait pour le seul SEO n’est peut-être pas le meilleur usage de votre temps (Google Search Central).

Une page rapide qui ne répond pas à la recherche ne se positionnera donc pas, et la page qui y répond le mieux peut se positionner tout en étant lente. La pertinence passe en premier : les mots de la page, son titre, ses intertitres et les liens qui y mènent. Ma checklist SEO on-page les reprend page par page.

La vitesse compte surtout après le clic. Quelqu’un qui cherche un plombier en urgence sur son téléphone n’attendra pas une page lente : il revient en arrière et ouvre le résultat suivant. Une page lente perd des demandes même quand elle est bien placée, et c’est pourquoi la vitesse fait partie de tout travail pour améliorer le taux de conversion d’un site internet.

Mesurer la vitesse de chargement de votre site internet avec PageSpeed Insights

PageSpeed Insights est le test gratuit de Google, sur pagespeed.web.dev. Collez l’adresse d’une page, lancez l’analyse et lisez d’abord les résultats sur mobile. Testez les pages qui comptent, pas seulement l’accueil.

En haut : ce qu’ont vécu vos vrais visiteurs

La partie haute donne l’évaluation des Core Web Vitals, réussie ou non, avec le LCP, l’INP et le CLS mesurés sur de vraies visites dans Chrome au cours des 28 derniers jours. Ce sont les données sur lesquelles Google s’appuie, et celles sur lesquelles agir.

Si la page a trop peu de visites, vous pouvez afficher les chiffres de tout le site, appelé « origine ». Si le site entier en a trop peu, cette partie reste vide. C’est courant pour une TPE et cela ne dit rien de mauvais sur votre site : servez-vous du test en laboratoire juste en dessous.

En bas : un test en laboratoire sur un téléphone simulé

En dessous, PageSpeed Insights lance Lighthouse, qui charge la page sur un téléphone de milieu de gamme simulé, avec une connexion lente, et donne un score de performances sur 100. Ce score varie de quelques points d’un test à l’autre : lancez-le deux ou trois fois avant de vous inquiéter. Le laboratoire ne peut pas mesurer l’INP, puisque personne ne touche la page pendant le test ; il affiche à la place le Total Blocking Time, qui augmente avec les mêmes scripts lourds.

Le plus utile est la liste des diagnostics sous le score. Depuis Lighthouse 13, sorti en octobre 2025, quatre d’entre eux répondent à l’essentiel des questions sur un site vitrine. Je les cite sous leur nom dans l’interface en anglais :

• LCP breakdown indique l’élément retenu comme LCP et où passe le temps. Regardez-le en premier : ce n’est pas toujours l’élément attendu, et un titre peut être le LCP à la place de la grande photo.
• Improve image delivery liste les images plus lourdes que nécessaire ou dans des formats anciens, avec le gain estimé pour chacune.
• Render blocking requests liste les feuilles de style et les scripts que le navigateur doit télécharger avant de pouvoir afficher quoi que ce soit.
• Layout shift culprits désigne les éléments qui font sauter la page.

Lire le rapport Signaux Web essentiels dans Search Console

PageSpeed Insights teste une page à la fois. Le rapport de Google Search Console couvre tout le site : ouvrez Expérience > Signaux Web essentiels, puis le rapport mobile ou ordinateur.

Il utilise les mêmes données de vraies visites que la partie haute de PageSpeed Insights et regroupe les pages semblables, par exemple tous les articles de blog construits sur le même modèle : un modèle lent apparaît comme un seul problème, pas comme cinquante. Chaque page est classée mauvaise, à améliorer ou bonne, et prend le statut de son plus mauvais indicateur.

Pour traiter un problème :

1. Cliquez dessus, par exemple un problème de LCP sur mobile, pour voir les pages concernées et une URL d’exemple.
2. Testez cet exemple dans PageSpeed Insights et corrigez la cause dans le modèle, pas page par page.
3. Cliquez sur Valider la correction. Google surveille alors le groupe pendant 28 jours au plus, car les chiffres couvrent les 28 derniers jours de visites : les visites lentes d’avant la correction y restent jusqu’à ce qu’elles sortent de la période.

Si le rapport reste vide faute de données, votre site a trop peu de visites dans Chrome pour être évalué, et le test en laboratoire devient votre repère. Mon tuto Google Search Console explique comment ajouter votre site et lire les autres rapports.

Ce qui ralentit un site vitrine, indicateur par indicateur

L’évaluation vous dit quel indicateur échoue, et chacun a ses causes habituelles.

LCP : le contenu principal s’affiche tard

INP : la page réagit tard

Les problèmes d’INP viennent le plus souvent du JavaScript : tant que le navigateur exécute un script, il ne peut pas répondre à un appui. Sur un site vitrine, beaucoup de ces scripts viennent de services tiers, ajoutés un par un au fil des années : widgets de chat, bannières de cookies, modules de réservation et d’avis, flux de réseaux sociaux, cartes et vidéos intégrées, balises de suivi accumulées dans Google Tag Manager.

Faites la liste des outils tiers du site et retirez ceux qui ne méritent plus leur place. Chargez les autres seulement là où ils servent : le module de réservation sur la page de réservation, pas sur toutes les pages. Pour les vidéos et les cartes, affichez une image qui ne charge le vrai lecteur ou la vraie carte qu’au clic. Gardez votre bannière de consentement si vos cookies en exigent une, mais choisissez-en une légère.

J’utilise Microsoft Clarity pour voir où les visiteurs s’attardent et quelles parties d’une page les font fuir. Ses clics de rage, ces clics répétés au même endroit, montrent où les gens attendaient une réaction : sur une page qui échoue à l’INP, regardez là en premier.

CLS : la page saute pendant le chargement

Les corrections selon votre plateforme : Squarespace, Wix, WordPress, site codé

Squarespace héberge le site et sert chaque image envoyée en plusieurs tailles. Vos leviers sont donc ce que vous mettez sur la page : des images plus légères dès le départ, moins de polices, une photo fixe plutôt qu’une vidéo d’arrière-plan, et le moins de code tiers possible dans l’injection de code et les blocs de code. Je propose Squarespace aux clients qui veulent modifier leur site eux-mêmes. J’ajoute souvent un peu de code à ces sites, en restant léger : un script injecté sur tout le site s’exécute sur chaque page.

Wix m’a toujours paru lent, quels que soient l’appareil, la connexion ou le pays où je l’ai utilisé. C’est mon expérience quand je crée des sites dessus ; la vitesse du site publié, côté visiteurs, est une autre question, alors mesurez-la dans PageSpeed Insights plutôt que de vous fier à mon impression. S’il échoue, les leviers sont les mêmes que sur Squarespace, plus les applications ajoutées depuis le Wix App Market, qui peuvent chacune apporter leur propre code. Mon avis sur Wix explique pourquoi j’oriente les entrepreneurs qui travaillent seuls vers d’autres outils.

WordPress donne plus de contrôle qu’un constructeur de sites, et plus de façons de ralentir un site : un thème ou un constructeur de pages lourd, des extensions qui ajoutent chacune leurs fichiers à toutes les pages, un hébergement bon marché sans cache. Les clients sous WordPress qui viennent me voir veulent en général le quitter, à cause de la prise en main et des extensions à gérer. Avec un spécialiste qui s’en occupe chaque mois, WordPress peut être rapide : moins d’extensions, la mise en cache des pages et un hébergement correct font l’essentiel du travail.

Les sites codés sur mesure et les sites statiques partent avec une longueur d’avance. Un site statique est un ensemble de pages préparées à l’avance, sans base de données à interroger à chaque visite ; ce blog est construit avec Hugo, un générateur de sites statiques, et hébergé sur GitHub Pages. Sur le site de climatisation Toshiba que j’ai créé pour Pilotech, construit avec Jekyll, le CSS est précompilé en une feuille de style finie avant la mise en ligne, et les icônes sont servies par le site lui-même plutôt que par le serveur d’une autre entreprise. Deux sources de lenteur courantes disparaissent ainsi avant même le premier test. Si vous préparez un site simple, mon tuto pour créer un site internet avec l’IA et l’héberger sur GitHub Pages part de ce type de site.

Sur un site codé, les corrections d’images et de polices ci-dessus tiennent en quelques lignes de HTML :

<!-- Grande image : taille réservée, prioritaire, jamais en différé -->
<img src="/images/hero.webp" width="1600" height="900" fetchpriority="high" alt="Technicien installant une climatisation murale">

<!-- Plus bas dans la page : taille réservée, chargement différé -->
<img src="/images/equipe.webp" width="800" height="600" loading="lazy" alt="L’équipe sur un chantier">

<!-- Dans le <head> : fichier de police principal demandé en priorité -->
<link rel="preload" href="/fonts/brand.woff2" as="font" type="font/woff2" crossorigin>

<!-- Texte affiché tout de suite dans une police de secours, remplacée par la police web à son arrivée -->
<style>
  @font-face {
    font-family: "Brand";
    src: url("/fonts/brand.woff2") format("woff2");
    font-display: swap;
  }
</style>

Avec swap, le texte s’affiche tout de suite, mais le changement de police peut le décaler un peu. Si la police figure encore dans Layout shift culprits, passez à font-display: optional : quand la police web arrive trop tard, le navigateur garde la police de secours.

Une vérification en une heure, et quand passer la main

1. Testez trois pages dans PageSpeed Insights, sur mobile : l’accueil, votre page de service principale et la page de contact. Notez l’indicateur qui échoue, dans la partie haute si vous avez des données de vraies visites, dans les résultats de laboratoire sinon.
2. Trouvez votre élément LCP dans LCP breakdown. Si c’est une image, redimensionnez-la, compressez-la et vérifiez qu’elle n’est pas en chargement différé.
3. Listez chaque widget, balise et contenu intégré du site. Retirez ce qui ne sert plus et gardez le reste sur les pages qui en ont besoin.
4. Limitez les polices à deux familles, et vérifiez que la bannière de cookies s’affiche par-dessus la page au lieu de la faire descendre.
5. Testez de nouveau, deux ou trois fois, en comparant ce qui est comparable : même page, même type d’appareil.
6. Dans Search Console, cliquez sur Valider la correction pour chaque problème traité, et revenez quatre semaines plus tard.

Passez la main quand le serveur tarde à répondre, quand l’INP échoue à cause des scripts du thème lui-même, ou quand la correction suppose de refaire des modèles de pages. Ce travail demande quelqu’un qui lit le code, et il fait partie de mon accompagnement SEO. Si le site est lent parce que sa plateforme ne correspond pas à votre façon de travailler, comparez le coût d’une refonte avec celui des rustines à payer chaque année.