Core Web Vitals : indicateurs, seuils et priorités d’optimisation

Core Web Vitals : seuils, identification des goulots d’étranglement et priorités d’optimisation pour un site B2B

Core Web Vitals : indicateurs, seuils et priorités d’optimisation

Conclusion d’abord : Core Web Vitals est la note d’expérience de page de Google. Les trois indicateurs clés ont pour seuils LCP ≤ 2,5 s, INP ≤ 200 ms et CLS ≤ 0,1, évalués au 75e percentile. Sur un site B2B, 80 % des problèmes de performance se concentrent à trois endroits : la grande image du premier écran non compressée, les scripts de chat et de CRM tiers qui bloquent le thread principal, et les images sans ratio qui provoquent des décalages de mise en page. L’ordre d’optimisation est LCP avant INP avant CLS : d’abord les images, ensuite les scripts, enfin la mise en page. Côté données, ne vous fiez qu’aux 28 jours de données terrain de Search Console, pas aux scores de laboratoire de Lighthouse.

1. Ce que mesurent réellement les trois indicateurs

Core Web Vitals n’est pas une note, mais un ensemble de trois indicateurs d’expérience indépendants. Comprendre ce que mesure chacun permet de savoir quoi corriger.

Indicateur	Nom complet	Ce qui est mesuré	Seuil de qualification	À améliorer
LCP	Largest Contentful Paint	Temps de rendu du plus grand élément du premier écran	≤ 2,5 s	2,5 à 4 s
INP	Interaction to Next Paint	Délai entre l’interaction de l’utilisateur et le rendu de l’image suivante	≤ 200 ms	200 à 500 ms
CLS	Cumulative Layout Shift	Score cumulé des décalages de mise en page imprévus	≤ 0,1	0,1 à 0,25
TTVC	Dérivé du Time to First Contentful Paint	Temps de rendu du premier contenu utile	≤ 1,8 s	1,8 à 3 s

Deux points essentiels. Premièrement, le 75e percentile : pour juger si votre page est bonne, Google regarde la performance de 75 % de vos utilisateurs réels sur cet indicateur, pas la moyenne ni les utilisateurs les plus rapides. Deuxièmement, l’INP a officiellement remplacé le FID en mars 2024 : le délai d’interaction est donc devenu un indicateur clé, ce qui pèse le plus sur les sites B2B équipés d’une multitude de chats en ligne, d’automatisations marketing et de fenêtres de chat, car ces scripts sont la principale cause de blocage du thread principal.

L’optimisation des performances n’est pas un travail isolé : elle et Gouvernance des actifs médias sont les deux faces d’une même pièce. Si les images ne sont pas maîtrisées, le LCP ne baissera jamais ; si les scripts ne sont pas maîtrisés, l’INP ne sera jamais conforme. Pour savoir comment mettre en place un système de surveillance interne, voir Checklist de surveillance et d’alerte du site.

2. Sources de données : ce que regarde chaque outil

Beaucoup d’équipes optimisent avec les mauvaises données et constatent au bout d’une semaine qu’aucun indicateur n’a bougé, parce qu’elles regardent des valeurs de laboratoire.

Outil	Type de données	Échantillonnage	Cas d’usage	Limites
PageSpeed Insights	Laboratoire + terrain	Test ponctuel + 28 jours de CrUX	Diagnostic rapide d’une page	Écart entre les valeurs de laboratoire et les utilisateurs réels
CrUX	Données terrain	Remontées anonymes des utilisateurs Chrome	Voir la distribution réelle	Échantillon insuffisant sur les petits sites
Search Console	Synthèse des données terrain	Fenêtre glissante de 28 jours	Voir les tendances par template	Pas d’analyse page par page
Lighthouse CI	Données de laboratoire	Tests en local	Non-régression avant déploiement	Ne reflète pas les utilisateurs réels en ligne
Web Vitals .js	Collecte terrain personnalisée	Vos propres utilisateurs	Compléter l’échantillon des petits sites	Nécessite du développement

Règle pratique : utilisez le rapport Core Web Vitals de Search Console pour identifier le template qui pose problème, PageSpeed Insights pour analyser une page et trouver le goulot d’étranglement, et Lighthouse CI pour tester la non-régression à chaque mise en production. Ne faites pas l’inverse : prendre un score de laboratoire pour une performance en ligne est l’illusion la plus courante en optimisation de performance.

3. Optimiser le LCP : la grande image du premier écran, ennemi numéro un

Sur un site B2B, 80 % des problèmes de LCP viennent de l’image hero et du carrousel du premier écran.

Goulot	Symptôme typique	Action	Gain attendu
Image principale non compressée	Image hero en PNG de plus de 500 Ko	Convertir en WebP/AVIF, qualité 80, srcset multi-tailles	LCP réduit de 0,5 à 1,5 seconde
Image principale non préchargée	Le navigateur découvre l’image hero trop tard	Ajouter un preload dans le head vers l’image principale	LCP réduit de 0,2 à 0,5 seconde
Police bloquant le rendu	Chargement tardif de la police personnalisée, écran blanc	font-display: swap, ne charger que les graisses nécessaires	LCP réduit de 0,3 à 0,8 seconde
Réponse serveur lente	TTFB supérieur à 1,8 seconde	Passer au CDN, activer HTTP/2, cache PHP	LCP réduit de 0,4 à 1 seconde
Scripts tiers retardant le premier rendu	Scripts de tracking dans le head qui bloquent	defer ou chargement différé après idle	LCP réduit de 0,2 à 0,6 seconde

Un point négligé : les sites B2B prennent souvent une vue d’ensemble de l’usine ou une grande photo produit comme image hero, et cette image est fréquemment un original photographique de plus de 2 Mo. La compresser sous 200 Ko, la passer en WebP et ajouter un preload : ces trois actions suffisent généralement à diviser le LCP par deux. Quand le serveur est en Chine et les clients en Europe ou aux États-Unis, le TTFB est naturellement élevé : le CDN est indispensable.

4. Optimiser l’INP : les scripts tiers sont les principaux coupables

Depuis que l’INP a remplacé le FID, les sites B2B sont souvent à la traîne, car ils accumulent les scripts marketing et de support client.

Type de script	Sources courantes	Impact sur l’INP	Mesure à prendre
Support client en ligne	Intercom, Zendesk, Tawk	Tâches longues sur le thread principal de 200 à 800 ms	Charger 3 secondes après le premier écran, ou au scroll en bas de page
Automatisation marketing	HubSpot, Marketo, Pardot	Formulaires et pop-ups bloquant les interactions	Charger uniquement sur les pages cibles, retirer ailleurs
Heatmaps et analytics	Hotjar, FullStory	Les scripts d’enregistrement occupent le thread principal en continu	Échantillonner 10 % des utilisateurs, pas d’enregistrement total
Pop-up de chat	WhatsApp, fenêtre flottante WeCom	Délai au clic sur le pop-up	Utiliser un bouton natif, charger le script après le clic
Carrousel personnalisé	Carrousel produit de la page d’accueil	Tâches longues du JS de lecture automatique	Passer à un carrousel CSS, arrêter la lecture automatique

Pour identifier le goulot d’étranglement, enregistrez une interaction de page avec le panneau Performance de Chrome DevTools et repérez les tâches longues violettes sur le thread Main : traitez d’abord celle qui prend le plus de temps. Principe : tout script non essentiel au premier écran doit être chargé après le premier scroll de l’utilisateur ou après 5 secondes d’idle. Restez sobre dans le choix des extensions, voir Quatre extensions pour un site à l’international : plus vous en installez, plus l’INP est difficile à valider.

5. Optimiser le CLS : donner une taille à tous les médias

Le CLS est l’indicateur le plus simple à corriger, mais aussi le plus souvent négligé.

Source du décalage	Raison	Correctif	CLS après correction
Image sans dimensions	balise img sans width/height	ajouter les attributs width/height ou aspect-ratio	proche de 0
Emplacement publicitaire sous-dimensionné	le chargement asynchrone de la pub étire la page	hauteur minimale prédéfinie sur le conteneur	baisse de 0,05 à 0,15
Changement de police	FOIT/FOUT provoque un reflow	font-display: swap, réserver la taille de la police de repli	baisse de 0,02 à 0,08
Contenu inséré dynamiquement	insertion après les recommandations et les articles liés	hauteur réservée sur le conteneur de remplacement	baisse de 0,05 à 0,1
Image en lazy loading chargée trop tard	une image en loading=lazy arrive tard et pousse le contenu du dessous	image de remplacement ou aspect-ratio	baisse de 0,03 à 0,07

Une règle absolue : toute balise img, video ou iframe de la page doit porter les attributs width et height dans le HTML, et le CSS doit utiliser aspect-ratio pour rester responsive. Aucun planning de développement n’est nécessaire : une modification du template profite à tout le site. Accessibilité et performance vont de pair sur la réservation des dimensions, voir Périmètre d’accessibilité d’un site B2B.

6. Priorités d’optimisation et rythme des itérations

Phase	Délai	Objectif	Action	Objectif de validation
Semaine 1	Diagnostic	Identifier les templates à problème	extraire 28 jours de données dans Search Console et lister les 10 pages les plus mauvaises	Liste des templates à problème
Semaine 2	Attaque sur le LCP	LCP sous 2,5 s sur tous les templates	compression des images + preload + optimisation des polices	Répartition du LCP dans PSI
Semaine 3	Attaque sur l’INP	Réduire les scripts tiers	chargement différé, enregistrement par échantillonnage, suppression des scripts inutiles	nombre de tâches longues divisé par 2
Semaine 4	Finitions sur le CLS	CLS inférieur à 0,1 sur tout le site	attributs width/height, conteneurs de remplacement	aucune page en erreur CLS dans GSC
En continu	Suivi	Pas de régression à chaque mise en production	exécuter Lighthouse CI à chaque déploiement	score au moins égal à la version précédente

La maintenance d’un site a son propre rythme, et la performance n’en est qu’un volet, voir Les six tâches de maintenance mensuelles. Après une refonte ou une migration, les performances régressent facilement : à traiter en même temps que Migration 301 et préservation du SEO.

FAQ — Questions fréquentes

Lighthouse affiche plus de 90, mais Search Console signale un échec : pourquoi ?

Parce que Lighthouse mesure des données de laboratoire, sur une seule passe dans un environnement propre ; Search Console utilise 28 jours de données réelles de terrain, avec de la 4G faible, de vieux téléphones et de vrais scripts tiers. Les deux échantillons n’ont rien à voir. La bonne approche : Search Console comme juge, PSI comme outil de diagnostic. Si GSC signale un template en échec, lancez PSI sur une page de ce template pour trouver le goulot d’étranglement, sans chercher le score Lighthouse parfait.

Le trafic d’un site B2B est faible, que faire si l’échantillon CrUX est insuffisant ?

Pour un petit site, mesurez vous-même vos Core Web Vitals avec Web Vitals.js et collectez vos propres données utilisateurs réelles. Le code de mesure fait environ 1 Ko : ajoutez un snippet dans le head de la page et envoyez les trois métriques LCP, INP et CLS vers votre propre entrepôt de données. Ainsi, même si CrUX ne dispose pas de vos données, vous avez votre propre distribution terrain. Attention : ne collectez que les valeurs des métriques, aucune donnée personnelle, pour rester conforme au RGPD. Voir RGPD et conformité des données cookies.

Faut-il vraiment un carrousel en haut de page ?

Côté performance, mieux vaut supprimer le carrousel automatique. Les deuxième et troisième visuels ne sont jamais vus par l’utilisateur, mais il faut quand même les télécharger, les parser et exécuter le JS du carrousel : c’est une double charge pour le LCP et l’INP. Remplacez-le par une seule image hero avec un CTA, ou par un défilement manuel en CSS. Si le métier impose un carrousel, passez les visuels à partir du deuxième en loading=lazy et veillez à ce que le JS du carrousel ne bloque pas le premier écran.

Faut-il supprimer le widget de chat pour optimiser l’INP ?

Non, il faut le différer. Les scripts de chat comme Intercom ou Zendesk ont de la valeur pour la conversion des demandes B2B, mais ils ne doivent pas s’exécuter au chargement du premier écran. La méthode : attendre 3 secondes après le chargement du premier écran, ou injecter le script après le premier scroll de 20 % de la fenêtre. Vous gardez ainsi le contact client sans bloquer la première interaction. Même logique pour la fenêtre WhatsApp : utilisez un bouton natif et ne chargez le SDK web qu’au clic.

Mon CLS tourne autour de 0,15, comment le faire passer sous 0,1 ?

Repérez les éléments qui se déplacent dans le panneau Layout Shift des DevTools. Les trois causes les plus fréquentes sur un site B2B : des images sans width/height ; des blocs d’articles liés ou de recommandations insérés en JS asynchrone sans espace réservé ; un texte qui se réagence après le chargement de la police. Une fois ces trois points corrigés, le CLS passe généralement sous 0,05. Concrètement : ajoutez largeur et hauteur à toutes les balises img, définissez un aspect-ratio sur tous les conteneurs asynchrones, et utilisez font-display: swap avec une police de repli système aux dimensions proches.

Quels problèmes de performance un CDN peut-il régler ?

Un CDN règle surtout le TTFB et la distribution des ressources statiques : sa contribution au LCP se situe entre 0,3 et 1 seconde, et il n’apporte quasiment rien à l’INP ni au CLS. Si votre serveur est en Chine et vos clients en Europe ou aux États-Unis, le TTFB peut dépasser 2 secondes : passer au CDN est alors la priorité absolue. Si le TTFB est déjà sous 600 ms, le gain d’un CDN reste limité : mieux vaut investir dans les images et les scripts. La version gratuite de Cloudflare suffit pour un petit site ; pour un site d’entreprise, préférez Cloudflare Pro ou AWS CloudFront.

Pour conclure

Les Core Web Vitals ne sont pas l’affaire de la seule équipe technique : c’est un indicateur partagé par le contenu, le design et le marketing. La taille des images revient au contenu, le chargement des scripts au marketing, les décalages de mise en page au design. Réunissez ces trois personnes autour du même tableau et laissez chacune corriger dans l’ordre LCP, INP, CLS pendant deux semaines : passer au vert sur tout le site en un trimestre est réalisable.

Trois étapes concrètes : cette semaine, listez les 10 modèles les plus lents depuis Search Console ; la semaine suivante, compressez l’image hero et ajoutez un preload ; la troisième semaine, passez tous les scripts du service client et du marketing en chargement différé. Une fois ces trois étapes faites, regardez à nouveau GSC : le taux d’échec baisse généralement de plus de moitié.

Une phrase à retenir : l’argent de l’optimisation des performances doit profiter aux vrais utilisateurs. Analyser les données de terrain, alléger la grande image du premier écran et différer les scripts tiers compte dix fois plus qu’un score parfait.