Core Web Vitals : quand la vitesse devient un critère de classement

En 2021, Google a officialisé les Core Web Vitals comme facteur de classement. Ce ne sont pas des métriques abstraites de laboratoire : elles mesurent l'expérience réelle des utilisateurs — combien de temps avant que la page soit lisible, si elle clignote au chargement, si elle répond rapidement aux interactions.

Bonne nouvelle : améliorer ses Core Web Vitals est souvent plus accessible qu'on ne le croit, et ses effets vont au-delà du SEO. Un site plus rapide, c'est moins d'abandons, plus de conversions, et une image plus professionnelle. C'est pour ça que la performance est au cœur de chaque site que je construis chez Tricolab.

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

Google mesure trois dimensions de l'expérience utilisateur :

• LCP — Largest Contentful Paint (rendu du plus grand élément) — mesure le temps avant que l'élément principal de la page (souvent l'image hero ou le titre) soit visible. Un bon LCP se situe sous 2,5 secondes. Au-delà de 4 secondes, c'est « mauvais » selon Google.
• INP — Interaction to Next Paint (remplace le FID depuis mars 2024) — mesure la réactivité de la page aux interactions (clic, tap, saisie). Un bon INP se situe sous 200 ms. Au-delà de 500 ms, la page semble « gelée » aux yeux de l'utilisateur.
• CLS — Cumulative Layout Shift (décalage de mise en page) — mesure si les éléments de la page bougent pendant le chargement (ce bouton qui saute juste quand on allait cliquer). Un bon CLS est inférieur à 0,1.

Les causes fréquentes de mauvais scores

La plupart des problèmes de Core Web Vitals ont des causes identifiables :

• LCP dégradé : image hero non compressée ou non préchargée, serveur lent, polices bloquantes, JavaScript volumineux qui retarde le rendu.
• INP dégradé : JavaScript trop lourd exécuté dans le thread principal, scripts tiers (chats, analytics, publicités) qui bloquent les interactions.
• CLS élevé : images sans dimensions width/height définies, polices qui swappent au chargement, bannières ou publicités qui s'insèrent après le premier rendu.

L'outil PageSpeed Insights (pagespeed.web.dev) donne un diagnostic gratuit et précis page par page, avec les corrections priorisées. C'est le point de départ de tout audit performance.

Les actions concrètes pour améliorer ses Core Web Vitals

Sans entrer dans le code, voici les leviers les plus impactants :

• Compresser et reformater les images en WebP — l'image hero est souvent le principal facteur de LCP. La passer en WebP et la précharger (rel="preload") peut faire tomber le LCP de plusieurs secondes.
• Choisir un hébergeur performant — un serveur lent plombe le TTFB (Time to First Byte) et donc le LCP. Un CDN avec mise en cache et un plan d'hébergement adapté font une différence immédiate.
• Définir les dimensions des images — width et height sur chaque <img> pour éviter les sauts de mise en page (CLS).
• Différer les scripts non critiques — les scripts tiers (analytics, chat, réseaux sociaux) doivent charger après le rendu principal, jamais avant.
• Utiliser font-display: swap — pour que les polices custom n'empêchent pas l'affichage du texte pendant leur chargement.

Performance dès la conception, pas en correctif

Le vrai problème des Core Web Vitals, c'est qu'ils sont difficiles à corriger après coup sur un site déjà en ligne. Ajouter des images lourdes, des plugins en cascade, des scripts tiers par dizaines — c'est normal dans l'évolution d'un site. Mais ça s'accumule, et les scores s'effondrent progressivement.

Ma philosophie chez Tricolab est de traiter la performance comme une contrainte de départ, pas un chantier de rattrapage : code propre, images optimisées dès le premier upload, hébergement sélectionné pour sa vitesse, scripts tiers réduits au strict nécessaire. Les sites que je construis obtiennent régulièrement des scores PageSpeed élevés dès le lancement — et ils le restent dans le temps.