Core Web Vitals are Google's field measurements of how a page feels to real users: how fast the main content shows up, how quickly the page responds to input, and how stable the layout is while it loads. They are a ranking signal, but more importantly they are a user-experience signal. Slow, jumpy pages lose visitors before your content has a chance.
This guide covers what each metric measures, the thresholds that count as "good", and the fixes that usually help most.
The three metrics and their thresholds
- LCP (Largest Contentful Paint): What it measures: Time until the largest visible element renders; Good: ≤ 2.5 s; Poor: > 4.0 s
- INP (Interaction to Next Paint): What it measures: Delay between a user action and the next visual update; Good: ≤ 200 ms; Poor: > 500 ms
- CLS (Cumulative Layout Shift): What it measures: How much visible content moves unexpectedly; Good: ≤ 0.1; Poor: > 0.25
Google assesses these at the 75th percentile of real visits, separately for mobile and desktop. A page passes when all three are "good" at that percentile.
Field data vs. lab data
Lab tools such as Lighthouse run a single simulated load. They are great for debugging, but they are not what Google uses. Field data comes from real Chrome users (the Chrome UX Report) and is what appears in Search Console's Core Web Vitals report.
Use lab data to find causes. Use field data to confirm you fixed them. Expect field numbers to take around four weeks to fully reflect a change, because they are a rolling 28-day window.
Fixing LCP
LCP is usually a hero image, a large heading, or a video poster. The fixes depend on which part of the load is slow:
- Slow server response. Cache HTML at the edge, reduce server work on first request, and avoid redirect chains.
- Late discovery of the LCP resource. If the hero image is set in CSS or injected by JavaScript, the browser finds it late. Put it in the HTML as an <img> and add fetchpriority="high".
- Heavy images. Serve modern formats (AVIF or WebP), size them for the viewport with srcset, and never lazy-load the LCP image.
- Render-blocking CSS and fonts. Inline critical CSS, defer the rest, and use font-display: swap or optional.
Fixing INP
INP replaced First Input Delay in 2024 and is the metric most sites now struggle with. It looks at all interactions during a visit, not just the first, and reports one of the slowest.
Common causes and fixes:
- Long JavaScript tasks. Break work into smaller chunks and yield to the main thread between them, for example with scheduler.yield() or setTimeout.
- Too much third-party script. Audit tag managers, chat widgets, and analytics. Load non-essential scripts after the page is interactive, or remove them.
- Expensive re-renders. In frameworks like React, avoid re-rendering large trees on every keystroke. Debounce input handlers and memoize heavy components.
- Large DOM size. Very large pages make every style and layout calculation slower. Paginate or virtualize long lists.
A helpful habit: give immediate visual feedback (a pressed state, a spinner) before doing the heavy work. The next paint happens sooner, and the interaction feels faster.
Fixing CLS
Layout shift is almost always caused by content that arrives without reserved space:
- Set width and height (or aspect-ratio) on images, videos, and iframes.
- Reserve space for ads, embeds, and cookie banners instead of pushing content down when they load.
- Avoid inserting banners above existing content after load.
- Preload key web fonts and use size-adjusted fallbacks so text does not reflow when the font swaps.
How to prioritize
You rarely need to fix every page individually. Core Web Vitals problems usually come from templates. Group URLs by template (product page, blog post, category page), find the template that fails on the most traffic, and fix it once.
A simple order of operations:
1. Open the Core Web Vitals report in Search Console and note which URL groups fail on mobile. 2. Pick the group with the most traffic. 3. Run Lighthouse or WebPageTest on two or three example URLs to find the cause. 4. Ship the template fix, then watch field data over the next 28 days.
Where this fits in your SEO work
Core Web Vitals will not rescue thin content, and great content will not fully overcome a painfully slow site. Treat them as part of your overall Site Health, and measure the result the same way you would any change: with before-and-after attribution, not guesswork.
SearchVoro monitors Core Web Vitals alongside crawl health, groups failing URLs by template, and links each fix to its impact on traffic, so you can see which performance work actually paid off.
About this byline
“SearchVoro Team” identifies collaborative product and engineering material, not an invented individual author. Named contributor and reviewer profiles will be added only with the person's approval.