Core Web Vitals 2026 : Passer LCP, INP et CLS au Vert en 2 Semaines

Depuis mars 2024, INP a remplacé FID. En 2026, les trois Core Web Vitals (LCP, INP, CLS) sont un signal de ranking stable, et surtout : un mauvais score casse le taux de rebond et pénalise toute la chaîne de conversion.

Semaine 1 — Audit et quick-wins

Jour 1 : mesure de base

Outils gratuits à utiliser dans cet ordre :

• PageSpeed Insights (données de terrain + lab)
• Search Console → Core Web Vitals (données CrUX agrégées)
• Chrome DevTools → Performance → Lighthouse (reproduction locale)
• WebPageTest.org (filmstrip détaillé, waterfall)

Jour 2-3 : optimiser LCP

LCP mesure le temps d'affichage du plus gros élément visible (souvent une image hero ou un titre). Les wins :

• Preload l'image LCP : <link rel="preload" as="image" href="/blog/hero.webp">
• Servir en WebP/AVIF : −60 à −80 % de poids vs JPEG
• Dimensions explicites (width, height)
• CDN avec edge locations proches de vos utilisateurs (Vercel, Cloudflare)
• Supprimer les render-blocking resources (JS synchrone, CSS externe bloquant)
• Inline critical CSS pour le above-the-fold

Jour 4-5 : optimiser CLS

CLS mesure les sauts de contenu pendant le chargement. Les causes fréquentes :

• Images sans width/height → toujours les préciser
• Fonts qui swap tardivement → font-display: optional ou preload + size-adjust
• Pubs ou embeds sans hauteur réservée → aspect-ratio ou conteneur fixe
• Contenu injecté dynamiquement au-dessus du fold (bannières cookies) → réserver l'espace

Jour 6-7 : optimiser INP

INP mesure la réactivité aux interactions (clic, scroll). Les leviers :

• Réduire le JavaScript main-thread : code-splitting, dynamic imports
• Débouncer les handlers coûteux
• Déplacer les tâches lourdes en Web Worker
• Utiliser requestIdleCallback pour les tâches non-critiques
• Désactiver les tiers scripts lourds ou les charger après interaction

Semaine 2 — Réécritures ciblées

Migration vers images modernes

Si votre site sert encore du JPEG/PNG classique : Next.js Image ou un CDN image (Cloudinary, imgix, Vercel Image) génère automatiquement WebP/AVIF. Gain typique : −50 % de LCP sur les pages hero.

Suppression des tiers scripts inutiles

Chaque tag tiers ajoute 50 à 300ms d'INP. Audit :

• Google Analytics → gtag → vérifier le nécessaire, envisager Plausible ou PostHog
• Facebook Pixel, LinkedIn Insight → ne charger qu'après consentement
• Chat widgets (Intercom, Drift) → lazy-load après 3s ou sur scroll
• A/B testing tools → délai de chargement en non-critique

Migration de stack si nécessaire

Si vous êtes sur WordPress shared hosting et que rien ne passe au vert malgré les correctifs, la stack elle-même peut être le bloqueur. Voir Next.js vs WordPress et le comparatif hébergement.

Cas concret : e-commerce passé de rouge à vert en 10 jours

Actions : preload image hero, compression WebP, hauteur explicite sur bannière promo, lazy-load du chat, code-splitting des composants de checkout.

Les Core Web Vitals ne sont pas un objectif en soi. C'est un proxy pour "le site marche bien". Optimiser CWV, c'est optimiser l'expérience — le SEO suit automatiquement.

Monitoring continu

Une fois au vert, mettre en place :

• Alertes Search Console pour toute dégradation
• RUM (Real User Monitoring) : Vercel Speed Insights, Sentry, SpeedCurve
• Review CWV mensuelle avec l'équipe

Lab data vs field data — pourquoi vos scores divergent

Une frustration classique — Lighthouse affiche 96 en local et Search Console signale "à améliorer" sur 40 % de l'URL. Ce n'est pas un bug, c'est la différence entre données de laboratoire et données de terrain (CrUX). Comprendre l'écart change radicalement la priorisation.

Ce que mesure Lighthouse en local

Lighthouse simule un Moto G4 sur 4G ralentie (1,6 Mbps download, 150ms RTT) depuis votre machine de dev — souvent fibre, proche du serveur d'origine. La page est testée à froid, sans cache, en mode incognito, et chaque run produit un score différent (variance de ±5 points typique). C'est un test synthétique reproductible, pas une mesure d'usage.

Ce que mesure CrUX (le terrain)

Le Chrome User Experience Report agrège anonymement les visites réelles des utilisateurs Chrome connectés, sur les 28 derniers jours. Google publie le P75 — autrement dit, la valeur sous laquelle se situent 75 % des sessions. Si votre INP P75 vaut 410 ms, cela signifie qu'un quart de vos visiteurs subissent au moins 410 ms de latence à chaque interaction. Vous pouvez avoir un Lighthouse vert et un CrUX rouge si :

• Votre trafic mobile dépasse 60 % et l'audit Lighthouse a été lancé en desktop
• Vos utilisateurs sont en zones 4G médiocres (campagne, transports) alors que vous testez en fibre
• Un cookie banner ou une extension navigateur bloque l'INP en conditions réelles
• Le service worker / cache HTTP masque la latence du TTFB initial

Méthode : trianguler avec un RUM

Installer un RUM léger (Vercel Speed Insights, Plausible Web Vitals, Sentry Performance) permet de segmenter par device, géographie, type de connexion et URL. C'est la seule manière de répondre à la question : "où, exactement, mes utilisateurs souffrent ?". Sur un site testé récemment, le P75 mobile INP global était de 240 ms, mais une fois segmenté par page la fiche produit montait à 580 ms — un seul composant React mal mémoïsé. Sans RUM, l'optimisation se serait dispersée sur la home, qui allait déjà très bien.

Tableau comparatif : lab vs field

En résumé : pilotez vos décisions sur le terrain, debuggez en lab. L'inverse est l'erreur la plus commune sur les projets que nous reprenons en migration WordPress → Next.js.

Pièges spécifiques par stack

WordPress — la dette technique invisible

Sur WordPress, l'INP est presque toujours dégradé par 3 sources : jQuery encore actif (Gutenberg en a réduit la dépendance mais beaucoup de thèmes l'embarquent), un page builder lourd (Elementor, WPBakery — chacun ajoute 200 à 600 ko de JS minifié), et la chaîne de plugins. Un audit honnête commence par lister les plugins actifs : tout plugin non utilisé en page d'accueil doit être désactivé sur cette page via un plugin de type Asset CleanUp ou un mu-plugin custom. Gain typique sur la page d'accueil d'un site B2B : −180 ko de JS, −90 ms d'INP.

Le second piège WordPress : les Web Fonts chargées via Google Fonts en CSS @import dans le thème. Le RTT vers fonts.googleapis.com retarde le LCP de 200 à 500 ms en mobile 4G. Solution : self-host les fichiers woff2 (plugin OMGF ou copie manuelle) avec font-display: swap et un preload sur la police critique de l'above-the-fold.

Next.js — les régressions silencieuses

Next.js livre nativement de bonnes métriques, mais trois erreurs reviennent en code review :

• next/image sans priority sur le LCP — l'image hero est lazy-loadée par défaut, le LCP grimpe à 3 s. Ajouter priority sur l'image LCP de chaque page, et seulement celle-là.
• Un Client Component qui remonte trop haut — un 'use client' placé dans le layout transforme l'arbre entier en JS hydraté. Garder les Client Components aux feuilles (boutons, formulaires) et passer les enfants en props.
• Polices Google via next/font sans display: 'swap' — bloque le LCP. Toujours configurer display explicitement.

Shopify — le poids des apps

Sur un Shopify avec 12 apps installées, le poids JS dépasse régulièrement 1,5 Mo. Chaque app injecte ses scripts en synchronisé. Utiliser le rapport "Online Store Speed" pour identifier les apps coûteuses, puis désinstaller systématiquement les apps inutilisées (un audit dans Asset Reports liste les apps citées par 0 page). Le second gros levier : passer le thème en Online Store 2.0, qui charge les sections en lazy. Sur un e-commerce de 80 SKU, ce switch fait gagner −1,2 s de LCP mobile.

Quand un score parfait ne suffit pas — performance perçue

Un site peut avoir 100/100 Lighthouse et "se sentir" lent. La performance perçue ne se mesure pas dans les CWV — elle inclut la cohérence des transitions, la présence de skeleton screens, la latence apparente des micro-interactions. Trois leviers concrets :

View Transitions API

Disponible sur Chromium et bientôt Safari, l'API document.startViewTransition() fait fondre les navigations internes (carte produit → détail produit) en moins de 150 ms de transition lissée. Coût d'implémentation : 30-60 minutes par template. Effet immédiat sur l'impression de fluidité — sans toucher au LCP réel.

Optimistic UI

Sur les actions utilisateur (ajouter au panier, liker, sauvegarder), afficher le résultat immédiatement sans attendre le retour serveur. En cas d'erreur, rollback. La latence ressentie passe de 400 ms à 0 ms. Bibliothèques utiles : React 19 useOptimistic, SWR mutate, TanStack Query optimistic updates.

Skeleton screens calibrés

Un skeleton screen mal proportionné est pire que rien — il provoque un CLS à l'arrivée du contenu réel. La règle : hauteur et largeur du skeleton doivent matcher le contenu final au pixel près, animation shimmer subtile (durée ≥ 1,5 s pour éviter l'effet hypnotique). Pour un e-commerce, voir notre analyse des erreurs de conversion qui inclut un volet performance perçue.

Budget de performance — la discipline qui dure

Sans budget chiffré, les CWV régressent toutes les 6 semaines. Un budget de performance fixe des plafonds non négociables dans le pipeline CI, vérifiés à chaque pull request via Lighthouse CI ou bundlesize.

Exemple de budget pour un site vitrine

• JS first-party : 90 ko gzippé max
• JS third-party (analytics, chat, A/B) : 30 ko max
• CSS : 25 ko gzippé max, dont 12 ko critical inline
• LCP mobile P75 : ≤ 2,2 s (marge de sécurité vs 2,5 s)
• INP P75 : ≤ 180 ms
• Poids total above-the-fold : ≤ 350 ko

Toute PR qui dépasse un seuil bloque la merge — l'auteur doit justifier l'écart en commentaire ou réduire ailleurs. Ce simple garde-fou suffit à maintenir un site au vert sur 24 mois sans audit semestriel coûteux.

Questions fréquentes