Vitesse d’un site et SEO : comprendre les Core Web Vitals

La question « mon site est-il assez rapide ? » n’a pas de réponse absolue. Elle a en revanche une réponse mesurable, et depuis que Google a normalisé ses indicateurs d’expérience de page, on sait exactement quoi regarder. Le problème est ailleurs : beaucoup de sites optimisent au hasard, en installant trois extensions de cache, sans avoir identifié ce qui les ralentit. Cet article remet les mesures dans l’ordre — un chantier à mener en parallèle des autres réglages techniques d’un site.

Vitesse ressentie, vitesse mesurée

Un visiteur ne chronomètre pas le chargement complet d’une page. Il perçoit trois choses : le moment où il voit enfin quelque chose d’utile, la réaction du site quand il clique, et la sensation désagréable d’un bouton qui se dérobe au dernier instant. C’est précisément ce que les trois indicateurs tentent de traduire en chiffres.

C’est aussi pourquoi les anciens repères — « poids total de la page », « temps de chargement complet » — ont perdu de leur pertinence. Une page de 2 Mo qui affiche son contenu principal en une seconde offre une meilleure expérience qu’une page de 400 Ko qui attend un script tiers avant de dessiner quoi que ce soit.

Les trois indicateurs et leurs seuils

Voici les valeurs publiées par Google pour classer une page comme « bonne », « à améliorer » ou « médiocre » :

• LCP — Largest Contentful Paint. Temps d’affichage du plus grand élément de contenu visible dans la fenêtre : image de bandeau, visuel produit, bloc de texte principal. Bon jusqu’à 2,5 secondes, à améliorer entre 2,5 et 4 secondes, médiocre au-delà de 4 secondes.
• INP — Interaction to Next Paint. Délai entre une interaction de l’utilisateur (clic, appui, touche) et le prochain rendu visible à l’écran. Bon jusqu’à 200 millisecondes, à améliorer entre 200 et 500 ms, médiocre au-delà de 500 ms.
• CLS — Cumulative Layout Shift. Score sans unité mesurant l’ampleur des déplacements inattendus d’éléments pendant la vie de la page. Bon jusqu’à 0,1, à améliorer entre 0,1 et 0,25, médiocre au-delà de 0,25.

L’INP a officiellement pris la place du FID (First Input Delay) en mars 2024. Le FID ne mesurait que le délai avant traitement de la première interaction ; l’INP observe l’ensemble des interactions et retient la plus pénalisante, ce qui reflète bien mieux le ressenti sur les interfaces riches.

Le 75^e centile : la nuance qui change tout

Un point mal compris : ces seuils ne s’appliquent pas à une visite moyenne, mais au 75^e centile des chargements observés sur une période glissante, séparément pour mobile et pour ordinateur. Autrement dit, trois quarts de vos visiteurs doivent vivre l’expérience « bonne » pour que la page soit classée ainsi.

Cela a une conséquence pratique : votre propre test, réalisé depuis une connexion en fibre sur un ordinateur récent, ne dit rien. Il faut distinguer deux natures de données :

• Les données de terrain, collectées auprès d’utilisateurs réels de Chrome ayant activé le partage de statistiques. Ce sont elles qui font foi, et elles sont rétrospectives — un correctif met plusieurs semaines à se voir.
• Les données de laboratoire, produites par un test synthétique dans des conditions simulées. Elles ne comptent pas dans l’évaluation, mais elles sont immédiates et diagnostiques : elles vous disent pourquoi c’est lent.

On corrige avec le laboratoire, on valide avec le terrain. Inverser les deux fait perdre beaucoup de temps.

Améliorer le LCP : viser le premier affichage

Le LCP dépend de quatre facteurs, dans l’ordre chronologique : le temps de réponse du serveur, le chargement des ressources bloquantes, le téléchargement de l’élément lui-même, et son rendu. Les leviers les plus rentables :

1. Réduire le temps de réponse du serveur. Cache de pages, hébergement correct, base de données allégée. Si le serveur met une seconde à répondre, aucune optimisation front ne sauvera le score.
2. Servir des images au bon format et à la bonne taille. Un visuel de 3000 pixels de large affiché dans un bloc de 800 pixels est du gaspillage pur. Les formats modernes réduisent le poids à qualité égale.
3. Ne pas différer l’élément principal. Le chargement paresseux est excellent pour ce qui se trouve sous la ligne de flottaison, et catastrophique appliqué à l’image de bandeau — celle-là doit être demandée en priorité.
4. Alléger le CSS et le JavaScript bloquants placés dans l’en-tête, qui retardent le premier rendu.

Améliorer l’INP : rendre la page réactive

L’INP est un problème de fil d’exécution occupé. Quand l’utilisateur clique, le navigateur doit interrompre ce qu’il fait pour traiter l’événement, puis redessiner. Si un script monopolise le processeur pendant 300 ms, le clic attend.

Les causes habituelles sont connues : trop de scripts tiers (widgets de chat, bandeaux publicitaires, outils de mesure), des gestionnaires d’événements qui recalculent l’ensemble de l’interface, des tâches longues jamais découpées. Les remèdes sont du même ordre : supprimer ce qui n’est pas indispensable, charger le reste après l’interaction, fractionner les traitements lourds, et donner un retour visuel immédiat même si le traitement se poursuit en arrière-plan.

C’est l’indicateur le plus exigeant sur mobile, où la puissance de calcul est bien plus limitée : un site fluide sur un ordinateur de bureau peut afficher un INP catastrophique sur un téléphone d’entrée de gamme.

Améliorer le CLS : arrêter de faire bouger la page

Le CLS est souvent le plus simple à corriger, et le plus visible pour l’utilisateur. Il vient presque toujours des mêmes sources :

• Des images sans dimensions déclarées, qui réservent zéro pixel puis poussent tout vers le bas en arrivant.
• Des blocs injectés après coup : bandeau de consentement, encart promotionnel, publicité insérée en haut de page.
• Des polices personnalisées qui remplacent brutalement une police système avec des métriques différentes.
• Des contenus dynamiques insérés au-dessus de ce que l’utilisateur est en train de lire.

La règle générale tient en une phrase : réservez l’espace avant que le contenu n’arrive. Largeur et hauteur sur les médias, conteneur de taille fixe pour les encarts, et jamais d’insertion au-dessus du contenu déjà visible.

Mesurer sans se tromper d’écran

Les évaluations sont séparées entre mobile et ordinateur, et c’est le mobile qui pose problème dans l’immense majorité des cas. Tester uniquement la version bureau donne une vision rassurante et fausse. Cette dépendance à l’appareil rejoint directement les enjeux du référencement mobile et de l’indexation mobile-first : c’est la version consultée sur téléphone qui sert de référence.

Autre précaution souvent négligée : vérifiez que les robots peuvent bien charger vos feuilles de style, vos polices et vos scripts. Une ressource interdite d’exploration dans les règles du fichier robots.txt empêche la reconstitution fidèle de la page et fausse tout diagnostic de rendu.

Quel poids réel dans le classement

Soyons honnêtes sur ce point, car les promesses abondent. Les signaux d’expérience de page font partie des critères pris en compte, mais Google a toujours présenté la pertinence du contenu comme prioritaire. Passer de 3 secondes à 2,4 secondes ne propulsera pas une page en tête si dix concurrents répondent mieux à la question posée.

En revanche, à qualité comparable, la lenteur coûte. Elle coûte d’abord en conversions et en taux de rebond, ce qui est mesurable immédiatement, bien avant tout effet SEO. C’est le meilleur argument pour investir dans la performance : le retour se voit dans les ventes avant de se voir dans les positions.

Questions fréquentes

Sources

• Google Search Central — Documentation sur l’expérience de page et les signaux associés.
• web.dev — Définitions et seuils des métriques LCP, INP et CLS.
• Google — Annonce du remplacement du FID par l’INP (mars 2024).
• Documentation du rapport « Signaux web essentiels » de Google Search Console.

Article informatif. Le SEO évolue et aucun résultat n’est garanti : privilégiez toujours des pratiques conformes aux consignes de Google.