La réponse directe en 30 secondes
Les Core Web Vitals sont 3 indicateurs Google qui mesurent l’expérience réelle de vos utilisateurs et impactent votre référencement :
| Indicateur | Mesure | Bon | À améliorer | Mauvais |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Temps d’affichage du plus gros élément visible | ≤ 2,5 s | 2,5 – 4 s | > 4 s |
| INP (Interaction to Next Paint) | Latence entre clic et réponse interface | ≤ 200 ms | 200 – 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Décalages visuels imprévus | ≤ 0,1 | 0,1 – 0,25 | > 0,25 |
Pour passer dans le vert en 5 jours focalisés : optimiser images (WebP/AVIF, preload), polices (font-display: swap, preload), réduire JS bloquant, réserver l’espace pour images/iframes (width/height obligatoires).
Vous voulez le détail de chaque indicateur, les leviers d’amélioration, et le plan d’action en 5 jours ? On déroule tout ci-dessous.
Pourquoi les Core Web Vitals comptent vraiment en 2026
Depuis l’update « Page Experience » de Google (déployé progressivement entre 2021 et 2024), les Core Web Vitals font partie des facteurs de classement officiels. En 2026, après plusieurs ajustements, leur poids dans l’algorithme reste modéré mais leur impact est cumulatif :
- Sur 2 sites équivalents en contenu, celui avec de meilleurs Core Web Vitals ranke mieux.
- Mauvais Core Web Vitals = baisse du temps passé, hausse du taux de rebond = signaux UX négatifs qui s’auto-renforcent.
- Sur mobile, où 70 % du trafic se concentre, ils pèsent plus que sur desktop.
3 indicateurs comptent : LCP, INP, CLS. Voici ce qu’ils mesurent et comment les optimiser.
LCP — Largest Contentful Paint
Ce que ça mesure
Le LCP mesure le temps qu’il faut pour afficher le plus gros élément visible au-dessus de la ligne de flottaison. Typiquement : l’image hero, le titre principal, le bloc d’introduction.
C’est le moment où l’utilisateur a la sensation que la page est chargée.
Seuils Google 2026
- Bon : ≤ 2,5 s
- À améliorer : entre 2,5 s et 4 s
- Mauvais : > 4 s
Sur mobile, viser moins de 2 s pour un site sérieux.
Leviers d’amélioration
1. Optimiser l’image hero (impact #1)
- Format moderne : WebP ou AVIF au lieu de JPEG.
- Taille adaptée à la résolution réelle (pas une image 3000×2000 affichée en 800×600).
<link rel="preload">sur l’image hero pour la prioriser.loading="eager"sur l’image hero (paslazy).fetchpriority="high"sur l’image hero.
2. Réduire les ressources bloquantes
- Inline le CSS critique (above-the-fold) dans le
<head>. - Différer le chargement du CSS non critique avec
mediaoupreload. - Polices :
font-display: swap+<link rel="preload" as="font" crossorigin>.
3. CDN proche des utilisateurs
Vercel, Cloudflare, Netlify Edge : déploiement géographiquement proche réduit le TTFB de 100-300 ms.
4. Côté serveur
- Cache HTTP côté serveur (Cache-Control, ETag).
- Pour pages dynamiques : SSG (Static Site Generation) ou ISR (Incremental Static Regeneration) si possible.
INP — Interaction to Next Paint
Ce que ça mesure
L’INP mesure la latence entre l’action utilisateur (clic, tap, frappe clavier) et la prochaine peinture de l’interface. Il a remplacé FID (First Input Delay) en mars 2024 comme indicateur officiel.
C’est le moment où l’utilisateur a la sensation que le site répond.
Seuils Google 2026
- Bon : ≤ 200 ms
- À améliorer : entre 200 ms et 500 ms
- Mauvais : > 500 ms
Leviers d’amélioration
1. Réduire le travail JavaScript bloquant
- Code splitting : ne charger que le JS nécessaire à la page.
- Lazy loading des composants non critiques.
- Migrer les composants lourds vers le server-side quand possible (React Server Components, Astro Islands).
2. Optimiser les handlers
- Utiliser debounce/throttle sur les inputs fréquents.
requestAnimationFramepour les animations.- Décharger les calculs lourds en Web Workers.
3. Réduire la taille du DOM
- Un DOM avec plus de 1 500 nœuds ralentit les interactions.
- Virtualiser les longues listes (react-window, virtual scroll).
- Lazy-render les composants hors viewport.
4. Limiter les third-party scripts
GA, Hotjar, Tag Manager, chatbots, ads : chaque tag ajoute du JS bloquant. Auditez et supprimez l’inutile. Chargez le reste avec defer ou async.
CLS — Cumulative Layout Shift
Ce que ça mesure
Le CLS mesure les décalages visuels imprévus pendant le chargement. Quand un utilisateur s’apprête à cliquer sur un bouton et qu’une bannière apparaît juste au-dessus, faisant glisser le bouton, c’est du CLS.
C’est l’indicateur de stabilité visuelle.
Seuils Google 2026
- Bon : ≤ 0,1
- À améliorer : entre 0,1 et 0,25
- Mauvais : > 0,25
Leviers d’amélioration
1. Réserver l’espace pour les images et iframes
- Toujours déclarer
widthetheightsur<img>et<iframe>. - Utiliser
aspect-ratioen CSS pour les conteneurs d’images responsives.
2. Polices web : éviter le FOUT/FOIT
font-display: swap(ouoptional) pour éviter le texte invisible.<link rel="preload" as="font">pour charger les polices critiques tôt.- Choisir une police de fallback proche en métriques.
3. Pas d’éléments injectés au-dessus du contenu existant
- Bannières cookies : afficher en bas, pas en haut, ou en overlay sans pousser le contenu.
- Notifications : utiliser des positions fixes hors flux.
- Annonces : réserver un slot dimensionné fixement.
4. Animations CSS plutôt que JS
- Utiliser
transformetopacity(qui n’affectent pas le layout). - Éviter les animations sur
width,height,top,leftqui causent des reflows.
Comment mesurer correctement
Outils gratuits Google
- PageSpeed Insights : score synthétique + données labo + données réelles (CrUX).
- Search Console → section « Signaux Web essentiels » : vue d’ensemble sur 28 jours pour vos vraies URLs.
- Lighthouse dans Chrome DevTools : audit local instantané.
Données réelles vs données labo
Important : PageSpeed Insights affiche 2 sections.
- Données de l’utilisateur réel (en haut) : votre vraie performance perçue par les utilisateurs sur 28 jours. C’est ce qui compte pour Google.
- Données de laboratoire (en bas) : test ponctuel synthétique. Indicatif, mais pas ce qui ranke.
Si vous n’avez pas assez de trafic, vous n’aurez que les données labo. Visez quand même les seuils.
Plan d’action en 5 jours
Jour 1 : Mesurer
PageSpeed Insights sur les 5 pages les plus visitées. Notez les 3 Core Web Vitals pour chacune. Identifiez la pire métrique sur la pire page.
Jour 2 : Optimiser images
- Convertir les images critiques en WebP/AVIF.
- Préchargement de l’image hero.
- Lazy loading sur les images sous la ligne de flottaison.
Jour 3 : Optimiser polices
- Préchargement des polices critiques.
font-display: swap.- Suppression des graisses inutilisées.
Jour 4 : Réduire JS bloquant
- Audit des scripts third-party (GTM, analytics, chatbots).
- Suppression du gras.
deferouasyncsur tout le JS non critique.
Jour 5 : Re-mesurer
PageSpeed Insights sur les mêmes 5 pages. Comparez avant/après. Identifiez les gains.
Sur la plupart des sites, 5 jours d’effort focalisé suffisent à passer dans le vert. Les sites complexes (SaaS, e-commerce) demandent davantage.
Quand un audit professionnel est nécessaire
- Vous avez fait les optimisations basiques sans gain significatif.
- Votre site est complexe (SaaS, application interactive).
- Le LCP reste > 4 s malgré vos efforts.
- Vous voulez identifier les gains à fort impact / faible effort.
Pour un audit performance ciblé Core Web Vitals, on prend 2-3 jours avec rapport priorisé. À partir de 1 200 € HT selon la complexité.
Pour discuter de votre cas et savoir si un audit est pertinent, on prend 30 minutes — sans facturer.