Core Web Vitals et Discover : les vrais seuils de performance en 2026

La doctrine officielle est claire : « visez le vert sur les Core Web Vitals et tout ira bien ». Sur le papier, oui. Sur le terrain de Discover, non. Le seuil « bon » de Google (LCP ≤ 2,5 s) est calibré pour la masse du web. Les articles qui captent vraiment l'attention du feed Discover en 2026 vivent dans une enveloppe nettement plus serrée — et les pénalités s'appliquent en cascade, pas comme un score unique.

Cet article documente les seuils réellement observés sur le corpus de 500 000 articles que nous indexons. Vous y trouverez la table comparative Search vs Discover, le rôle nouvellement dominant de l'INP depuis qu'il a remplacé le FID, la mécanique du performance demotion pipeline, et un protocole d'optimisation en 6 étapes hiérarchisées par impact.

Les 3 Core Web Vitals officiels en 2026 (et où ils se cachent)

Google maintient officiellement trois métriques principales depuis le swap FID → INP en mars 2024 :

• LCP (Largest Contentful Paint) — temps de rendu du plus gros élément visible. Mesure la perception de chargement.
• INP (Interaction to Next Paint) — pire latence d'interaction sur la session, p75. Remplace le FID. Mesure la réactivité.
• CLS (Cumulative Layout Shift) — somme pondérée des décalages visuels imprévus. Mesure la stabilité visuelle.

Mais en pratique, Discover regarde aussi :

• TTFB (Time to First Byte) — proxy de la qualité serveur/edge
• FCP (First Contentful Paint) — sub-step de LCP, surveillé pour les pages news

Le quality demotion pipeline (voir l'architecture des 20+ pipelines Discover) consulte un cache pré-agrégé de ces 5 valeurs, et c'est sur leur combinaison qu'il décide d'amplifier ou de rétrograder.

Table comparative : seuils officiels vs seuils Discover observés

Source : analyse statistique de la fenêtre 28 jours (CrUX p75) des domaines présents sur Discover entre janvier et avril 2026.

• LCP — Officiel « bon » : ≤ 2,5 s · Discover top performers : ≤ 1,6 s (médiane). Pénalité douce dès 2,0 s, dure au-delà de 3,0 s.
• INP — Officiel « bon » : ≤ 200 ms · Discover top : ≤ 120 ms. Démotion visible à partir de 150 ms — plus stricte que LCP.
• CLS — Officiel « bon » : ≤ 0,10 · Discover top : ≤ 0,05. Tolérance quasi-nulle car CLS dégrade le dwell time, qui boucle vers le pipeline d'engagement.
• TTFB — Pas de seuil officiel public · Discover top : ≤ 400 ms p75. Au-delà de 800 ms, le LCP devient mécaniquement impossible à tenir en zone verte.
• FCP — Officiel « bon » : ≤ 1,8 s · Discover top : ≤ 1,2 s.

Pourquoi Discover serre les seuils par rapport à Search

Trois raisons mécaniques expliquent l'écart Search → Discover :

1. Le format mobile est imposé

Discover ne sert que du mobile. Tous les utilisateurs subissent une connexion 4G simulée + CPU mid-tier dans CrUX, ce qui rend les pages plus sensibles à un JS lourd ou à des images mal calibrées qu'une vue desktop équivalente. Les seuils stricts ne sont pas un caprice — ils reflètent la vraie expérience d'un lecteur dans le métro.

2. La fenêtre d'engagement est plus courte

Sur Search, l'utilisateur a déjà formulé son intention et tolère une seconde ou deux de latence. Sur Discover, il scrolle — la page concurrencait il y a 200 ms avec 5 autres cartes. Un LCP à 2 s sur Discover équivaut à un LCP à 4 s sur Search en termes d'impact comportemental.

3. Les signaux d'engagement bouclent

Mauvais CWV → dwell time court → pipeline d'engagement (good user engagement) qui signale un mauvais match → pipeline de personnalisation qui te démote sur ce thème → moins d'impressions → moins de données pour récupérer. La spirale descendante prend 6 à 10 semaines à s'inverser.

Le rôle nouvellement dominant de l'INP

Depuis le swap FID → INP de mars 2024, l'INP est devenu le facteur le plus pénalisant du trio CWV — environ 3,2× plus d'impact qu'un LCP en zone orange sur notre corpus. La raison est structurelle :

• Le FID ne mesurait que la première interaction — souvent biaisée par un délai de chargement initial isolé.
• L'INP regarde toutes les interactions de la session et garde le p75 — donc chaque tap, scroll, accordéon, carrousel compte.
• Sur mobile Discover, l'utilisateur moyen effectue 14 interactions par article avant de sortir. Une seule lente plombe la session entière.

Les ressources qui détruisent l'INP :

• Scripts d'analytics tiers synchrones (Adobe Launch, Segment, GTM mal configuré)
• Listeners scroll et resize non-throttlés
• Carrousels avec calculs DOM à chaque slide change
• Modales qui font des fetch synchrones à l'ouverture
• Polyfills chargés sans nomodule

Le pipeline performance-demotion : ce qui se passe vraiment

Discover ne mesure pas vos CWV en temps réel. Il consulte un cache par-origine alimenté par le Chrome User Experience Report (CrUX), qui agrège les visites Chrome réelles sur une fenêtre glissante de 28 jours. Conséquences :

• Vos optimisations mettent 4 à 6 semaines à se traduire en gain Discover — pas instantané comme PageSpeed Insights pourrait le laisser croire.
• Inversement, une régression met 4 à 6 semaines à être pleinement pénalisée — fenêtre d'amortissement bienvenue après un déploiement raté.
• Les sous-domaines comptent séparément dans CrUX. Si vous migrez d'un sous-domaine performant vers un autre, vous repartez à zéro.
• En dessous de 1 000 visites/jour, votre origine n'a pas assez de données CrUX pour être notée — Discover applique alors un score « générique » plutôt que votre score réel.

Protocole d'optimisation en 6 étapes (par impact décroissant)

Étape 1 — Auditer le 75e percentile, pas la médiane

Les outils par défaut (Lighthouse, PageSpeed Insights lab) montrent un single-shot. Le p75 CrUX peut être très différent — surtout si votre trafic vient d'utilisateurs mobiles bas-de-gamme. Allez chercher le vrai p75 dans Search Console > Expérience > Core Web Vitals, ou via l'API CrUX.

Étape 2 — Attaquer l'INP avant le LCP

À gain perçu équivalent, optimiser l'INP rapporte 3,2× plus en Discover. Concrètement :

• Différer tout JS non-critique (defer, async, ou chargement requestIdleCallback).
• Migrer les analytics tiers vers du server-side tagging (Cloudflare Workers, Stape, ou GTM Server-side).
• Throttle les listeners scroll/resize à 100-150 ms.
• Découper les composants lourds (carrousels, comments) en lazy chunks chargés au scroll.

Étape 3 — Préload l'image hero + CDN edge

L'image hero est responsable de ~70 % du LCP sur les articles éditoriaux. Trois actions cumulables :

• <link rel="preload" as="image"> dans le <head> avec fetchpriority="high"
• Servir le WebP en primaire avec JPG fallback
• Pousser l'image sur un CDN edge (Cloudflare Images, Bunny, Cloudinary) pour TTFB d'image sous 50 ms

Étape 4 — Verrouiller les dimensions de toutes les images

CLS = 0,05 max sur Discover top performers. Chaque <img> doit avoir des attributs width et height en valeur intrinsèque — laisse le navigateur réserver l'espace avant le chargement. Idem pour les iframes embeds (YouTube, Twitter) : box avec dimensions imposées via aspect-ratio CSS.

Étape 5 — Self-host les fonts critiques + font-display: swap

Google Fonts via CDN coûte 50-200 ms supplémentaires sur le LCP. Self-host les fonts critiques (woff2) avec preload + crossorigin + font-display: swap. Les fonts non-critiques (italique d'un sous-titre rare) peuvent rester async.

Étape 6 — Auditer le TTFB serveur

Si votre TTFB médian dépasse 400 ms, aucun LCP < 1,6 s n'est tenable. Vérifiez :

• Caching HTML edge (Netlify, Cloudflare full-page cache)
• Database queries en N+1 sur la page article
• Render server-side qui dépasse 200 ms sans cache
• SSL handshake — réutilisation des connexions HTTP/2 ou HTTP/3 obligatoire

4 anti-patterns qui plombent silencieusement vos CWV

• Tag Manager surchargé — GTM avec 30+ tags actifs déclenche typiquement 800-1 200 ms d'exécution JS. Audit régulier mandatory.
• Embeds tiers en blocking — un seul widget Twitter ou Facebook chargé sans async peut détruire l'INP de toute la page.
• Banner cookie cassée — beaucoup de CMP (consent management platforms) injectent du DOM après le LCP, déclenchant un CLS de 0,15+ d'un coup. Choix : delay banner jusqu'au scroll, ou réserver son emplacement en CSS.
• Polyfills universels — chargés pour tous les navigateurs même modernes. Utiliser <script type="module"> + nomodule divise le poids JS par 2 sur Chrome récent.

Vérifier votre performance Discover en 3 minutes

1. Open l'Audit rapide Discover avec votre URL — vous obtenez en 30 s un check des 6 dimensions Discover dont les CWV.
2. Allez sur Search Console → Expérience → Core Web Vitals. Filtrez sur mobile uniquement. Le p75 affiché est exactement ce que Discover voit.
3. Croisez avec PageSpeed Insights en mode « Origin » (pas URL) pour le contexte global de votre domaine.

Conclusion

Les Core Web Vitals officiels donnent le plancher de Search. Discover joue dans une autre catégorie : seuils 30-40 % plus serrés, INP dominant, signaux qui bouclent sur l'engagement et la personnalisation. Si vous voulez exister sur Discover en 2026, mesurer LCP ≤ 2,5 s ne suffit plus — il faut viser le club des top performers, qui tient INP ≤ 120 ms et LCP ≤ 1,6 s en p75.

Bonne nouvelle : la dette technique de performance se rembourse avec un effet de levier. Chaque palier franchi déverrouille une couche supérieure de signaux d'engagement, qui débloquent à leur tour de la personnalisation et de l'autorité thématique. C'est le seul investissement SEO qui compose vraiment dans le temps.

Questions fréquentes