Most core web vitals optimization work fails for one reason: teams optimize a Lighthouse score instead of the metric Google actually uses. Lighthouse runs a simulated page load on a throttled connection in a lab. Ranking signals come from the Chrome User Experience Report — real visitors, real devices, real networks — at the 75th percentile over a 28-day window. Those two numbers routinely disagree, and only one of them counts.
Start from the field data, then use lab tools to explain it. That order fixes more than any specific technique.
The Three Metrics and Their Thresholds
Core Web Vitals is currently three metrics, each with a “good” threshold measured at the 75th percentile of field data:
- Largest Contentful Paint (LCP) — 2.5 seconds or less. Time until the largest visible element in the viewport renders.
- Interaction to Next Paint (INP) — 200 milliseconds or less. How quickly the page visually responds to user interactions across the whole visit.
- Cumulative Layout Shift (CLS) — 0.1 or less. How much visible content jumps around unexpectedly.
The 75th percentile matters more than the numbers. It means one visitor in four can have a worse experience than your reported figure and you still pass. It also means your median user’s experience is irrelevant — the metric is deliberately weighted toward your slower quarter, which is usually mid-range Android phones on cellular connections.
One retirement worth noting: First Input Delay was replaced by INP in March 2024 and is no longer a Core Web Vital. Any guide still telling you to optimize FID is working from material that is at least two years stale.
Field Data Versus Lab Data
Field data — CrUX — is what Google uses for the page experience signal. It is aggregated from real Chrome users who have opted in, which creates a practical limitation: a URL without enough traffic has no field data at all. Below the sampling threshold, Google falls back to origin-level data for the whole site, and pages on small sites may show nothing.
Lab data — Lighthouse, PageSpeed Insights’ lab section, WebPageTest — is reproducible and diagnostic. It tells you why something is slow. It cannot tell you whether your users are experiencing it, because it simulates one device on one connection.
Practical rule: field data decides whether you have a problem, lab data tells you what to fix. Chasing a 100 Lighthouse score on a page that already passes in the field is wasted engineering time.
Improving LCP
LCP is usually an image, a heading block, or a hero video. Identify the actual element first — PageSpeed Insights names it — because optimizing the wrong asset is the most common wasted effort here.
Break the metric into its four phases: time to first byte, resource load delay, resource load duration, and element render delay. In my experience the biggest wins come from the first two, not from compressing the image harder.
- Preload the LCP image with
<link rel="preload" fetchpriority="high">so discovery does not wait on CSS or JavaScript - Never lazy-load the LCP element — this single mistake regularly adds a full second
- Serve modern formats (AVIF, WebP) with correctly sized
srcsetvariants - Cut TTFB with caching at the edge; a 600ms server response caps your best possible LCP before a single byte renders
- Inline critical CSS so the render is not blocked on an external stylesheet round trip
Improving INP
INP measures the worst-case interaction responsiveness across a page visit, so it punishes heavy JavaScript in a way FID never did. FID only measured the delay before the first interaction started processing. INP measures input delay, processing time, and the presentation delay until the next paint — the whole loop, for every interaction.
Sites that comfortably passed FID frequently fail INP. That is not a regression; it is a better measurement finally catching what users always felt.
The fixes are about main-thread discipline. Break long tasks into chunks and yield to the main thread between them. Defer non-critical third-party scripts — analytics, chat widgets, A/B testing tools — which are disproportionately responsible for long tasks on real sites. Debounce expensive event handlers, and avoid running layout-thrashing DOM reads and writes inside them. If a click triggers a large re-render, use a lightweight visual acknowledgment first so the paint happens quickly, then do the heavy work.
Improving CLS
CLS is the most fixable of the three and the most often ignored. Almost every shift traces to content that changes size after first paint.
- Set explicit
widthandheightattributes, or a CSSaspect-ratio, on every image, video, and iframe - Reserve space for ad slots, embeds, and cookie banners with a fixed-height container
- Use
font-display: optionalor preload web fonts to avoid a swap that reflows text - Never inject content above existing content after load — push notifications and promo bars belong in reserved space or overlaid, not inserted
A useful discipline: test on a slow connection with the cache disabled. Shifts that are invisible on fast fiber become obvious the moment assets arrive late.
Where to Start When Everything Is Red
Sites that have never done this work usually fail all three metrics at once, and the temptation is to open a fifty-item Lighthouse list and work top to bottom. Do not. Sequence by leverage instead.
- Group URLs by template. Product pages, category pages, blog posts, and the homepage each have their own performance profile. Fixing one template fixes thousands of URLs.
- Rank templates by traffic and revenue. A slow terms-of-service page is not a priority regardless of how bad the number is.
- Fix CLS first. It is usually the cheapest — often a few width and height attributes — and it produces a visible pass quickly, which buys goodwill for the harder work.
- Then LCP, then INP. LCP fixes are well-understood and mostly infrastructural. INP typically requires application changes and is the longest project.
Resist site-wide rewrites. I have watched teams propose a framework migration to fix a 3.1-second LCP that turned out to be one unoptimized 2MB hero image on the homepage template. Measure the specific element before anyone proposes architecture.
How Long Improvements Take to Show
Field data moves on a 28-day trailing window. Ship a fix today and the reported number improves gradually over the following month as old sessions age out — it will not jump. Teams that deploy on Monday and check Search Console on Wednesday conclude nothing worked, then revert a fix that was fine.
Be honest about impact, too. Core Web Vitals is a real ranking signal but a modest one, and it is not going to outrank a competitor with substantially better content and links. Where it pays reliably is conversion: faster pages convert better regardless of what the algorithm does.
Monitoring Without Guesswork
Search Console’s Core Web Vitals report groups URLs by similarity and reports field status, which is fine for triage but slow to update and coarse in its grouping. PageSpeed Insights gives you the per-URL detail, but you have to check pages one at a time.
For ongoing work, put the two data sources side by side. SEO Rocket surfaces PageSpeed and Core Web Vitals with real-user field data next to the lab metrics, so you can tell at a glance whether a Lighthouse warning matches something users are actually experiencing. Combined with full-site crawls that report concrete evidence per issue, it stops the common failure mode: a week spent optimizing a page that was already passing where it counted.
