Core Web Vitals
#Définition Core Web Vitals
Core Web Vitals : ensemble de trois métriques d'expérience utilisateur définies par Google en 2020, intégrées comme facteur de classement en juin 2021. Mesurées sur données terrain réelles (field data) via CrUX (Chrome User Experience Report, percentile 75). Pour approfondir, consultez la page service Development Next.js Nehos.
D'un point de vue métier, (1) LCP — Largest Contentful Paint : temps jusqu'au rendu du plus grand élément de contenu visible dans le viewport. Seuils : good <2,5 s / needs improvement 2,5-4 s / poor >4 s. Principaux leviers d'optimisation : lazy loading images avec fetchpriority="high" sur l'image LCP, preconnect CDN, Server Components Next.js pour réduire le JavaScript bloquant, ISR (Incremental Static Regeneration).
(2) INP — Interaction to Next Paint : temps entre une interaction utilisateur (clic, tap, frappe) et le prochain frame visuel peint. Remplace le FID depuis mars 2024. Seuils : good <200 ms / needs improvement 200-500 ms / poor >500 ms. Leviers : réduction des Long Tasks JS (>50 ms), code splitting, deferment des scripts tiers, React Concurrent features.
(3) CLS — Cumulative Layout Shift : somme des scores de déplacement de mise en page inattendus pendant la durée de vie de la page. Seuils : good <0,1 / needs improvement 0,1-0,25 / poor >0,25. Leviers : réserver les dimensions d'images et iframes via attributs width/height, éviter l'injection dynamique de contenu au-dessus du contenu existant.
Outils de mesure : Lighthouse (lab data), PageSpeed Insights (lab + field data), Chrome DevTools, GSC rapport Expérience de la page, CrUX Dashboard (Data Studio).
Maîtriser Core Web Vitals permet aux équipes techniques et métier de parler le même langage — et d'arbitrer plus vite.
#Core Web Vitals expliqué simplement
Imagine que tu arrives sur un site web. Est-ce qu'il charge vite ? Est-ce qu'il répond immédiatement quand tu cliques ? Est-ce que les boutons restent bien à leur place ou est-ce qu'ils sautent au moment où tu essaies de cliquer dessus ? Core Web Vitals, c'est la façon dont Google mesure ces trois choses en conditions réelles sur des millions d'utilisateurs Chrome.
Ce n'est pas un test de labo artificiel — c'est basé sur ce que vivent vraiment les gens qui visitent ton site. Le LCP vérifie que le contenu principal s'affiche vite. L'INP vérifie que le site répond quand on interagit. Le CLS vérifie que la page ne bouge pas de façon imprévue.
Si tu rates ces trois métriques, Google considère que ton site offre une mauvaise expérience — et ça peut coûter des positions dans les résultats de recherche, surtout sur mobile où les performances sont souvent moins bonnes que sur desktop.
Prenez un cas concret : une entreprise de 50 personnes qui accélère sa croissance. La différence entre théorie et terrain ? Les chiffres. Et les chiffres, on les a.
#Cas d'usage concrets
Exemple de situation : DNVB cosmétique — migration de Shopify Liquid vers Shopify Hydrogen et Next.js — Exemple de situation : une DNVB dont les pages Shopify Liquid affichent un LCP lent, un INP au niveau « needs improvement » et un CLS élevé migre vers Shopify Hydrogen, Next.js App Router et une infrastructure edge.
On mesure les trois métriques avant et après, ainsi que la conversion mobile. Le travail sur les Core Web Vitals n'est pas une fin en soi : c'est la conséquence d'une architecture frontend moderne.
Exemple de situation : site d'agence B2B — optimisation de l'INP sur des pages de service interactives — Exemple de situation : les pages de service d'une agence, avec formulaires et animations JavaScript lourdes, ont un INP élevé. Diagnostic : plusieurs scripts tiers (chat, analytics, A/B testing, retargeting) injectés dans le main thread.
Intervention : chargement des scripts tiers après la première interaction, code splitting React avec React.lazy(), réduction des Long Tasks. On suit l'INP et la position Google sur les mots-clés de service.
Exemple de situation : e-commerce B2B en refonte Next.js 16 — CLS sur fiches produits dynamiques — Exemple de situation : sur des fiches produits e-commerce B2B, le CLS est mauvais car les badges de disponibilité et les prix remisés sont injectés de façon asynchrone au-dessus du bouton d'ajout au panier. Correction : skeleton screens avec dimensions réservées, et Server Components pour le prix et le stock. On suit le CLS et le taux d'ajout au panier mobile.
#Core Web Vitals chez Nehos Groupe
Chez Nehos, on part du terrain. Notre service Development Next.js Nehos couvre ce périmètre de A à Z.
La méthode Nehos est documentée sur Méthode Performance Web Stack Nehos™. Chaque mission démarre par un cadrage structuré : objectifs chiffrés, périmètre technique, jalons à 30/60/90 jours. On livre, on mesure, on itère. Pas de slides sans livrable. Voir aussi : refonte Magento vers architecture headless.
#Termes associés
Comprendre ce terme implique de maîtriser son écosystème.
- INP (Interaction to Next Paint)
- Hreflang
- Crawl Budget
- Schema Markup
- Next.js
- Server Components React
- Featured Snippet
Explorez chaque définition pour construire une vision complète du sujet.
Applications Concrètes
« Exemple de situation : une DNVB dont les pages Shopify Liquid affichent un LCP lent, un INP au niveau « needs improvement » et un CLS élevé migre vers Shopify Hydrogen, Next.js App Router et une infrastructure edge. On mesure les trois métriques avant et après, ainsi que la conversion mobile. Le travail sur les Core Web Vitals n'est pas une fin en soi : c'est la conséquence d'une architecture frontend moderne. »
« Exemple de situation : les pages de service d'une agence, avec formulaires et animations JavaScript lourdes, ont un INP élevé. Diagnostic : plusieurs scripts tiers (chat, analytics, A/B testing, retargeting) injectés dans le main thread. Intervention : chargement des scripts tiers après la première interaction, code splitting React avec React.lazy(), réduction des Long Tasks. On suit l'INP et la position Google sur les mots-clés de service. »
« Exemple de situation : sur des fiches produits e-commerce B2B, le CLS est mauvais car les badges de disponibilité et les prix remisés sont injectés de façon asynchrone au-dessus du bouton d'ajout au panier. Correction : skeleton screens avec dimensions réservées, et Server Components pour le prix et le stock. On suit le CLS et le taux d'ajout au panier mobile. »
Questions & réponses
Questions fréquentes sur Core Web Vitals
Lab data (données de laboratoire) : mesures effectuées par Lighthouse ou PageSpeed Insights sur un appareil simulé dans des conditions contrôlées. Utile pour le diagnostic et le débogage — reproductible à la demande. Field data (données terrain) : mesures collectées sur de vrais utilisateurs Chrome visitant votre site, agrégées dans CrUX (Chrome User Experience Report). C'est sur ces données terrain que Google base ses signaux de classement. Un bon score Lighthouse en lab ne garantit pas un bon score CrUX en field data — les conditions réseau, les appareils réels et les comportements utilisateurs peuvent différer significativement.
Oui, officiellement. Google a retiré FID (First Input Delay) du set Core Web Vitals en mars 2024 et l'a remplacé par INP (Interaction to Next Paint). La raison : FID ne mesurait que la latence de la première interaction, ignorant toutes les interactions suivantes. INP mesure la latence de toutes les interactions pendant la durée de vie de la page, en ne retenant que la plus lente (ou la 98e percentile sur les pages avec de nombreuses interactions). INP est donc bien plus représentatif de la réactivité globale d'une page, notamment pour les applications web complexes (SPA, e-commerce avec filtres interactifs).
Impact réel mais relatif. Google est explicite : la pertinence du contenu reste le signal dominant. Core Web Vitals intervient comme facteur de départage entre pages de pertinence similaire — c'est le 'tiebreaker'. En pratique, sur des requêtes très compétitives avec des contenus similaires entre les premiers résultats, un avantage Core Web Vitals peut faire la différence entre la position 3 et la position 1. Sur des requêtes moins compétitives avec un contenu nettement supérieur, un site avec des Core Web Vitals 'needs improvement' peut tout à fait se positionner en top 3. Ce n'est pas un facteur binaire on/off.
Cinq leviers par ordre d'impact décroissant. (1) Identifier l'élément LCP (Lighthouse ou Chrome DevTools) — souvent une image héro ou un titre H1. (2) Ajouter fetchpriority='high' et supprimer le lazy loading sur l'image LCP. (3) Précharger les ressources critiques avec <link rel='preload'>. (4) Utiliser un CDN avec edge network (Netlify, Vercel, Cloudflare) pour réduire le TTFB. (5) Passer à React Server Components + streaming SSR pour éliminer le JavaScript bloquant côté client. Combinées sur un projet Next.js 16, ces cinq mesures aident à viser un LCP sous 2,5 s sur mobile.
Oui, directement. Un CLS élevé (>0,1) produit des 'fat finger clicks' : l'utilisateur clique sur le bouton d'achat juste au moment où un élément se charge et déplace ce bouton. Résultat : clic sur un élément non voulu, frustration, abandon. C'est particulièrement problématique sur mobile où les zones de clic sont réduites. Corriger le CLS sur les fiches produits se mesure directement sur le taux d'ajout au panier mobile. L'impact CLS est donc à la fois un signal SEO et une métrique UX/conversion directe.
Oui. Google collecte et évalue séparément les Core Web Vitals desktop et mobile dans CrUX et GSC. Les seuils cibles (LCP <2,5 s, INP <200 ms, CLS <0,1) s'appliquent aux deux. En pratique, les scores mobiles sont presque toujours moins bons que les scores desktop — réseau plus lent, CPU moins puissant, viewport réduit. Google indexe en mobile-first, ce sont donc les scores mobiles qui priment dans l'évaluation Page Experience. L'erreur classique : optimiser uniquement en lab sur desktop avec Lighthouse, en ignorant le terrain mobile.
Quatre outils complémentaires. (1) GSC rapport Expérience de la page : vue d'ensemble des URL 'Good', 'Needs improvement', 'Poor' sur field data CrUX — idéal pour identifier les pages à prioriser. (2) CrUX Dashboard (Looker Studio) : suivi des tendances historiques sur 6 mois, comparaison desktop vs mobile. (3) PageSpeed Insights : diagnostic ponctuel lab + field data sur URL spécifique. (4) Sentry ou Grafana avec web-vitals.js intégré : monitoring temps réel en production sur 100 % du trafic réel, avec alerting sur dégradation. La combinaison GSC + web-vitals.js + l'analytics de l'hébergeur couvre bien un projet Next.js en production.