Core Web Vitals (LCP, CLS, INP) : les métriques Google qui impactent votre SEO

Le LCP mesure le temps nécessaire pour afficher le plus grand élément visible de la page, généralement une image hero ou un bloc de texte principal. C'est la perception de vitesse : quand le LCP est rapide, l'utilisateur sent que la page "charge vite", même si d'autres éléments continuent de charger.

Les seuils sont les suivants : moins de 2,5 secondes est bon (vert), entre 2,5 et 4 secondes nécessite une amélioration (orange), plus de 4 secondes est mauvais (rouge).

Les causes fréquentes d'un mauvais LCP incluent les images hero non optimisées (trop lourdes, mauvais format), un serveur lent à répondre (TTFB élevé), du CSS ou JavaScript bloquant le rendu, des polices web lentes à charger, et trop de redirections.

Comment améliorer le LCP ? Pour les images, utilisez des formats modernes (WebP, AVIF), dimensionnez correctement (pas d'image 4000px pour un affichage 800px), ajoutez l'attribut loading="eager" sur l'image LCP, et utilisez un CDN. Pour le serveur, passez à un hébergement plus rapide, activez la compression (gzip, brotli), utilisez un CDN pour le HTML, et cachez agressivement les ressources statiques. Pour éliminer les ressources bloquantes, différez le JavaScript non critique (defer, async), inlinéz le CSS critique, et préchargez les ressources importantes (<link rel="preload">).

Le CLS mesure la stabilité visuelle, c'est-à-dire combien la page "saute" pendant le chargement. Ces décalages inattendus frustrent les utilisateurs : vous cliquez sur un bouton, et hop, une pub apparaît et vous cliquez dessus par erreur. Un CLS élevé crée une expérience désagréable et les utilisateurs perdent confiance.

Les seuils sont : moins de 0,1 est bon, entre 0,1 et 0,25 nécessite une amélioration, plus de 0,25 est mauvais.

Les causes fréquentes incluent les images sans dimensions spécifiées, les publicités/embeds qui s'insèrent après coup, les polices web qui changent la taille du texte, le contenu injecté dynamiquement en haut de page, et les animations qui déplacent du contenu.

Comment améliorer le CLS ? Réservez l'espace des images en spécifiant toujours les dimensions :

\\\html

<!-- Mauvais : pas de dimensions -->

<img src="photo.jpg" alt="Photo">

<!-- Bon : dimensions explicites -->

<img src="photo.jpg" alt="Photo" width="800" height="600">

<!-- Mieux : ratio aspect -->

<img src="photo.jpg" alt="Photo" style="aspect-ratio: 4/3">

\\\

Définissez des conteneurs de taille fixe pour les pubs et embeds qui chargent après coup. Gérez les polices avec font-display: swap ou optional pour éliminer le décalage. Ne jamais injecter de contenu au-dessus du viewport : le contenu ajouté dynamiquement doit toujours apparaître en dessous de ce que l'utilisateur regarde.

L'INP mesure la réactivité. Quand l'utilisateur clique, tape ou touche, combien de temps avant que la page réagisse visuellement ? L'INP a remplacé le FID (First Input Delay) en 2024 et mesure l'ensemble des interactions, pas seulement la première. Un site qui "lag" frustre les utilisateurs.

Les seuils sont : moins de 200ms est bon, entre 200ms et 500ms nécessite une amélioration, plus de 500ms est mauvais.

Les causes fréquentes incluent le JavaScript bloquant le thread principal, les écouteurs d'événements lourds, trop de work pendant les interactions, l'hydration lente des frameworks JavaScript, et les third-party scripts abusifs.

Comment améliorer l'INP ? Divisez les tâches longues :

\\\javascript

// Mauvais : tâche bloquante de 500ms

function traitementLourd() {

// ... traitement long

}

// Mieux : découpage en chunks

async function traitementLourd() {

for (const item of items) {

await processItem(item);

// Laisse le navigateur respirer

await new Promise(r => setTimeout(r, 0));

}

}

\\\

Les gestionnaires de clics doivent être légers. Déplacez le travail lourd dans des Web Workers ou différez-le. Réduisez le JavaScript en éliminant le code mort, différant les scripts non critiques, utilisant le tree-shaking, et lazy-loadant les modules lourds. Attention aux third-party : scripts de chat, analytics, pubs, pixels de tracking... chacun ajoute du JavaScript. Auditez régulièrement et supprimez les inutiles.

Les données terrain (CrUX, Search Console) reflètent l'expérience réelle et sont celles que Google utilise pour le classement. Les données laboratoire (Lighthouse) sont utiles pour diagnostiquer et tester des améliorations, mais peuvent différer de la réalité.