Les Core Web Vitals sont les trois indicateurs par lesquels Google mesure l’expérience réelle de vos visiteurs : la vitesse d’affichage du contenu principal (LCP), la réactivité aux interactions (INP) et la stabilité de la mise en page (CLS). Une page les réussit lorsque 75 % des visites atteignent les seuils recommandés, mesurés sur de vrais utilisateurs de Chrome. Chez SEORank, nous les optimisons gabarit par gabarit, en commençant par les pages qui génèrent vos ventes et vos demandes de devis, et nos développeurs appliquent eux-mêmes les correctifs.
Notre position est volontairement nuancée : les Core Web Vitals ne feront pas passer une page médiocre devant une page pertinente. Mais sur des requêtes disputées, ils départagent des concurrents proches, et un site qui répond vite convertit mieux. C’est cette double logique, référencement et conversion, qui guide nos priorités.
Les trois indicateurs et leurs seuils
Les seuils ci-dessous sont ceux publiés par Google sur web.dev et dans sa documentation Search Central. Ils s’appliquent au 75e centile des chargements, séparément sur mobile et sur ordinateur.
| Indicateur | Ce qu’il mesure | Bon | À améliorer | Mauvais | Causes fréquentes |
|---|---|---|---|---|---|
| LCP · Largest Contentful Paint | Temps d’affichage du plus grand élément visible (image, bloc de texte) | ≤ 2,5 s | 2,5 à 4 s | > 4 s | Serveur lent, image principale découverte tard ou trop lourde, CSS bloquant |
| INP · Interaction to Next Paint | Délai entre un clic, un appui ou une touche et l’affichage de la réponse | ≤ 200 ms | 200 à 500 ms | > 500 ms | JavaScript lourd, scripts tiers, DOM très volumineux |
| CLS · Cumulative Layout Shift | Ampleur des décalages inattendus de la mise en page | ≤ 0,1 | 0,1 à 0,25 | > 0,25 | Images sans dimensions, bandeaux injectés, polices web, publicités |
Un rappel utile : depuis le 12 mars 2024, l’INP a remplacé le FID. Le FID ne mesurait que l’attente avant la première interaction ; l’INP prend en compte les clics, les appuis et les frappes au clavier pendant toute la visite. Nombre de sites bien notés auparavant ont découvert à ce moment un problème de réactivité. Nous détaillons cet indicateur dans notre guide de l’INP.
Quel poids dans le classement Google ?
Google formule les choses avec prudence. Il indique que de bons Core Web Vitals, combinés aux autres aspects de l’expérience sur la page, correspondent à ce que ses systèmes de classement cherchent à récompenser. Mais sa page sur l’expérience sur la page précise aussi que la recherche affiche toujours le contenu le plus pertinent, même quand l’expérience est décevante. Conclusion pratique :
- si vos pages ne répondent pas à l’intention de recherche, commencez par le contenu et l’audit SEO ;
- si vous êtes au coude à coude avec des concurrents de pertinence équivalente, les Core Web Vitals deviennent un levier crédible ;
- dans tous les cas, une page qui s’affiche vite et ne saute pas sous le doigt perd moins de visiteurs avant l’action.
Données terrain et données de laboratoire : ne pas confondre
La confusion la plus fréquente chez nos clients vient de PageSpeed Insights, qui affiche deux blocs aux logiques opposées. La documentation de l’outil explique que les données terrain couvrent les 28 jours précédents, tandis que le laboratoire simule un seul chargement. Les données terrain viennent du Chrome UX Report (CrUX), l’ensemble de données officiel du programme Web Vitals.
| Données terrain (CrUX) | Données de laboratoire (Lighthouse) | |
|---|---|---|
| Source | Visites réelles d’utilisateurs de Chrome | Un chargement simulé sur un appareil et un réseau fixés |
| Période | 28 jours glissants | Instantané, à la demande |
| Où les voir | PageSpeed Insights (partie haute), rapport Core Web Vitals de la Search Console | PageSpeed Insights (partie basse), Chrome DevTools |
| INP disponible | Oui | Non : le laboratoire n’interagit pas, il utilise un indicateur de substitution (Total Blocking Time) |
| Usage | Évaluer : c’est ce que Google prend en compte | Diagnostiquer et tester une correction avant mise en ligne |
| Limite | Nécessite assez de trafic pour qu’une page ou une origine ait des données | Ne reflète pas la diversité des téléphones et des réseaux de vos visiteurs |
Conséquence : un score Lighthouse qui passe de 45 à 90 ne signifie pas que vos Core Web Vitals sont validés. Seules les données terrain le diront, environ quatre semaines après la mise en production.
Améliorer le LCP : trouver la sous-partie qui coûte
Le LCP se décompose en quatre sous-parties, décrites dans le guide d’optimisation du LCP : le temps de réponse du serveur (TTFB), le délai avant le début du chargement de la ressource principale, la durée de ce chargement, puis le délai de rendu de l’élément. Optimiser au hasard fait perdre du temps ; nous mesurons d’abord laquelle domine.
- Serveur lent : cache des pages HTML, hébergement dimensionné, CDN pour les visiteurs éloignés.
- Image principale découverte tard : présente dans le HTML initial, attribut
fetchpriority="high", et jamais de chargement différé sur cette image. - Image trop lourde : formats modernes, dimensions adaptées à l’écran grâce à
srcset. - Rendu bloqué : CSS critique en ligne, feuilles de style secondaires et scripts non essentiels différés.
Réduire l’INP : libérer le fil principal
Une interaction se découpe en trois phases : le délai d’entrée (le navigateur est occupé ailleurs), la durée de traitement (votre code réagit) et le délai de présentation (le navigateur redessine). Le guide d’optimisation de l’INP recommande de céder régulièrement la main au fil principal et de limiter la taille du DOM. Sur les sites que nous auditons, trois causes reviennent : des scripts tiers (chat, avis, suivi publicitaire) qui s’exécutent au mauvais moment, des gestionnaires d’événements qui recalculent toute la page, et des menus ou filtres construits avec des milliers de nœuds. Nous découpons les tâches longues, différons ce qui n’est pas visible et chargeons les widgets seulement à la première interaction.
Stabiliser le CLS : réserver la place
Le CLS mesure les décalages inattendus : le bouton qui descend au moment où l’on appuie, le texte qui saute quand une police se charge. Le guide d’optimisation du CLS cite comme causes principales les images et iframes sans dimensions, le contenu injecté dynamiquement, les polices web et certaines animations. Les correctifs sont souvent simples : attributs width et height ou aspect-ratio sur les médias, espace réservé pour les encarts, polices de secours aux métriques proches, animations limitées aux propriétés qui ne déplacent pas la mise en page.
La spécificité française : bandeaux de consentement et outils de mesure
En France, le RGPD et les règles de la CNIL imposent de recueillir le consentement avant de déposer la plupart des traceurs. Le bandeau de consentement est donc présent sur presque tous les sites, et il pèse sur les trois indicateurs. Google le reconnaît dans ses bonnes pratiques pour les bannières de cookies : ces bandeaux sont une source très courante de décalages de mise en page, et l’acceptation déclenche souvent le chargement simultané de nombreux scripts tiers, ce qui dégrade l’INP. Sur mobile, le bandeau peut même devenir l’élément LCP.
- afficher le bandeau en superposition plutôt qu’en l’insérant en haut de page ;
- charger le script de la plateforme de consentement de façon asynchrone et établir la connexion tôt ;
- étaler dans le temps le chargement des outils autorisés après acceptation, au lieu de tout lancer d’un coup ;
- vérifier que le texte du bandeau n’est pas plus grand que votre contenu principal sur un petit écran.
Ces réglages ne changent rien à la conformité : le consentement reste recueilli de la même façon, seul le moment du chargement technique évolue.
Les correctifs selon votre plateforme
| Plateforme | Coupables habituels | Correctifs que nous appliquons |
|---|---|---|
| WordPress / WooCommerce | Constructeurs de pages, extensions qui chargent leurs scripts partout, sliders en tête de page | Chargement conditionnel des scripts, remplacement du slider par une image fixe, cache serveur et CDN |
| PrestaShop | Modules de filtres et de réassurance lourds, images produits non redimensionnées, hooks multiples | Audit des modules par page, formats d’image adaptés, report des modules non visibles |
| Shopify | Applications qui injectent du JavaScript sur toutes les pages, polices du thème, avis clients chargés en haut | Tri des applications, chargement différé des widgets, préchargement ciblé |
| Site sur mesure (Laravel, Symfony, JS) | Temps de réponse du serveur, hydratation JavaScript coûteuse, bundles volumineux | Mise en cache HTML, découpage du code, rendu serveur des gabarits clés |
Les problèmes structurels (serveur, architecture, rendu JavaScript) relèvent aussi de notre prestation de SEO technique. Pour les spécificités de chaque plateforme, consultez nos pages SEO WordPress, SEO PrestaShop et SEO Shopify.
Notre méthode d’optimisation des Core Web Vitals
Lecture des données terrain
Rapport Core Web Vitals de la Search Console et CrUX : quels groupes d’URL échouent, sur mobile ou ordinateur, et sur quel indicateur.
Choix des gabarits rentables
Nous croisons avec le chiffre d’affaires : une fiche produit ou une page service passe avant les mentions légales.
Diagnostic en laboratoire
Chrome DevTools et Lighthouse sur les gabarits retenus, avec un profil mobile réaliste, pour isoler la sous-partie du LCP ou la phase de l’INP en cause.
Correctifs en préproduction
Nos développeurs corrigent le code du thème, des modules ou du serveur, puis nous comparons avant et après sur le même protocole.
Mise en production et mesure réelle
Nous installons si besoin une mesure terrain (bibliothèque web-vitals) pour suivre l’effet dès les premiers jours, sans attendre 28 jours.
Garde-fou
Un seuil d’alerte par gabarit pour repérer la prochaine application ou le prochain script qui dégradera les résultats.
Prix et délais
Le diagnostic des Core Web Vitals fait partie de notre audit SEO complet, qui démarre dès 690 € HT. Les correctifs sont ensuite chiffrés au temps de développement réel, gabarit par gabarit, dans un devis séparé : remplacer un slider par une image fixe n’a pas le même coût que réécrire le JavaScript d’un configurateur. Dans nos formules mensuelles, à partir de 490 € HT par mois, les corrections techniques prioritaires sont incluses. Tous nos prix sont publiés sur la page tarifs.
Pour les délais, retenez deux horloges : le temps de correction (de quelques heures à quelques semaines selon le chantier) et le temps de mesure (28 jours glissants pour que les données terrain reflètent entièrement la correction). Vous verrez l’évolution dans votre reporting SEO mensuel.
Erreurs fréquentes
- Viser 100/100 sur Lighthouse au lieu de faire passer les gabarits rentables dans la zone « bonne » en données terrain.
- Tester uniquement sur ordinateur alors que Google évalue mobile et ordinateur séparément et que l’essentiel du trafic est souvent mobile.
- Charger en différé l’image principale pour « alléger » la page : c’est l’inverse de ce qu’il faut pour le LCP.
- Ajouter une extension d’optimisation de plus qui minifie, regroupe et diffère tout, au risque de casser les interactions.
- Oublier les scripts tiers : chat, avis, cartes, vidéos et pixels publicitaires pèsent souvent plus que votre propre code.
Nos limites, en toute transparence
Nous ne promettons pas de gain de positions lié aux seuls Core Web Vitals, parce que Google ne le promet pas non plus. Certaines contraintes ne dépendent pas de nous : un script imposé par une régie publicitaire, une plateforme SaaS qui ne donne pas accès au code, un hébergement que vous ne souhaitez pas changer. Dans ces cas, nous chiffrons l’effet de chaque contrainte pour vous permettre d’arbitrer. Et nous refusons de désactiver le bandeau de consentement ou de contourner les règles de la CNIL pour gagner quelques millisecondes.
Si le rapport Core Web Vitals de votre Search Console affiche des URL « mauvaises » sur mobile, envoyez-nous l’adresse de votre site : nous vous indiquons sous 24 heures ouvrées quels gabarits corriger en premier et ce que cela représente.