Anticode Open builder

Core Web Vitals explained: reading the report and fixing the usual causes

Core Web Vitals are three measurements of how a page feels to real visitors: how fast the main content appears (LCP), how quickly the page responds to a tap or key press (INP) and how much the layout jumps while loading (CLS). Good means LCP within 2.5 seconds, INP within 200 milliseconds and CLS of 0.1 or less, for at least three in four visits.

Updated · By the Anticode team

The three metrics

Core Web Vitals and their thresholds
MetricMeasuresGoodPoor
Largest Contentful Paint (LCP)Time until the biggest image or text block in view has rendered2.5 s or lessOver 4 s
Interaction to Next Paint (INP)Delay between a click, tap or key press and the next frame drawn200 ms or lessOver 500 ms
Cumulative Layout Shift (CLS)How much visible content moves unexpectedly0.1 or lessOver 0.25

That table is Core Web Vitals explained in brief; the detail is in how each number is gathered. The thresholds come from web.dev's Core Web Vitals overview and are judged at the 75th percentile, separately for phones and desktops. INP replaced First Input Delay in 2024; older articles that talk about FID are out of date. Google uses these signals as part of page experience in search, but relevance still matters far more: a fast page that doesn't answer the query won't outrank a slower one that does.

Field data and lab data

Field data
Collected from real Chrome users over the previous 28 days (the Chrome UX Report). This is what Search Console's Core Web Vitals report and the top of PageSpeed Insights show, and what counts.
Lab data
A single simulated load, usually on a throttled phone profile, from Lighthouse or DevTools. Repeatable and good for debugging, but it can't measure INP, since nobody interacts; it reports Total Blocking Time as a stand-in.

A small site often sees "Not enough data" in Search Console. That simply means too few Chrome visitors for a report. Use PageSpeed Insights' lab results and DevTools instead until traffic grows.

Reading a report, step by step

  1. Run PageSpeed Insights on your most visited page, on the Mobile tab first, since phones are slower.
  2. Check the top section. If it shows field data, note which metric fails. If not, scroll to the lab results.
  3. Find the LCP element. Under Diagnostics, the report names the element measured. On most small sites it's the hero image or headline.
  4. Look at the LCP breakdown into time to first byte, load delay, load time and render delay. The biggest slice tells you where to work.
  5. For CLS, open "Avoid large layout shifts" to see which elements moved.
  6. Fix one thing, then re-run. Lab scores vary a few points between runs, so look for clear changes, not single digits.

The usual causes and fixes

Slow LCP

  • An oversized hero image. Resize and compress it; optimising images covers target sizes. This alone fixes most small sites.
  • The hero image is lazy-loaded or set as a CSS background. The browser discovers it late. Use a normal <img> without loading="lazy" for the first image in view.
  • A slow server or many redirects before the page arrives. Static hosting behind a CDN usually answers quickly; redirect chains add a round trip each.
  • Render-blocking scripts or large CSS in the head.

Poor INP

  • Heavy JavaScript on the main thread: chat widgets, analytics bundles, sliders, consent tools. Remove what you don't need and defer the rest.
  • Long event handlers that do a lot of work before updating the screen. Break them up so the page can paint in between.

High CLS

  • Images without width and height, so space isn't reserved before they load.
  • Banners, cookie bars or embeds inserted above content after the page renders.
  • Web fonts that swap in at a different size from the fallback. One family with a close fallback limits the jump.

How Anticode pages fare

Pages from Anticode's design engine are plain HTML and CSS with no scripts at all and one font family per site, which removes the commonest causes of poor INP and much of the font-related layout shift. They don't remove the biggest LCP risk on small sites: a heavy photo. If you put your own hosted image in a CMS image field (it shows with that collection's entries, not in the hero), or upload photos for an app build (they're stored as uploaded, without resizing), resize them first. App builds are different: they run JavaScript the model wrote, inside a frame on the published page, so test the interactions that matter in DevTools and on a real phone. Anticode doesn't show Core Web Vitals in its own dashboard, so use PageSpeed Insights or Search Console.

Limits of the numbers

Core Web Vitals measure loading, responsiveness and stability, not whether a page is clear, accessible or useful. A perfect score on a confusing page is still a confusing page. Treat "good" on all three as the goal and then stop optimising; work on content and mobile testing usually pays off more after that.

Questions people ask

Do Core Web Vitals affect Google rankings?

They're part of the page experience signals Google uses, but they weigh less than relevance and content quality. Fix failing metrics, then focus on the page itself.

Why is my Lighthouse score different every time?

Lab tests depend on network and CPU conditions at that moment. Run it a few times and compare medians, or rely on field data when it's available.

My page has no interactions. What's its INP?

A visit with no clicks, taps or key presses reports no INP at all. Pages with nothing to interact with rarely have INP problems.

Sources

  1. Web Vitals (web.dev), checked
  2. Optimize Largest Contentful Paint (web.dev), checked
  3. Interaction to Next Paint (web.dev), checked
  4. Cumulative Layout Shift (web.dev), checked
  5. PageSpeed Insights, checked