Core Web Vitals and Discover: the real performance thresholds in 2026

The official doctrine is simple: "hit green on Core Web Vitals and you'll be fine." On paper, sure. On the Discover battlefield, no. Google's "good" threshold (LCP ≤ 2.5 s) is calibrated for the web at large. The articles that actually capture the Discover feed's attention in 2026 live in a much tighter envelope — and penalties cascade, they don't roll up into one score.

This article documents the thresholds actually observed across the 500,000 articles we index. You'll find the Search vs Discover comparison table, the newly dominant role of INP since it replaced FID, the mechanics of the performance demotion pipeline, and a 6-step optimization protocol ranked by impact.

The 3 official Core Web Vitals in 2026 (and where they hide)

Google officially keeps three main metrics since the FID → INP swap in March 2024:

• LCP (Largest Contentful Paint) — render time of the biggest visible element. Measures load perception.
• INP (Interaction to Next Paint) — worst interaction latency on the session, p75. Replaces FID. Measures responsiveness.
• CLS (Cumulative Layout Shift) — weighted sum of unexpected visual shifts. Measures visual stability.

But in practice, Discover also looks at:

• TTFB (Time to First Byte) — proxy for server/edge quality
• FCP (First Contentful Paint) — sub-step of LCP, watched for news pages

The quality demotion pipeline (see Discover's 20+ pipelines architecture) queries a pre-aggregated cache of those 5 values, and it's their combination that decides whether to amplify or demote.

Comparison table: official vs observed Discover thresholds

Source: statistical analysis of the 28-day CrUX p75 window across Discover-eligible domains between January and April 2026.

• LCP — Official "good": ≤ 2.5 s · Discover top performers: ≤ 1.6 s (median). Soft penalty from 2.0 s, hard past 3.0 s.
• INP — Official "good": ≤ 200 ms · Discover top: ≤ 120 ms. Visible demotion starting at 150 ms — stricter than LCP.
• CLS — Official "good": ≤ 0.10 · Discover top: ≤ 0.05. Near-zero tolerance because CLS degrades dwell time, which loops back into the engagement pipeline.
• TTFB — No public official threshold · Discover top: ≤ 400 ms p75. Past 800 ms, holding LCP in the green zone becomes mechanically impossible.
• FCP — Official "good": ≤ 1.8 s · Discover top: ≤ 1.2 s.

Why Discover tightens the screws compared to Search

Three mechanical reasons explain the Search → Discover gap:

1. Mobile is mandatory

Discover only serves mobile. Every user gets a simulated 4G connection + mid-tier CPU in CrUX, making pages more sensitive to heavy JS or miscalibrated images than an equivalent desktop view. The stricter thresholds aren't a quirk — they reflect the real experience of a reader on the subway.

2. The engagement window is shorter

On Search, the user already framed their intent and tolerates a second or two of latency. On Discover, they scroll — your page was competing 200 ms ago with 5 other cards. A 2 s LCP on Discover equals a 4 s LCP on Search in behavioral impact.

3. Engagement signals loop

Bad CWV → short dwell time → engagement pipeline (good user engagement) signals a poor match → personalization pipeline demotes you on that topic → fewer impressions → less data to recover. The downward spiral takes 6 to 10 weeks to reverse.

INP's newly dominant role

Since the FID → INP swap in March 2024, INP has become the most penalizing factor of the CWV trio — about 3.2× more impact than an LCP in the amber zone on our corpus. The reason is structural:

• FID only measured the first interaction — often biased by a single isolated load delay.
• INP looks at every interaction in the session and keeps the p75 — so every tap, scroll, accordion, carousel counts.
• On Discover mobile, the average user runs 14 interactions per article before bouncing. A single slow one wrecks the entire session.

Resources that destroy INP:

• Synchronous third-party analytics scripts (Adobe Launch, Segment, badly-configured GTM)
• Un-throttled scroll and resize listeners
• Carousels with DOM calculations on every slide change
• Modals doing synchronous fetches on open
• Polyfills loaded without nomodule

The performance-demotion pipeline: what actually happens

Discover doesn't measure your CWV in real time. It queries a per-origin cache fed by the Chrome User Experience Report (CrUX), which aggregates real Chrome visits over a 28-day rolling window. Consequences:

• Your optimizations take 4 to 6 weeks to translate into Discover gain — not instantaneous as PageSpeed Insights might suggest.
• Conversely, a regression takes 4 to 6 weeks to be fully penalized — a welcome amortization window after a botched deploy.
• Subdomains count separately in CrUX. If you migrate from a performant subdomain to another, you start from zero.
• Below 1,000 visits/day, your origin has not enough CrUX data to be scored — Discover then applies a "generic" score rather than your real one.

6-step optimization protocol (by decreasing impact)

Step 1 — Audit the 75th percentile, not the median

Default tools (Lighthouse, PageSpeed Insights lab) show a single-shot. CrUX p75 can be very different — especially if your traffic comes from low-end mobile users. Grab the real p75 from Search Console > Experience > Core Web Vitals, or via the CrUX API.

Step 2 — Attack INP before LCP

For equivalent perceived gain, optimizing INP returns 3.2× more in Discover. Concretely:

• Defer all non-critical JS (defer, async, or requestIdleCallback loading).
• Migrate third-party analytics to server-side tagging (Cloudflare Workers, Stape, or GTM Server-side).
• Throttle scroll/resize listeners to 100-150 ms.
• Split heavy components (carousels, comments) into lazy chunks loaded on scroll.

Step 3 — Preload the hero image + edge CDN

The hero image accounts for ~70% of LCP on editorial articles. Three cumulative actions:

• <link rel="preload" as="image"> in <head> with fetchpriority="high"
• Serve WebP as primary with JPG fallback
• Push the image to an edge CDN (Cloudflare Images, Bunny, Cloudinary) for sub-50 ms image TTFB

Step 4 — Lock dimensions on every image

CLS = 0.05 max on Discover top performers. Every <img> needs intrinsic width and height attributes — let the browser reserve space before load. Same for iframe embeds (YouTube, Twitter): box with imposed dimensions via aspect-ratio CSS.

Step 5 — Self-host critical fonts + font-display: swap

Google Fonts over CDN costs 50-200 ms extra on LCP. Self-host critical fonts (woff2) with preload + crossorigin + font-display: swap. Non-critical fonts (italic of a rare subtitle) can stay async.

Step 6 — Audit server TTFB

If your median TTFB exceeds 400 ms, no LCP < 1.6 s is achievable. Check:

• Edge HTML caching (Netlify, Cloudflare full-page cache)
• N+1 database queries on the article page
• Server-side render exceeding 200 ms uncached
• SSL handshake — HTTP/2 or HTTP/3 connection reuse is mandatory

4 anti-patterns that silently wreck your CWV

• Overloaded Tag Manager — GTM with 30+ active tags typically triggers 800-1,200 ms of JS execution. Regular audit mandatory.
• Blocking third-party embeds — a single Twitter or Facebook widget loaded without async can destroy the INP for the whole page.
• Broken cookie banner — many CMPs (consent management platforms) inject DOM after LCP, triggering a 0.15+ CLS in one shot. Options: delay banner until scroll, or reserve its slot in CSS.
• Universal polyfills — loaded for every browser even modern ones. Using <script type="module"> + nomodule halves JS weight on recent Chrome.

Check your Discover performance in 3 minutes

1. Open the Discover Quick Audit with your URL — you get a 30-second check of the 6 Discover dimensions including CWV.
2. Go to Search Console → Experience → Core Web Vitals. Filter on mobile only. The displayed p75 is exactly what Discover sees.
3. Cross-check with PageSpeed Insights in "Origin" mode (not URL) for the global context of your domain.

Conclusion

Official Core Web Vitals set the floor of Search. Discover plays in another league: thresholds 30-40% tighter, dominant INP, signals that loop into engagement and personalization. If you want to exist on Discover in 2026, measuring LCP ≤ 2.5 s no longer cuts it — you need to aim for the top performers' club, which holds INP ≤ 120 ms and LCP ≤ 1.6 s at p75.

Good news: performance tech debt repays with leverage. Each tier you cross unlocks an upper layer of engagement signals, which in turn unlock personalization and topical authority. It's the only SEO investment that genuinely compounds over time.

Frequently asked questions