Comment réussir les Core Web Vitals : étape par étape (2026)

Le chemin le plus rapide pour réussir les Core Web Vitals

Vos Core Web Vitals ont besoin d'attention. Google Search Console affiche du rouge ou de l'orange, un client pose des questions, ou PageSpeed Insights vient d'annoncer une mauvaise nouvelle. Cette page détaille la méthode que j'applique pour faire passer les sites de l'échec à la réussite le plus rapidement possible.

J'ai utilisé cette méthode pour faire réussir les Core Web Vitals à des centaines de milliers de pages. Elle fonctionne sur WordPress, Shopify, les développements sur mesure et toutes les plateformes intermédiaires. L'ordre dans lequel vous intervenez compte. Corrigez d'abord les fondations, puis progressez vers l'extérieur. Sinon, vous perdez du temps à optimiser des éléments qu'un problème plus profond viendra neutraliser.

Où en est le web aujourd'hui

D'après le Web Almanac 2025 (basé sur les données CrUX de juillet 2025), 48 % des sites sur mobile et 56 % des sites sur ordinateur réussissent les trois Core Web Vitals. C'est un progrès par rapport aux 44 % sur mobile en 2024, mais plus de la moitié du web mobile reste en échec.

Le détail par métrique (pourcentage d'origines classées « bon » sur mobile) :

Source : Web Almanac 2025 (HTTP Archive, données CrUX de juillet 2025). Les données RUM de CoreDash sur les sites suivis montrent des répartitions similaires.

Le LCP est le goulot d'étranglement. 77 % des sites réussissent l'INP et 81 % réussissent le CLS, mais seulement 62 % réussissent le LCP. C'est ce qui tire le taux de réussite global vers le bas, à 48 %. Voilà pourquoi la méthode ci-dessous place le TTFB et le LCP en tête des priorités.

Étape 1 : faites l'état des lieux

Avant de changer quoi que ce soit, déterminez précisément quelles métriques échouent et sur quelles pages. Si vous sautez cette étape et avancez au hasard, vous perdrez votre temps à corriger les mauvais éléments.

Vérifiez Google Search Console

Ouvrez votre propriété Search Console et consultez le rapport Core Web Vitals sous « Expérience ». Vous y trouverez :

• Le nombre d'URL classées Bon, À améliorer ou Médiocre
• La métrique exacte qui échoue (LCP, INP ou CLS)
• Les groupes d'URL qui partagent le même problème (par exemple, toutes les pages produits qui échouent sur l'INP)

Search Console utilise les field data réelles d'utilisateurs de Chrome sur une période glissante de 28 jours. Ce sont ces données que Google utilise pour le classement. Si Search Console indique que vous réussissez, vous réussissez, peu importe ce que dit Lighthouse.

Analysez les pages clés dans PageSpeed Insights

Testez au moins une URL pour chaque type de page : la page d'accueil, un article de blog, une page produit, une page de catégorie ou de collection. PageSpeed Insights fournit à la fois des field data (si disponibles) et des lab data avec des diagnostics précis.

Regardez d'abord la section field data (intitulée « Découvrez ce que vivent vos utilisateurs réels »). Si elle est au vert pour les trois métriques, la page réussit. Si les field data ne sont pas disponibles, la page manque de trafic pour générer des données CrUX. Google peut alors utiliser les données au niveau du groupe d'URL ou de l'origine.

Installez un Real User Monitoring

Search Console et CrUX s'appuient sur une fenêtre glissante de 28 jours : les améliorations mettent donc des semaines à se voir. Pour constater l'impact immédiat de vos modifications, installez une solution de Real User Monitoring (RUM) comme CoreDash. Le RUM fournit des field data en temps réel pour chaque page, chaque appareil et chaque pays. Vous pouvez ainsi vérifier l'efficacité de chaque correctif avant de passer au suivant.

Étape 2 : déterminez la métrique à corriger en premier

Si plusieurs métriques échouent, corrigez-les dans cet ordre :

Le TTFB n'est pas un Core Web Vital en soi, mais chaque milliseconde de TTFB s'ajoute directement au LCP et au FCP. Une page avec un TTFB de 800 ms a déjà consommé un tiers du budget LCP de 2,5 secondes avant même que le navigateur ne démarre le rendu. Le seuil « bon » de CrUX pour le TTFB est de 800 ms, mais plus il est court, mieux c'est : tout gain sur le TTFB se répercute directement sur vos métriques de rendu. Pour en savoir plus, consultez notre guide du Time to First Byte.

Étape 3 : consolidez les fondations (TTFB)

Si votre Time to First Byte dépasse régulièrement 400 ms, commencez ici. Les problèmes habituels :

• Hébergement lent : passez à un hébergement performant avec mise en cache au niveau du serveur. Les hébergeurs infogérés pour WordPress (Kinsta, SiteGround, Cloudways) ou l'infrastructure intégrée de Shopify s'en chargent.
• Absence de cache de page : assurez-vous que le CMS met en cache le code HTML entièrement rendu pour éviter que le serveur ne le régénère à chaque requête.
• Absence de CDN : mettez en place un CDN (Cloudflare est gratuit) pour distribuer les pages depuis des emplacements edge proches des visiteurs. Consultez notre guide de configuration de Cloudflare.
• Redirections : chaque redirection ajoute un aller-retour réseau complet. Supprimez les chaînes de redirection inutiles.
• Backend lent : requêtes en base de données non optimisées, trop d'extensions WordPress ou traitements lourds côté serveur. Utilisez des outils de surveillance des requêtes pour repérer les goulots d'étranglement.

Objectif : amener le TTFB sous les 200 ms pour la majorité des visiteurs. Au grand maximum sous les 400 ms.

Étape 4 : corrigez le LCP

Une fois le TTFB stabilisé, réglez le Largest Contentful Paint. Voici la démarche :

Identifiez votre élément LCP

Analysez la page en échec dans PageSpeed Insights et trouvez l'« Élément Largest Contentful Paint » dans la section Diagnostics. Il s'agit généralement d'une image hero, d'une image mise en avant ou d'un bloc de texte volumineux.

Si le LCP est une image

1. Assurez-vous que le navigateur puisse la trouver dans le HTML. L'URL de l'image doit figurer dans une balise standard <img src="">, et non dissimulée derrière un attribut data-src ou injectée via JavaScript. Si le parseur HTML du navigateur ne voit pas l'URL de l'image, il ne peut pas déclencher son chargement au plus tôt. Selon le Web Almanac 2025, 7 % des sites web masquent encore leur image LCP de cette façon.
2. Ajoutez fetchpriority="high" à la balise <img>. Cela indique au navigateur de prioriser cette image par rapport aux autres ressources en concurrence pour la bande passante. Sans cela, le navigateur risque de télécharger d'abord les feuilles de style, les scripts et d'autres images. Dans un test mené par Google sur Google Flights, ce simple changement a fait passer le LCP de 2,6 s à 1,9 s.
3. Supprimez loading="lazy". Le lazy loading retarde la requête jusqu'à ce que l'image soit proche du viewport. Sur une image LCP, ce délai gonfle directement votre score LCP.
4. Optimisez le poids du fichier. Convertissez l'image en WebP ou AVIF. Servez les dimensions adaptées au viewport à l'aide de srcset et sizes.
5. Si l'image n'est pas dans le HTML (image d'arrière-plan CSS, injectée en JavaScript, ou sur une page où vous ne pouvez pas modifier la balise <img>) : ajoutez un préchargement. Utilisez <link rel="preload" as="image" href="..." fetchpriority="high"> dans le <head>. Le préchargement force le navigateur à détecter l'image sans attendre, même lorsqu'elle n'est pas visible dans le code source HTML. Pour les images qui figurent déjà dans une balise <img> normale, le préchargement est généralement superflu puisque le parseur les découvre déjà.

Si le LCP est du texte

1. Limitez le CSS render blocking. Ne chargez que le CSS dont la page a besoin, afin que le navigateur puisse afficher le texte sans attendre une feuille de style volumineuse.
2. Optimisez le chargement des polices. Hébergez vos polices en local et préchargez le fichier de police principal pour réduire le délai avant l'affichage du texte.
3. Réduisez le JavaScript render blocking. Différez le JavaScript non critique pour qu'il ne bloque pas le parseur HTML.

Étape 5 : corrigez l'INP

Dès que le LCP est validé, traitez l'Interaction to Next Paint. L'INP échoue quand JavaScript bloque le main thread pendant les interactions de l'utilisateur.

Trouvez le goulot d'étranglement

Ouvrez les DevTools de Chrome, allez dans le panneau Performance et enregistrez une session où vous interagissez avec la page. Repérez les long tasks (les tâches de plus de 50 ms, affichées sous forme de barres rouges). Ce sont elles qui empêchent le navigateur de réagir à vos clics.

Ce qui bloque généralement le main thread :

• Les scripts tiers (analytics, publicités, widgets de chat, balises marketing) qui accaparent le main thread
• Les bundles JavaScript volumineux issus de frameworks, de constructeurs de page ou d'extensions qui s'exécutent lors du chargement de la page
• Les gestionnaires d'événements non optimisés qui effectuent trop d'opérations lors d'un clic ou d'une touche enfoncée

L'ordre de priorité des correctifs

1. Retardez les scripts tiers. Les scripts de chat, d'analytics, de réseaux sociaux et de marketing doivent se charger après la première interaction de l'utilisateur, et non pendant le chargement initial de la page.
2. Différez le JavaScript interne non critique. Appliquez defer ou async aux scripts qui n'ont pas besoin d'être exécutés avant que la page devienne interactive.
3. Découpez les long tasks. Si votre propre code comporte des fonctions qui prennent plus de 50 ms, faites un yield vers le main thread pour permettre au navigateur de traiter les entrées de l'utilisateur entre deux blocs de travail. La méthode moderne repose sur scheduler.yield() (pris en charge dans Chrome 129+ et Edge). Pour une compatibilité navigateur plus large, rabattez-vous sur un setTimeout(resolve, 0) encapsulé dans une Promise :

   async function yieldToMain() {
     if ('scheduler' in window && 'yield' in scheduler) {
       return scheduler.yield();
     }
     return new Promise(resolve => setTimeout(resolve, 0));
   }

4. Supprimez le JavaScript inutilisé. Utilisez l'onglet Coverage des DevTools de Chrome pour repérer le code JavaScript qui se charge sans jamais s'exécuter. Supprimez-le ou chargez-le conditionnellement.

Pour la stratégie complète d'optimisation de l'INP, consultez notre guide d'optimisation de l'INP.

Étape 6 : corrigez le CLS

Le CLS est généralement la métrique la plus facile à corriger. Causes et solutions les plus fréquentes :

Images sans dimensions

Chaque balise <img> a besoin d'attributs width et height explicites. Sans eux, le navigateur ne sait pas quel espace réserver et le contenu saute au chargement de l'image. C'est la première cause de CLS dans le monde. Consultez notre guide du CLS.

Remplacement des polices web

Quand une police web se charge et remplace la police fallback, le texte peut se réajuster et décaler les éléments voisins. Solution : hébergez les polices en local, appliquez font-display: optional ou utilisez la propriété CSS size-adjust pour aligner les métriques de la police fallback sur celles de la police web.

Contenu injecté dynamiquement

Bandeaux de cookies, barres de notification, encarts publicitaires et pop-ups qui décalent le contenu vers le bas après le chargement. Solution : réservez l'espace nécessaire avec la propriété CSS min-height ou chargez-les d'une façon qui n'altère pas la mise en page environnante (par exemple en superposition plutôt qu'en insertion dans le flux).

Étape 7 : vérifiez avec les field data

Après avoir appliqué vos correctifs, vérifiez qu'ils fonctionnent en conditions réelles, pas uniquement dans Lighthouse.

• Vérification immédiate : utilisez CoreDash ou un autre outil RUM pour visualiser les field data en temps réel. Les améliorations doivent être visibles en quelques heures.
• Vérification CrUX : le Chrome User Experience Report couvre les 28 derniers jours et est actualisé chaque jour. Chaque nouvelle journée enregistre des visites postérieures au correctif et écarte les plus anciennes : il faut donc jusqu'à 28 jours pour que la fenêtre ne reflète que des visites postérieures au correctif.
• Vérification Search Console : le rapport Core Web Vitals de Search Console s'actualise à partir des données CrUX. Dès que CrUX montre une amélioration, Search Console suit.

Ce décalage rend le RUM indispensable. Sans lui, vous travaillez à l'aveugle pendant plusieurs semaines avant de savoir si vos changements ont fonctionné.

Étape 8 : surveillez et maintenez

La performance se dégrade avec le temps. Chaque nouvelle extension, mise à jour de thème ou script tiers peut anéantir vos optimisations. Mettez en place une surveillance continue :

• Consultez chaque semaine le rapport Core Web Vitals dans Search Console
• Utilisez CoreDash pour un suivi continu en temps réel avec des alertes
• Refaites un test dans PageSpeed Insights après chaque changement notable (nouvelle extension, mise à jour de thème, ajout de script tiers)
• Auditez les scripts tiers chaque trimestre. Supprimez ceux qui ne sont plus nécessaires.

Pour disposer d'un inventaire complet de tous les points à contrôler, utilisez notre checklist ultime des Core Web Vitals.

Gains rapides : les correctifs au plus fort impact

Si vous n'avez le temps de faire que cinq actions, voici les correctifs les plus percutants sur toutes les plateformes :

Ces ordres de grandeur d'impact proviennent des données de suivi réel (RUM) de CoreDash sur divers projets d'optimisation. Votre progression réelle dépendra de votre situation initiale, de votre hébergement et du profil de votre trafic. Les sites partant de scores très dégradés (LCP supérieur à 5 secondes) enregistrent souvent des gains encore plus spectaculaires. Les sites déjà proches des seuils obtiendront des gains absolus plus modestes, mais suffisants pour basculer de l'échec à la réussite.

Les données du Web Almanac 2025 confirment ces priorités. Les pages d'accueil ne réussissent les Core Web Vitals qu'à 45 % sur mobile, alors que les pages secondaires atteignent 56 %. Cet écart provient du fait que les pages d'accueil intègrent généralement plus de contenu dynamique, des images hero plus lourdes et davantage de scripts tiers. Si votre page d'accueil échoue alors que vos pages internes sont validées, concentrez vos efforts d'optimisation LCP et INP en priorité sur le gabarit de la page d'accueil.