Core Web Vitals 2026 sur mobile : les chiffres à viser et comment les atteindre

Sur mobile en 2026, trois seuils non négociables : LCP < 2,5 s, INP < 200 ms, CLS < 0,1, mesurés au 75e percentile sur 28 jours glissants en données de terrain. C’est ce que Google appelle la zone “good” et c’est le minimum pour ne pas perdre de classement dans la Search Console.

Mais si vous voulez l’avantage compétitif réel — celui qui se voit dans le taux de conversion mobile, pas juste dans un rapport — visez plutôt LCP < 1,2 s, INP < 100 ms, CLS < 0,05. C’est la cible que je tiens sur toutes les livraisons depuis 2023, sur des sites métier comme urgenceserrures.fr ou plombiersidf.fr qui doivent convertir un client en panique en moins de trente secondes.

Voici ce qui a changé dans le tableau de bord depuis mars 2024, les chiffres précis à viser sur chaque vital, et la méthode que j’applique chez mes clients pour les tenir.

Ce qui a changé depuis mars 2024

Le FID (First Input Delay) a été remplacé par l’INP (Interaction to Next Paint) le 12 mars 2024 comme troisième Core Web Vital officiel. Ce n’est pas une mise à jour cosmétique. Le FID ne mesurait que le délai avant que le navigateur commence à traiter votre première interaction. Vous pouviez avoir un FID excellent et un site qui rame sur tous les clics suivants — le score ne le voyait pas.

L’INP, lui, mesure la latence complète (input + processing + presentation) de toutes les interactions de la session et retient la pire selon la documentation de Chrome for Developers. Concrètement, si votre menu hamburger met 400 ms à s’ouvrir au troisième clic parce qu’un script analytics se déclenche au scroll, votre INP est à 400 ms même si le premier clic était instantané.

Le résultat : selon le Web Almanac 2024 publié par HTTP Archive, seulement 49% des sites passaient les trois Core Web Vitals sur mobile en données de terrain à la fin 2024, contre 64% l’année précédente sous l’ancien système avec FID. L’INP a sorti beaucoup de monde de la zone verte sans que rien ne change techniquement sur leurs sites. C’est ce qui justifie de regarder son tableau Search Console deux fois par mois, pas deux fois par an.

Le deuxième changement majeur : le mobile pèse maintenant lourd dans l’évaluation. Le rapport de la Search Console sépare desktop et mobile, et le mobile est de plus en plus pénalisant. Selon les données INSEE publiées en 2024, 79% des Français de 15 à 74 ans utilisent leur smartphone pour aller sur internet, contre 67% pour un ordinateur. Optimiser pour le desktop d’abord est une erreur stratégique en 2026.

LCP : passer sous 1,2 s sur mobile

Le Largest Contentful Paint mesure le temps que met le plus gros élément visible (en pratique, presque toujours une image hero ou un bloc de texte au-dessus de la ligne de flottaison) à être peint à l’écran. Seuil “good” selon web.dev : 2,5 s. Ma cible : 1,2 s.

Les quatre leviers qui comptent vraiment, dans l’ordre d’impact :

1. TTFB sous 200 ms. Si votre serveur met 600 ms à répondre, vous avez déjà perdu un quart du budget LCP. C’est la raison principale pour laquelle je sers tous mes sites statiques depuis le edge Netlify ou Cloudflare Pages — le HTML arrive en 30 à 80 ms depuis Paris. Sur un WordPress avec PHP-FPM dégradé et un cache mal configuré, le TTFB monte régulièrement à 800 ms ou plus, et aucune optimisation côté frontend ne rattrapera ça.

2. Image hero préchargée et bien dimensionnée. Une image hero en JPEG non compressé à 2 Mo charge en 4 s sur une 4G dégradée. La même image en AVIF à 50 ko charge en 200 ms. J’utilise astro:assets pour générer automatiquement les variantes AVIF + WebP + JPEG avec des breakpoints adaptés, et un <link rel="preload" as="image" fetchpriority="high"> pour signaler au navigateur l’urgence absolue de cette ressource.

3. Fonts en font-display: swap avec subsetting. Une font web non-subsettée pèse souvent 200 ko et bloque le rendu du texte. Avec unicode-range sur les caractères latins de base, vous passez à 30 ko et le texte apparaît immédiatement avec la font système, puis bascule sans flash quand la font custom est chargée.

4. CSS critique inliné. Pour un site Astro avec Tailwind v4, je laisse le build inliner automatiquement le CSS critique au-dessus de la ligne de flottaison. Sur les pages d’atterrissage de plombiersidf.fr, ça fait gagner 300 à 400 ms de LCP sur une connexion 4G simulée.

Sur un site WordPress, le LCP descend rarement sous 2,5 s sans changer de stack. J’ai mesuré 4,2 s en moyenne sur les sept sites WordPress que j’ai migrés depuis 2023, contre 800 ms après bascule sur Astro à configuration de contenu identique. Le LCP n’est pas un problème de fine-tuning, c’est un problème d’architecture.

INP : sous 200 ms sans tout hydrater

L’INP est la métrique la plus difficile à tenir en 2026 parce qu’elle pénalise tout JavaScript bloquant sur le thread principal. Seuil “good” : 200 ms. Ma cible : 100 ms.

L’erreur classique que je vois chez 7 sites sur 10 : un framework qui hydrate toute la page côté client alors que 80% du contenu est statique. Next.js en mode hybride, Nuxt en SSR full, ou pire, un WordPress avec un thème React-based qui charge 600 ko de JS pour afficher une page À propos.

La règle que j’applique : JavaScript uniquement là où il est nécessaire. Sur Astro, j’utilise les directives d’hydratation partielle (client:load, client:visible, client:idle) pour cibler précisément les composants interactifs. Un formulaire de contact a besoin d’être hydraté. Un titre H1 et un paragraphe non. La différence se mesure en INP : sur une page comparable, je suis passé de 280 ms (hydratation globale) à 60 ms (hydratation partielle) sur le même contenu.

Les trois actions à fort impact, dans l’ordre :

• Auditer les scripts tiers. Google Tag Manager, Hotjar, Intercom, chatbots — chaque tiers ajoute typiquement 50 à 150 ms d’INP. Si vous n’utilisez pas réellement la donnée, supprimez. Pour ceux que vous gardez, chargez-les en defer ou via un dispatcher type Partytown qui les exécute sur un Web Worker.

• Éviter les listeners synchrones lourds. Un onClick qui déclenche un calcul de 200 ms bloque l’INP de la prochaine interaction. Découpez avec requestIdleCallback ou scheduler.postTask pour rendre la main au navigateur entre deux tâches.

• Mesurer en conditions réelles. Le bouton qui fonctionne bien sur votre MacBook M3 peut être catastrophique sur un Samsung A14 en zone Île-de-France à 50% de batterie. J’utilise la bibliothèque web-vitals de Google directement dans le code de production sur quelques sites stratégiques pour remonter les vrais INP par utilisateur dans Plausible.

CLS : sous 0,05 et tenir dans la durée

Le Cumulative Layout Shift mesure les décalages visuels imprévus pendant la session. Seuil “good” : 0,1. Ma cible : 0,05.

Les sources de CLS sont bien identifiées et toutes corrigibles à la racine. Quatre causes que je traque systématiquement :

1. Images sans dimensions. Toute balise <img> doit avoir width et height explicites. Sans ça, le navigateur réserve zéro pixel, puis pousse le contenu vers le bas quand l’image arrive. Sur Astro avec astro:assets, les dimensions sont calculées automatiquement à la build — c’est une des raisons pour lesquelles je l’utilise.

2. Fonts avec FOUT mal géré. Le passage de la font système à la font web peut décaler tout le texte si les métriques diffèrent. J’utilise size-adjust, ascent-override et descent-override dans les déclarations @font-face pour aligner les deux fonts. Outils utiles : le Font Style Matcher de Monica Dinculescu et le générateur de fallback metrics de Malte Ubl.

3. Bannières (cookies, RGPD, notifications) qui apparaissent après chargement. Réservez l’espace en amont avec un min-height sur le conteneur, même vide. Mieux : si vous n’avez pas besoin d’un bandeau cookies (cas valide selon la doctrine CNIL pour Plausible ou Matomo configurés en mode anonyme), supprimez-le complètement.

4. Ads et embeds tardifs. Les iframes YouTube, Twitter, ou les widgets analytics-visibles peuvent provoquer du CLS s’ils chargent après le scroll. Pour les embeds, utilisez la technique du wrapper avec aspect-ratio CSS. Pour les ads, négociez des slots à taille fixe avec votre régie.

Le CLS est la métrique la plus facile à régler une fois pour toutes — et celle qui régresse le plus facilement quand un nouveau bandeau est rajouté en urgence par une équipe marketing. Mettez en place une mesure CrUX en continu pour ne pas découvrir trois mois plus tard que votre site est passé de 0,03 à 0,18 parce qu’un consultant a ajouté une promo en pop-up.

Comment je mesure réellement

PageSpeed Insights est utile mais trompeur. Le score Lighthouse est un test en laboratoire, déterministe, qui ne reflète pas vos vrais utilisateurs. Ce qui compte, c’est ce que voit le CrUX — la collecte de données réelles Chrome — et c’est ce que Google utilise pour le ranking.

Ma stack de mesure en 2026, sur tous mes sites :

• PageSpeed Insights une fois par semaine sur la page d’accueil et 3 pages internes stratégiques, pour repérer les régressions structurelles.
• Search Console > Core Web Vitals une fois par mois pour le terrain officiel Google.
• CrUX Dashboard ou Treo Sites pour la tendance sur 6 mois, par segment desktop/mobile.
• web-vitals.js intégré au site sur les sites à fort trafic, avec remontée vers Plausible Custom Events, pour avoir les données en temps réel sans dépendre du calendrier Google.
• Lighthouse CI dans la pipeline Netlify pour bloquer toute pull request qui dégraderait les métriques en lab.

Je facture entre 1 500 et 4 000 euros HT un audit + optimisation Core Web Vitals sur un site WordPress existant, hors refonte. Sur un Astro déjà bien architecturé, le tuning fin se fait en quelques heures. Sur un WordPress avec dix plugins et un thème commercial, il faut parfois accepter qu’aucune optimisation côté frontend ne suffira et qu’une refonte est plus économique à 24 mois.

Le tableau récapitulatif des seuils 2026 {#summary}

Métrique	Mesure	Seuil “good” Google	Ma cible	Seuil “poor”
LCP	Largest Contentful Paint	≤ 2,5 s	≤ 1,2 s	> 4,0 s
INP	Interaction to Next Paint	≤ 200 ms	≤ 100 ms	> 500 ms
CLS	Cumulative Layout Shift	≤ 0,1	≤ 0,05	> 0,25
TTFB	Time to First Byte	≤ 800 ms	≤ 200 ms	> 1 800 ms

Le TTFB n’est pas un Core Web Vital officiel mais c’est le précurseur du LCP. Si votre TTFB dépasse 500 ms, aucune optimisation frontend ne vous fera passer en vert sur le LCP. Commencez par là.

Tous les seuils sont évalués au 75e percentile sur 28 jours glissants. Cela signifie que 75% de vos sessions doivent respecter le seuil pour être “good”. Une seule session sur quatre qui dépasse suffit à vous faire basculer en “needs improvement”.

Ce qu’il faut retenir {#takeaways}

• Les trois Core Web Vitals à tenir sur mobile en 2026 sont LCP < 2,5 s, INP < 200 ms, CLS < 0,1 au 75e percentile
• L’INP a remplacé le FID le 12 mars 2024 et a fait sortir beaucoup de sites de la zone verte sans changement technique de leur côté
• 79% des Français accèdent à internet via smartphone selon l’INSEE 2024 — optimiser le desktop d’abord est une erreur stratégique
• Sur un WordPress moyen, le LCP dépasse rarement les 2,5 s sur mobile : c’est un problème d’architecture, pas de tuning
• L’hydratation partielle (Astro, Qwik, Solid) divise typiquement l’INP par 3 par rapport à un framework SSR full-hydrate
• Le score Lighthouse global ne sert pas au ranking — seul le CrUX en données de terrain compte aux yeux de Google
• Un audit + optimisation Core Web Vitals sur site existant coûte entre 1 500 et 4 000 euros HT en freelance senior