Core Web Vitals

Core Web Vitals (CWV) are Google's three user-experience metrics, measured from real Chrome users. Google says they are used by its ranking systems, and also that it still shows the most relevant content even when its page experience is weaker. In practice (this is opinion, shared by most SEOs) they act as a tiebreaker rather than a dominant factor. They matter anyway, because they measure something that does dominate: whether users stay or leave.

The three metrics#

Thresholds are evaluated at the 75th percentile of real users, separately for mobile and desktop. Your fast dev machine on fibre is not the measurement.

These numbers have not changed: web.dev/vitals still lists the same three stable metrics and thresholds as of October 2026. INP replaced FID in March 2024, and FID is now gone from the tooling (web-vitals.js v5, May 2025, removed onFID()). If a blog announces a "2026 Core Web Vitals update" with new thresholds or TTFB as a vital, it is not backed by Google or Chrome documentation.

Field data vs. lab data#

• Field data comes from the Chrome User Experience Report (CrUX): real-user telemetry over a rolling 28-day window. It is what Google uses. Where to see it in 2026:

  • Search Console → Core Web Vitals: URL groups that pass or fail, per device.
  • PageSpeed Insights: field data for the URL and origin, above the lab run.
  • CrUX Vis and the CrUX History API: weekly trends at origin and URL level.
  • CrUX on BigQuery: monthly origin-level data for custom analysis.

  The old Looker Studio CrUX Dashboard is gone: its connector was shut down at the end of November 2025, and Google points to CrUX Vis instead.

• Lab data (Lighthouse, DevTools Performance panel) is reproducible diagnostics. Use it to find causes, never to declare victory.

npx lighthouse https://example.com --only-categories=performance --view

Lighthouse now speaks in "insights"#

Lighthouse 12.7 (June 2025) made performance insights the default view, and Lighthouse 13 (October 2025) removed the legacy audits. The insights match the DevTools Performance panel:

The performance score itself did not change. Update any audit template that still names the old checks.

Fixing LCP#

LCP is almost always the hero image or headline block. The LCP breakdown insight splits it into four parts: time to first byte, resource load delay, resource load duration and element render delay. Fix the biggest part first:

1. Slow server response (TTFB). Cache HTML at the edge; in Next.js prefer static rendering or ISR for content pages over per-request rendering.
2. The LCP image isn't prioritized. It must be in the initial HTML and fetched early:

import Image from "next/image";
 
<Image
  src="/hero.webp"
  alt="…"
  width={1200}
  height={630}
  loading="eager"
  fetchPriority="high"
/>

Next.js 16 deprecated the old priority prop in favour of preload; its docs recommend loading="eager" or fetchPriority="high" in most cases.

3. Render-blocking CSS and fonts. Inline critical CSS (frameworks do this) and self-host fonts with font-display: swap (next/font handles both and removes the third-party request).
4. Too much image. Serve responsive sizes and modern formats: again, next/image defaults.

Fixing INP#

INP captures slow interactions, usually long JavaScript tasks blocking the main thread:

• Ship less JS. Audit bundles (@next/bundle-analyzer), use dynamic import() for below-the-fold and on-interaction components, and prefer Server Components for non-interactive UI.
• Break up long tasks. Yield to the main thread in heavy handlers (await scheduler.yield() where supported, with a setTimeout fallback) and move pure computation to a Web Worker.
• Tame third-party scripts. Tag managers, chat widgets and analytics are routinely the worst offenders. Load them with next/script strategy="lazyOnload" or remove them.
• Render less per interaction. Virtualize long lists and memoize expensive React subtrees so a keystroke doesn't re-render the world.

Fixing CLS#

Layout shift is a reserved-space failure:

• Images, video and embeds: always declare dimensions (width/height or CSS aspect-ratio).
• Ads and dynamic slots: reserve a fixed container before the content loads.
• Fonts: font-display: swap plus metric-compatible fallbacks (next/font generates the fallback metrics) to stop reflow when web fonts arrive.
• Never insert content above existing content after load. Banners and notices should use a reserved slot or an overlay.

Single-page apps and soft navigations#

CrUX only measures hard navigations (full page loads). In a client-routed app, every route change after the first is a "soft navigation" that CrUX does not record, so its LCP and CLS don't count for the new URL. Chrome ran a final origin trial of the Soft Navigations API in Chrome 147 to 149 (announced 2026-04-20), and Google said the trial evaluates the API, "not how this data will be used in CrUX or tooling". As of October 2026 there is no announced CrUX or Search Console change. You can measure per-route vitals in your own real-user monitoring; ranking data is unchanged. More in JavaScript SEO.

A realistic workflow#

1. Search Console → Core Web Vitals  → which URL groups fail, on which metric, which device
2. PageSpeed Insights on a failing URL → field numbers + Lighthouse insights
3. CrUX Vis                            → is the trend getting worse or better?
4. Fix per the playbooks above         → verify in the lab immediately
5. Wait for field data to roll over    → ~28 days, then "Validate fix" in Search Console

Mobile and desktop are reported separately, and mobile usually fails first: see Mobile-First Indexing. Performance work is permanent: add a Lighthouse CI budget to your pipeline so regressions fail the build instead of failing the quarter.

Next: Structured Data, telling machines exactly what your content is.