Site lent : mesurer et améliorer la vitesse de son site (Core Web Vitals)

La vitesse d’un site internet se mesure aujourd’hui avec trois indicateurs définis par Google, les Core Web Vitals : le temps d’affichage du contenu principal (LCP), la réactivité aux clics (INP) et la stabilité de la page pendant le chargement (CLS). Les mesurer est gratuit et prend quelques minutes ; les améliorer passe le plus souvent par des images mieux préparées, moins de scripts et une mise en page qui réserve la place de chaque élément. Voici comment lire ces indicateurs, avec quels outils, et quoi corriger en priorité.

Les trois indicateurs, en clair

Le guide Web Vitals de web.dev, publié par Google sur son site web.dev, décrit trois aspects de l’expérience : le chargement, l’interactivité et la stabilité visuelle.

LCP (Largest Contentful Paint) : le chargement. C’est le temps nécessaire pour afficher le plus grand élément visible à l’écran, souvent la grande photo d’en-tête ou le titre principal. D’après la page de web.dev consacrée au LCP, il peut s’agir d’une image, de l’image d’aperçu ou de la première image d’une vidéo, d’une image de fond chargée en CSS ou d’un bloc de texte.

INP (Interaction to Next Paint) : la réactivité. L’INP observe le délai de réaction de la page à tous les clics, appuis et saisies au clavier pendant la visite. Un menu qui met du temps à s’ouvrir ou un bouton qui semble ne pas répondre dégradent l’INP. Selon la page de web.dev sur l’INP, cet indicateur a succédé au FID (First Input Delay).

CLS (Cumulative Layout Shift) : la stabilité. Le CLS mesure les décalages inattendus de la mise en page. L’exemple classique : vous allez appuyer sur un lien, une image finit de se charger au-dessus, le texte descend et vous appuyez à côté.

Les seuils fixés par Google

Pour chaque indicateur, web.dev définit un seuil « bon » et un seuil « médiocre » :

Indicateur	Bon	Médiocre
LCP	2,5 secondes ou moins	plus de 4 secondes
INP	200 millisecondes ou moins	plus de 500 millisecondes
CLS	0,1 ou moins	plus de 0,25

Entre les deux, la page est considérée comme « à améliorer ».

Un détail compte : ces seuils s’apprécient au 75e centile des visites, séparément sur mobile et sur ordinateur. Autrement dit, il ne suffit pas que la page soit rapide sur votre ordinateur au bureau ; il faut qu’au moins trois visites sur quatre restent sous le seuil, y compris sur des téléphones moins puissants ou une connexion moyenne.

La vitesse et le référencement : ce que dit Google

La documentation de Google Search Central sur les Core Web Vitals recommande vivement aux propriétaires de sites d’obtenir de bons scores, et précise que cela va dans le sens de ce que ses principaux systèmes de classement cherchent à récompenser.

Il faut cependant garder les proportions. La page de Google sur l’expérience sur la page indique que de bons scores ne garantissent pas que vos pages s’afficheront en haut des résultats, et que la recherche s’efforce de toujours afficher le contenu le plus pertinent, même si l’expérience sur la page est décevante.

En pratique : un site rapide mais vide de contenu utile ne sera pas bien classé, et un contenu excellent ne sera pas effacé par un LCP moyen. La vitesse sert surtout vos visiteurs : un site qui s’affiche vite et ne bouge pas sous le doigt inspire confiance. C’est l’un des fondements d’un bon référencement naturel, parmi d’autres.

Mesurer : deux outils gratuits

PageSpeed Insights, pour une page

PageSpeed Insights analyse une adresse précise et rend deux types de résultats :

• Les données terrain, issues du rapport d’expérience utilisateur Chrome (CrUX), sur les 28 derniers jours : c’est l’expérience réelle de vos visiteurs. Si la page n’a pas assez de données, l’outil affiche celles de l’ensemble du site ; un site peu fréquenté peut ne pas en avoir du tout.
• Les données de laboratoire, produites par Lighthouse dans un environnement simulé : utiles pour diagnostiquer et tester une correction tout de suite.

L’outil affiche les résultats sur mobile et sur ordinateur. Commencez par les résultats mobile : c’est souvent là que les problèmes apparaissent.

La Search Console, pour tout le site

Le rapport Core Web Vitals de la Search Console s’appuie sur des données d’utilisation réelles. Il regroupe les adresses qui offrent une expérience similaire et leur attribue un état : « Bon », « Amélioration nécessaire » ou « Médiocre », séparément pour le mobile et l’ordinateur. L’état d’un groupe correspond à son indicateur le plus mauvais. Une fois un problème corrigé, cliquez sur « Démarrer le suivi » pour faire valider la correction : Google surveille alors les adresses concernées pendant 28 jours.

Si vous n’avez pas encore de Search Console, c’est l’occasion de la configurer : elle sert bien au-delà de la vitesse.

Les causes les plus fréquentes, et les corrections

Un LCP trop long

La méthode d’optimisation du LCP de web.dev recommande notamment :

• Servir des images à la bonne taille, avec des images adaptées à l’écran (images responsives). Une photo de 4 000 pixels de large affichée sur un téléphone fait télécharger beaucoup de données inutiles.
• Compresser les images et utiliser des formats modernes comme AVIF ou WebP.
• Ne jamais différer le chargement de l’image principale (le lazy loading convient aux images plus bas dans la page, pas à celle d’en-tête), et lui donner une priorité élevée avec l’attribut fetchpriority="high".
• Rendre l’image principale visible dans le code HTML initial, pour que le navigateur la repère tôt.
• Limiter les redirections et rapprocher le serveur des visiteurs, par exemple avec un réseau de diffusion de contenu (CDN).

Un CLS élevé

D’après la page d’optimisation du CLS de web.dev :

• Toujours indiquer la largeur et la hauteur (width et height) des images et des vidéos, ou réserver leur place en CSS avec aspect-ratio.
• Réserver l’espace des éléments qui arrivent après coup : bannière, encart publicitaire, widget de réservation.
• Maîtriser les polices web : les précharger, et limiter l’écart de taille avec la police de secours.
• Éviter d’animer des propriétés qui déplacent la mise en page, comme top ou left.

Un INP médiocre

L’INP se dégrade quand le navigateur est occupé à exécuter du JavaScript au moment où l’internaute clique. La page d’optimisation de l’INP de web.dev conseille de découper les tâches longues pour rendre la main au navigateur, d’alléger le travail exécuté à chaque clic, et signale qu’une page très lourde en éléments HTML rend chaque mise à jour plus coûteuse. Sur un site vitrine, la cause vient souvent de scripts empilés au fil des années : extensions, outils de suivi, widgets. Faire l’inventaire de ce qui est vraiment utilisé est un bon point de départ.

Un exemple concret

Prenons le site d’un restaurant de Juan-les-Pins. Sur mobile, PageSpeed Insights signale un LCP médiocre et un CLS à améliorer. L’analyse montre une photo de terrasse de plusieurs mégaoctets en en-tête, chargée en différé par une extension, et un bandeau de réservation qui apparaît après coup et pousse le contenu vers le bas.

Les corrections suivent directement les recommandations ci-dessus : la photo est redimensionnée, convertie en WebP ou AVIF, chargée en priorité ; le bandeau reçoit un emplacement réservé dès l’affichage. Après mise en ligne, on vérifie d’abord avec les données de laboratoire, puis on suit les données terrain, qui se mettent à jour progressivement puisqu’elles portent sur 28 jours.

Prévenir plutôt que corriger

La vitesse se décide largement au moment de la création : choix de la technologie, poids des modèles, nombre d’extensions. Notre comparatif WordPress, Webflow ou sur mesure aborde ce point, et notre article sur la refonte du site de Webest Riviera montre les mesures obtenues sur un site statique.

Elle se maintient ensuite dans la durée : chaque nouvelle image, chaque nouvel outil ajouté peut la dégrader. C’est l’un des rôles d’une maintenance de site suivie, et un critère que nous intégrons dès la création de site internet.

Votre site vous semble lent, ou ses résultats dans PageSpeed Insights vous interrogent ? Contactez-nous : nous regarderons ensemble ce qui le freine.