Core Web Vitals as a compliance signal: how Google measures you and how to score

LCP, INP, CLS — the three metrics that drive page-experience ranking and an increasing share of enterprise vendor questionnaires. Field vs. synthetic, what synthetic catches, and the fixes that move each metric.

Core Web Vitals are Google's page-experience metrics — three numbers that the search algorithm uses as ranking signals and that real users feel as “this site is fast” or “this site is broken.” Performance is not strictly a compliance domain, but in 2026 it functions like one: enterprise vendor questionnaires ask about it, SEO teams treat it as a budget, and a site in the “poor” band loses documented organic traffic.

The three metrics, plainly

Largest Contentful Paint (LCP)

Time from navigation start until the largest visible element finishes rendering. On most pages it's the hero image or the H1. Targets: < 2.5s good, < 4s needs improvement, > 4s poor. Measured at the 75th percentile across real users — synthetic numbers in a Lighthouse run are a sanity check, not the ground truth.

Interaction to Next Paint (INP)

Replaced First Input Delay in March 2024. INP measures the latency of every user interaction across the page's lifetime and reports the highest (worst) one. Targets: < 200ms good, < 500ms needs improvement, > 500ms poor. Long-running JS handlers, expensive React re-renders, and synchronous third-party tag execution are the usual culprits.

Cumulative Layout Shift (CLS)

Visual stability — how much content jumps around as the page loads. Targets: < 0.1 good, < 0.25 needs improvement, > 0.25 poor. Late-loading ads, banners, and webfonts without size hints are the most common shift sources.

How Google actually scores you

The scoring nuance most articles miss:

• Google uses field data, not synthetic tests. The Chrome User Experience Report (CrUX) aggregates real-user metrics across the population of Chrome users with reporting enabled. Your Lighthouse score is a guess at what CrUX will say — they can diverge by 30%+.
• To pass, you need “Good” on all three at the 75th percentile. If LCP is great but INP is mediocre, the page fails page-experience.
• Mobile and desktop are measured separately. Mobile is where most sites fail — slower CPUs, slower networks, and the same JS payload.

The fixes that consistently move the needle

For LCP

1. Preload the LCP element. If it's a hero image, add <link rel="preload" as="image" ...> in the head and fetchpriority="high" on the img.
2. Serve appropriately-sized images. A 2400×1600 hero shipped to a mobile viewport wastes bandwidth and decode time. Use srcset or a CDN with on-the-fly resizing.
3. Defer non-critical JS. Analytics tags, social widgets, and marketing SDKs should all carry defer or be loaded after user interaction.
4. Eliminate render-blocking CSS that isn't needed for above-the-fold content. Critical CSS inlined in the head, the rest loaded async.

For INP

1. Audit your largest event handlers. Profile a representative interaction in DevTools Performance panel — anything over 50ms is a candidate.
2. Break up long tasks. requestIdleCallback, scheduler.yield(), or simple setTimeout(0) chunks can split a 400ms handler into 4 × 100ms.
3. Lazy-load third-party SDKs. Intercom, Drift, Zendesk — none of them need to load before user interaction. Defer until idle or until the user hovers their launcher.
4. Use content-visibility: auto on long lists. Off-screen DOM stops costing render time.

For CLS

1. Set explicit width and height on every image and video. The browser reserves the space; nothing shifts when the asset loads.
2. Reserve banner / ad space with min-height in CSS rather than letting it inject post-load.
3. Use font-display: optional or font-display: swap with a size-matched fallback. Webfont swap is one of the most common CLS sources.
4. Avoid dynamically injected content above existing content. New banners, cookie notices, and promo bars should reserve space or push from the bottom.

What synthetic measurement does and doesn't catch

Plumb measures Core Web Vitals synthetically with a headless Chromium run — fast, repeatable, and good for catching regressions before they ship. But synthetic metrics can't replicate:

• Real user device variance (a 2019 Android with 3GB RAM vs. a 2024 flagship).
• Real network variance (4G in a basement vs. campus wifi).
• User-driven interactions and long-session INP that only materializes after minutes of use.

Use Plumb to keep the synthetic numbers honest sprint-over-sprint, and watch the CrUX field data in Search Console for the ground-truth picture on a 28-day rolling basis. Synthetic catches regressions in days; field catches them in weeks. Both are necessary.