Core Web Vitals measure what a page feels like to a real visitor: how quickly the main content appears, how quickly the page responds to input, and whether the layout stays still. They are part of how Google evaluates page experience, and, more directly, slow or jumpy pages frustrate the people you want to convert.
This guide explains the three metrics, where the numbers come from, why marketing and CMS sites fail them, and how to keep them healthy.
The three metrics
Google assesses each metric at the 75th percentile of page loads, split by mobile and desktop. In other words, a page passes when at least three out of four visits meet the “good” threshold.
Largest Contentful Paint (LCP)
LCP measures loading performance: the time from when the user starts navigating to when the largest image or text block in the viewport is rendered. On most marketing pages that is a hero image, a banner, or a large headline. Good is 2.5 seconds or less.
Interaction to Next Paint (INP)
INP measures responsiveness. It observes the delay between user interactions (clicks, taps and key presses) and the next time the browser paints a visual response, and reports a value close to the worst interaction on the page. INP replaced First Input Delay as a Core Web Vital in March 2024. Good is 200 milliseconds or less.
Cumulative Layout Shift (CLS)
CLS measures visual stability: how much visible content moves unexpectedly while the page is in use. A button that jumps just as someone goes to tap it is the classic example. CLS is a unitless score rather than a time. Good is 0.1 or less.
At a glance
| Metric | What it measures | Good threshold (p75) | Common fixes |
|---|---|---|---|
| LCP | Time until the largest visible content element renders | 2.5 s or less | Optimize and prioritize the hero image, reduce server response time, remove render-blocking CSS and JS |
| INP | Delay between a user interaction and the next visual update | 200 ms or less | Break up long JavaScript tasks, trim third-party scripts, reduce or defer hydration |
| CLS | Unexpected movement of visible content | 0.1 or less | Set image and embed dimensions, reserve space for ads, manage web font swaps |
Field data versus lab data
Different tools report different numbers because they measure different things.
Field data comes from real Chrome users visiting your site. Google collects it in the Chrome User Experience Report (CrUX), which reports over a rolling 28-day window. Field data is what Google uses for its page experience assessment, and it is the number that ultimately counts.
- Search Console has a Core Web Vitals report built on CrUX data. It groups similar URLs and flags which groups need work.
- PageSpeed Insights shows CrUX field data for a URL or the whole origin (when enough traffic exists) at the top of the report, followed by a lab test.
Lab data comes from a single simulated page load in a controlled environment. Lighthouse, available in Chrome DevTools, PageSpeed Insights and the command line, is the standard lab tool. Lab data is repeatable and useful for debugging, but it cannot represent every real device and network. Because a lab test has no real user clicking around, Lighthouse cannot measure INP directly; Total Blocking Time is the usual lab proxy.
A practical rule: use field data to decide what to fix and to confirm that it worked, and use lab data to find out why and to test changes before they ship. Remember that field data lags, so an improvement deployed today takes up to four weeks to be fully reflected in CrUX.
Why marketing and CMS sites fail, and how to fix it
Images
Oversized hero images are a frequent cause of poor LCP, along with lazy-loading the LCP image or loading it through CSS or JavaScript so the browser discovers it late.
- Serve modern formats such as WebP or AVIF, with responsive
srcsetandsizes. - Never lazy-load the above-the-fold hero image. Add
fetchpriority="high"to it instead. - Keep the LCP image in the initial HTML so the browser’s preload scanner can find it.
- Always set
widthandheight(or a CSSaspect-ratio) so the image reserves space, which also protects CLS.
Fonts
Web fonts can delay text rendering (hurting LCP when a headline is the LCP element) and cause layout shifts when the fallback font is swapped for the web font.
- Self-host fonts where practical and preload only the one or two files used above the fold.
- Use
font-display: swaporoptional, and subset fonts to the characters you need. - Tune fallback font metrics with
size-adjustand related descriptors so the swap barely moves the text.
Third-party scripts
Tag managers, analytics, chat widgets, A/B testing tools and marketing pixels accumulate over time, and each adds JavaScript that competes for the main thread, hurting INP.
- Audit tags regularly and remove the ones nobody uses.
- Load non-essential scripts with
deferor after user interaction. - Treat client-side A/B testing scripts carefully, since some hide the page until they finish running.
Render-blocking CSS and JavaScript
Stylesheets and synchronous scripts in the <head> block rendering until they download and run. CMS themes and page builders often ship large bundles for features a given page does not use.
- Inline the critical CSS needed for the first screen and load the rest without blocking.
- Add
deferto scripts that do not need to run before first render. - Remove unused plugins and theme features rather than just hiding them.
Hydration
Sites built with JavaScript frameworks often render HTML on the server and then “hydrate” it in the browser, running large amounts of JavaScript to make the page interactive. During that work, clicks may not respond, which shows up as poor INP.
- Ship less JavaScript: render static content as plain HTML and hydrate only interactive components (the “islands” approach used by frameworks such as Astro).
- Split long tasks so the browser can respond to input between them.
Layout shifts from ads and embeds
Ad slots, cookie banners, video embeds, social widgets and late-loading promotional bars are frequent CLS culprits, because they insert content after the surrounding layout has already rendered.
- Reserve space for ad slots and embeds with fixed dimensions or a minimum height.
- Show cookie banners as overlays rather than pushing content down.
Preventing regressions with performance budgets
Every new plugin, tag, image and feature can undo your work. Make performance a check in your delivery pipeline, not a quarterly clean-up.
- Define budgets. Set limits for lab metrics (such as LCP and Total Blocking Time) and for resource sizes (such as total JavaScript and image weight per page type).
- Run Lighthouse CI on every pull request. Test a representative set of templates, such as the home page, a service page, a blog post and a landing page, and fail the build when an assertion is breached.
- Monitor the field. Collect real-user data with the open-source
web-vitalslibrary or a RUM tool, and watch the Search Console report for new issues. - Govern third-party tags. Require a review before anyone adds a script through the tag manager, with an owner and a removal date.
Keep expectations realistic
Core Web Vitals are one ranking signal among many. Google has been clear that relevant, helpful content matters more, and that a great page experience will not lift weak content to the top of the results. Treat good scores as a baseline for a site that loads quickly and feels solid, not as a shortcut to rankings.
For a detailed example of how an audit, fixes and CI guardrails fit together, see our technical SEO and Core Web Vitals recovery blueprint.
Get help with your Core Web Vitals
Our SEO services team diagnoses field data, prioritizes fixes by impact, and works with developers to ship them, and our web design team builds fast, stable sites from the start. If your Search Console report is showing poor URLs, contact us and we’ll help you work out where to begin.
