Cette checklist couvre les 3 métriques officielles des Core Web Vitals (LCP, CLS, INP), leurs seuils Google, et 30+ actions concrètes hiérarchisées par impact. Chaque bloc indique l'outil de mesure, le gain typique constaté en production et le piège classique à éviter.
Les Core Web Vitals sont les trois métriques officielles que Google utilise depuis le déploiement du Page Experience Update en juin 2021 pour évaluer la qualité de l'expérience utilisateur d'une page web. Elles ne sont pas un facteur de classement mineur : Google les a confirmées comme signaux de ranking à part entière, intégrés au cœur de l'algorithme de pertinence. Depuis mars 2024, le FID a été remplacé par l'INP (Interaction to Next Paint), une métrique plus complète et plus exigeante qui évalue la réactivité globale d'une page tout au long de la session utilisateur.
D'après notre étude de 1 000 sites de PME françaises, seuls 11 % d'entre eux respectent simultanément les trois seuils verts sur mobile. C'est le facteur technique le plus négligé du SEO français — alors qu'une optimisation rigoureuse coûte rarement plus de quelques jours d'expertise et apporte un gain de visibilité mesurable en 4 à 8 semaines. Cette checklist détaille, pour chaque métrique, la définition rigoureuse, les seuils, les actions correctives par ordre de rentabilité et les outils gratuits pour tout vérifier vous-même.
Vous n'avez pas le temps d'auditer vos Core Web Vitals ? Nos experts vous remettent un diagnostic complet en 48h.
Demander un audit performance gratuitComprendre les 3 métriques actuelles des Core Web Vitals
FiabiliteAvant de plonger dans les corrections, il est essentiel de bien distinguer les trois métriques, leurs unités et leur méthode de mesure. Beaucoup d'agences confondent encore données de laboratoire (Lighthouse) et données de terrain (CrUX), ce qui aboutit à des optimisations efficaces sur le papier mais inutiles pour le ranking réel.
- LCP (Largest Contentful Paint) — temps en secondes nécessaire à l'affichage du plus grand élément visible dans la fenêtre. Bon : moins de 2,5s. À améliorer : 2,5 à 4s. Mauvais : au-delà de 4s. C'est la métrique la plus visible côté utilisateur : elle traduit la sensation de lenteur au chargement.
- CLS (Cumulative Layout Shift) — score sans unité mesurant la stabilité visuelle pendant la session. Bon : moins de 0,1. À améliorer : 0,1 à 0,25. Mauvais : au-delà de 0,25. Un CLS élevé correspond à ces situations frustrantes où l'utilisateur clique sur un bouton qui se déplace au dernier moment.
- INP (Interaction to Next Paint) — temps en millisecondes entre l'interaction utilisateur (clic, touche, tap) et le prochain rendu visuel. Bon : moins de 200ms. À améliorer : 200 à 500ms. Mauvais : au-delà de 500ms. Remplace officiellement le FID depuis le 12 mars 2024.
Ces trois métriques se mesurent de deux façons radicalement différentes. Les données de laboratoire (Lighthouse, PageSpeed Insights mode laboratoire, WebPageTest) simulent une visite dans un environnement contrôlé : utiles pour reproduire un problème et tester une optimisation, mais elles ne reflètent pas l'expérience réelle de vos visiteurs. Les données de terrain (Chrome User Experience Report, dit CrUX) agrègent les mesures collectées chez des millions d'utilisateurs Chrome réels sur une fenêtre glissante de 28 jours. Ce sont uniquement les données CrUX que Google utilise pour son ranking — pas Lighthouse.
Conséquence pratique : un site peut afficher 95/100 sur Lighthouse et être en zone rouge dans la Search Console, parce que les visiteurs réels utilisent des connexions 4G médiocres et des smartphones d'entrée de gamme. La règle d'or : optimisez en laboratoire pour valider vos hypothèses, mais pilotez vos décisions à partir des données CrUX (rapport Core Web Vitals dans Search Console).
💎 Nos engagements
Une optimisation technique sans compromis
La performance technique est le socle de tout bon référencement. Voici les piliers de notre approche.
Crawl & indexation
Analyse de la façon dont Google explore et indexe votre site. Correction des erreurs de crawl, optimisation du budget de crawl et configuration du robots.txt et sitemap XML.
Performance & Core Web Vitals
Optimisation du LCP, FID et CLS pour atteindre les seuils recommandés par Google. Compression des images, lazy loading, minification du code et mise en cache avancée.
Architecture & maillage
Restructuration du maillage interne pour distribuer efficacement le PageRank. Création de silos thématiques et optimisation de la profondeur des pages stratégiques.
Balisage & données structurées
Implémentation de Schema.org (FAQ, Article, LocalBusiness, Product) pour enrichir vos résultats dans les SERP et améliorer votre taux de clic organique.
Monitoring continu
Surveillance en temps réel des erreurs d'indexation, des temps de chargement et des Core Web Vitals via Google Search Console et des outils spécialisés.
Impact mesurable
Chaque correction technique se traduit par une amélioration concrète : meilleur score PageSpeed, pages indexées plus rapidement, positions qui progressent.
📈 Résultats concrets
Les étapes d'une optimisation technique réussie
Un site techniquement solide est la base de tout bon référencement. Voici notre méthodologie étape par étape.
Semaine 1–2
Audit & diagnostic
Analyse technique complète, recherche de mots-clés stratégiques, benchmark concurrentiel et plan d'action priorisé.
Feuille de route claire
Mois 1–3
Optimisation technique
Correction des erreurs d'indexation, optimisation des balises et de la vitesse, amélioration du maillage interne.
Site techniquement sain
Mois 3–6
Contenu & montée en positions
Contenus SEO ciblés, netlinking qualitatif, premiers gains visibles sur les mots-clés secondaires puis principaux.
+20 à +40 % de trafic
Mois 6–12+
Dominance & croissance
Positions solides sur vos requêtes principales, trafic qualifié régulier et croissant, ROI SEO mesurable mois par mois.
+60 % de trafic moyen
Évolution type des performances techniques
+45% en 12 mois
Montée en puissance
Résultats stabilisés
JanFévMarAvrMaiJuinJuilAoûtSepOctNovDéc
Ces chiffres représentent la moyenne observée sur nos clients après 12 mois d'accompagnement SEO. Les résultats varient selon votre secteur et votre concurrence.
Bloc LCP — Optimiser le Largest Contentful Paint
ConseilsLe LCP est la métrique la plus fréquemment échouée parmi les sites PME français. Dans 80 % des cas, l'élément LCP est l'image hero de la page d'accueil ou un bloc de titre H1 dans la moitié supérieure. Voici la checklist d'optimisation par ordre d'impact décroissant :
- 1Préchargez l'image LCP avec rel="preload" — Action : ajoutez
<link rel="preload" as="image" href="...">dans le<head>pour l'image hero. Outil de vérification : Chrome DevTools (onglet Network, voir si la ressource démarre dès le 1er round-trip). Gain typique : -300 à -800ms sur le LCP. - 2Ajoutez l'attribut fetchpriority="high" sur l'image LCP — Cet attribut introduit en 2023 indique au navigateur de prioriser le téléchargement par rapport aux autres ressources concurrentes. Combiné avec preload, c'est l'optimisation la plus rentable. Gain typique : -150 à -400ms.
- 3Servez vos images en AVIF ou WebP avec dimensions explicites — Le format AVIF est 50 % plus léger que JPEG, WebP est 25-34 % plus léger. Toujours déclarer width et height pour éviter le CLS induit. Outil : Squoosh, cwebp en CLI, plugin Cloudflare Polish.
- 4Servez les assets via un CDN proche de l'utilisateur — Pour un site français, un CDN avec PoP en Europe (Cloudflare, Bunny CDN, Fastly) divise par 2 à 5 le temps de transfert. Gain typique : -100 à -500ms selon la qualité de votre hébergement initial.
- 5Supprimez le CSS render-blocking — Inlinez le CSS critique (above-the-fold) directement dans le
<head>et différez le reste avecmedia="print"ourel="preload". Outil : Critical (npm), PurgeCSS pour éliminer le CSS mort. Gain typique : -200 à -600ms. - 6Activez font-display: swap sur toutes les @font-face — Sans cette directive, le texte reste invisible pendant le téléchargement de la police personnalisée, ce qui dégrade le LCP si l'élément LCP est un titre. Préchargez aussi les fichiers .woff2 critiques.
- 7Réduisez le TTFB serveur sous 600ms — Si vous tournez sur un mutualisé bas de gamme, un TTFB de 1,5 à 3s est courant et plombe tout le reste. Solutions : passer en SSG (Next.js, Astro), activer le cache full-page (WP Rocket, LiteSpeed Cache), migrer vers un VPS ou un hébergement managé. Gain typique : -500ms à -2s.
- 8Évitez le lazy loading sur l'image LCP — Erreur fréquente : appliquer
loading="lazy"en masse sur toutes les images, y compris la hero. Le navigateur diffère alors le téléchargement, dégradant fortement le LCP. Réservez le lazy loading aux images sous la ligne de flottaison.
Bloc CLS — Éliminer les layout shifts
ExpertiseLe CLS est paradoxalement la métrique la plus simple à corriger une fois identifiée, mais aussi celle qui revient en boucle après chaque ajout de fonctionnalité (bandeau cookies, widget chat, intégration vidéo, bannière promo). Voici la checklist pour passer durablement sous 0,1.
- 1Déclarez width et height sur toutes les images, iframes et vidéos — Le navigateur réserve ainsi l'espace dès l'analyse HTML, sans attendre le chargement de l'asset. Pour les images responsives, utilisez le ratio aspect :
width="800" height="450"reste lu correctement même avecstyle="width:100%; height:auto". Outil : PageSpeed Insights pointe précisément les éléments coupables. - 2Réservez de l'espace pour les publicités, widgets et embeds — Un slot Google Ads sans dimensions fixes provoque un CLS énorme à l'injection. Définissez explicitement
min-heighten CSS pour chaque conteneur d'annonce, de chat, de Trustpilot, etc. - 3Utilisez font-display: optional ou swap, et préchargez vos fonts — Le passage de la font système à la font personnalisée (FOIT/FOUT) est une cause majeure de CLS. Le préchargement des .woff2 critiques + size-adjust dans @font-face limite le décalage métrique entre fallback et font finale.
- 4Privilégiez transform et opacity pour les animations — Évitez d'animer top, left, width, height ou margin : ces propriétés déclenchent un layout. Utilisez
transform: translate()etopacityqui restent au niveau composite, sans CLS. - 5Bannissez les contenus injectés dynamiquement au-dessus de la ligne de flottaison — Bandeau cookie qui apparaît 800ms après le chargement, notification promo en haut de page, message de bienvenue : tout contenu poussant le reste vers le bas après le rendu initial cumule du CLS. Affichez-les en overlay (fixed/sticky) ou dans des slots pré-réservés.
- 6Servez les images responsives avec srcset et sizes corrects — Un mauvais sizes provoque parfois un re-rendu post-chargement avec une autre image qui a un ratio légèrement différent, ce qui produit un micro-CLS difficile à diagnostiquer.
Bloc INP — Améliorer la réactivité aux interactions
PerformanceL'INP est la métrique la plus difficile à optimiser car elle dépend du JavaScript exécuté en réponse aux clics et touches utilisateur. Une INP dégradée traduit presque toujours un thread principal saturé par des bundles JS trop volumineux ou des handlers événementiels mal écrits. Checklist par ordre de rentabilité :
- 1Réduisez la taille du bundle JavaScript principal sous 170 Ko gzippés — Mesurez avec
webpack-bundle-analyzerousource-map-explorer. Tracez les dépendances inutiles (Moment.js → date-fns, lodash full → lodash-es ciblé, jQuery si vous utilisez React/Vue). Gain typique : -100 à -300ms d'INP. - 2Pratiquez le code splitting par route — Ne chargez sur la page d'accueil que le code nécessaire à la page d'accueil. Next.js, Remix et Astro le font automatiquement. Sur React + Vite, utilisez
React.lazyetSuspensepour les routes secondaires. - 3Différez le JavaScript non critique — Tag manager, chat, analytics, A/B testing, widget de réservation : tous ces scripts tiers doivent être chargés avec
defer,async, ou viarequestIdleCallback. Mieux : utilisez Partytown pour les exécuter dans un Web Worker. - 4Adoptez scheduler.yield() pour les tâches longues — L'API
scheduler.yield()(Chrome 129+) permet de céder le thread principal au navigateur entre deux étapes d'un calcul lourd, évitant le blocage. Sur les navigateurs antérieurs, fallback avecsetTimeout(fn, 0)oupostMessage. - 5Déléguez les calculs lourds aux Web Workers — Tout traitement de données massif (filtrage de listes de plus de 1 000 éléments, calculs de panier complexes, parsing de gros JSON) doit s'exécuter hors du thread principal. La librairie Comlink simplifie l'usage des Web Workers.
- 6Débouncez et throttlez les handlers d'événements fréquents — Les écouteurs
scroll,resize,inputnon débouncés saturent le thread. UtilisezrequestAnimationFramepour le scroll et un debounce de 150-300ms pour la saisie clavier. - 7Limitez les re-renders React inutiles — Mémoïsez les composants coûteux avec
React.memo, les valeurs dérivées avecuseMemo, les callbacks avecuseCallback. Vérifiez avec React DevTools Profiler que vos interactions ne déclenchent pas de cascades de re-renders.
Outils gratuits pour mesurer et auditer vos Core Web Vitals
FiabiliteVous n'avez besoin d'aucun outil payant pour piloter sérieusement vos Core Web Vitals. Voici la pile que nous utilisons sur tous nos projets :
- Google PageSpeed Insights (pagespeed.web.dev) — Combine données CrUX (terrain, en haut du rapport) et données Lighthouse (laboratoire, en bas). C'est le premier outil à consulter pour un diagnostic. Avantage : il pointe précisément les éléments LCP et les sources de CLS.
- Google Search Console — rapport Core Web Vitals — Agrège les données CrUX par groupes d'URLs similaires sur 28 jours, mobile et desktop séparément. C'est la seule source fiable pour suivre l'impact SEO de vos optimisations dans le temps.
- Chrome User Experience Report (CrUX) — Données publiques accessibles via BigQuery ou via l'API CrUX. Permet d'obtenir les chiffres exacts qu'utilise Google pour le ranking, et de comparer avec vos concurrents.
- Bibliothèque web-vitals.js (npm: web-vitals) — Officielle Google, intègre directement dans votre site la mesure en temps réel des CWV chez vos visiteurs. À envoyer vers Google Analytics 4, Plausible ou un endpoint maison pour piloter au quotidien.
- Lighthouse CI — Pipeline d'intégration continue qui exécute Lighthouse sur chaque pull request et bloque la merge si un seuil est dégradé. Indispensable pour ne pas régresser après un déploiement. Documentation : github.com/GoogleChrome/lighthouse-ci.
- WebPageTest (webpagetest.org) — Pour des tests labo plus poussés que Lighthouse : connexions simulées variées (3G, 4G, fibre), filmstrip détaillé, waterfall complet. Idéal pour reproduire un problème spécifique.
Quand une refonte est plus rentable qu'une optimisation
ConseilsToutes les situations ne se règlent pas avec quelques optimisations ciblées. Dans certains cas, le coût cumulé pour atteindre les seuils verts dépasse celui d'une refonte propre. Voici nos critères de décision après plusieurs centaines d'audits :
- Site Wix, Squarespace ou page builder lourd — Ces plateformes injectent un volume de JS et de CSS difficile à élaguer (souvent plus de 600 Ko de bundles tiers). Le LCP et l'INP sont structurellement dégradés sans levier d'amélioration majeur. Une refonte sur un stack moderne (Next.js, Astro) divise par 3 à 5 les temps de chargement.
- WordPress avec thème ancien et 30+ plugins — Lorsque le thème date d'avant 2022 et empile des plugins non maintenus, chaque optimisation tactique est annulée par la prochaine mise à jour. La refonte sur un thème léger (GeneratePress, Kadence) ou un headless WordPress + Next.js redonne un terrain sain.
- CLS chronique malgré corrections répétées — Si après 2-3 itérations le CLS reste au-dessus de 0,15 sur mobile, c'est généralement un problème d'architecture (template mal conçu, multiples scripts tiers concurrents). Repartir d'une base propre coûte moins cher que de corriger sans fin.
- TTFB supérieur à 1,5s en permanence — Indique un hébergement saturé ou un back-end mal optimisé. Migrer ou refondre est plus rentable que d'empiler du cache.
Quand ces signaux s'accumulent, il faut envisager une refonte de site internet orientée performance dès la conception. À l'inverse, si votre site est récent et bien construit mais souffre seulement de quelques angles morts, l'optimisation ciblée reste le meilleur retour sur investissement. Notre audit SEO complet inclut systématiquement un volet Core Web Vitals avec arbitrage refonte vs optimisation chiffré.
FAQ — Core Web Vitals et SEO
ExpertiseQuel est l'impact réel des Core Web Vitals sur le classement Google ? Les CWV sont un signal de classement, mais pas le plus puissant. À pertinence et autorité égales, le site avec de meilleurs CWV passe devant. Concrètement, après optimisation, on observe un gain médian de 1 à 4 positions sur les requêtes concurrentielles, et un meilleur taux de clics depuis les SERP. Ne comptez pas sur les CWV seuls pour ranker, mais ne les négligez pas.
Mobile et desktop, faut-il optimiser les deux ? Google utilise principalement les données CrUX mobile pour le ranking depuis l'index mobile-first. C'est donc le mobile qu'il faut prioriser, surtout sur les pages à fort trafic. Néanmoins, si plus de 30 % de votre trafic est desktop (cas des B2B), corrigez les deux.
Combien de temps pour voir l'impact SEO d'une optimisation CWV ? Les données CrUX étant calculées sur une fenêtre glissante de 28 jours, comptez 4 à 8 semaines après le déploiement pour que la Search Console reflète le changement. L'impact sur le ranking suit en général dans les 2 à 4 semaines suivantes.
Mes scores Lighthouse sont à 95+, mais Search Console est rouge — pourquoi ? Lighthouse est un test labo dans des conditions optimales. Vos visiteurs réels utilisent des appareils plus lents, des connexions plus mauvaises, et des navigateurs avec extensions. Pilotez toujours par CrUX (Search Console), pas par Lighthouse.
Faut-il viser 100/100 sur PageSpeed Insights ? Non. Au-delà de 90, le retour sur investissement chute brutalement. L'objectif réaliste est : tous les CWV en zone verte sur mobile en données CrUX. Le score Lighthouse est secondaire.
Mon site est en Wix / Shopify / page builder — puis-je quand même optimiser ? Oui, partiellement. Vous pouvez compresser les images, optimiser les fonts, désactiver les apps superflues. Mais vous resterez limité par le code généré par la plateforme. Si vos CWV sont structurellement mauvais, une création de site internet sur un stack moderne est souvent la meilleure issue.
Testez vos Core Web Vitals avec Google PageSpeed Insights (données réelles + recommandations) puis suivez l'évolution dans Search Console pendant les 4-8 semaines suivant chaque déploiement. C'est le seul circuit de mesure fiable pour le SEO.
Vos Core Web Vitals sont dans le rouge ? Un audit performance gratuit identifie les corrections prioritaires et chiffre le ROI de chaque action.
Demander un audit performance gratuitEcrit par
Clickzou
#core web vitals#performance web#lcp#cls#inp#lighthouse
