Core Web Vitals are Google’s three measurements of how a page feels to a real visitor: how quickly the main content appears (Largest Contentful Paint), how quickly the page responds to input (Interaction to Next Paint), and how much the layout jumps while loading (Cumulative Layout Shift). A page passes when at least 75% of real visits score “good” on all three. Most failing pages fail for a handful of ordinary, fixable reasons.
Key takeaways
- Good scores: LCP at or under 2.5 seconds, INP at or under 200 milliseconds, CLS at or under 0.1.
- Google judges the 75th percentile of real visits, so fix the experience on mid-range phones, not on your laptop.
- LCP problems are usually one image or one font. INP problems are usually long JavaScript tasks. CLS problems are usually missing dimensions.
- Field data updates over a rolling 28-day window, so improvements take up to four weeks to show in Search Console.
What are the Core Web Vitals thresholds?
Each metric has three bands. For Largest Contentful Paint, 2.5 seconds or less is good and anything over 4 seconds is poor. For Interaction to Next Paint, 200 milliseconds or less is good and over 500 milliseconds is poor. For Cumulative Layout Shift, 0.1 or less is good and over 0.25 is poor. A URL only “passes” when all three are in the good band at the 75th percentile of visits.
Where should you measure Core Web Vitals?
Use field data first. Field data comes from real Chrome users and is what Google uses; lab data is a single simulated load, useful for debugging but not for judging. The practical toolkit:
- Search Console’s Core Web Vitals report: which groups of URLs pass or fail, from real visits.
- PageSpeed Insights: field data for one URL (when there is enough traffic) plus a lab run with diagnostics.
- Chrome DevTools Performance panel: a trace that shows exactly which element is the LCP and which tasks block input.
- The open-source web-vitals library: send real measurements from your own visitors to your analytics.
How do you fix Largest Contentful Paint?
First find the LCP element: in most pages it is the hero image, a large heading, or a background image. LCP time breaks into four parts: time to first byte, the delay before the browser starts loading the resource, the time to download it, and the delay before it is rendered. Measure which part is largest, then work on that part.
- Serve the LCP image in AVIF or WebP, at the size it is actually displayed, with a responsive srcset.
- Never lazy-load the LCP image. Give it fetchpriority="high" so the browser requests it early.
- Make sure the image is discoverable in the HTML, not injected later by JavaScript or hidden in a CSS background.
- Use font-display: swap with a size-matched fallback font, so headline text is visible before the web font arrives.
- Reduce time to first byte with static generation or caching at a CDN close to your visitors.
- Do not hide the hero behind a JavaScript entrance animation: an element that starts invisible cannot be painted.
How do you fix Interaction to Next Paint?
INP measures the slowest typical interaction across the whole visit: a tap, a click or a key press, until the screen visibly updates. It is made of input delay (the main thread is busy), processing time (your event handler runs) and presentation delay (the browser lays out and paints). Any task over 50 milliseconds on the main thread is a “long task” and a likely cause.
- Break long tasks up and yield back to the browser between chunks of work.
- Load chat widgets, heatmaps and tag-manager extras after the page is interactive, not before.
- Reduce the amount of JavaScript that hydrates on load; render static sections as plain HTML.
- Debounce expensive handlers such as search-as-you-type instead of running them on every keystroke.
- Avoid forcing layout inside handlers, for example reading element sizes immediately after changing styles.
How do you fix Cumulative Layout Shift?
CLS is usually the cheapest metric to fix. Content moves when something appears without space reserved for it, or when a late-loading font changes the size of text.
- Give every image and video width and height attributes, or an aspect-ratio in CSS.
- Reserve space for embeds, ad slots and cookie banners before they load.
- Never insert content above existing content, unless it is in response to a user action.
- Animate with transform and opacity, which do not move surrounding elements.
- Use fallback fonts with matching metrics so the swap to the web font does not reflow text.
If an element can appear after first paint, it needs its space reserved before it does.
A checklist to work through, in order
- 1. Open Search Console and list the URL groups failing each metric.
- 2. For each failing template, run PageSpeed Insights and a DevTools trace on a throttled mobile profile.
- 3. Fix LCP: identify the element, then image format, size, priority and discoverability.
- 4. Fix CLS: add dimensions, reserve space, check font fallbacks.
- 5. Fix INP: find long tasks, defer third-party scripts, cut hydration.
- 6. Add a performance budget to your deployment pipeline so regressions are caught before release.
- 7. Wait for the 28-day field window, then confirm in Search Console with “Validate fix”.
How long until Google sees the improvement?
Lab scores change immediately, but Google’s field data is a rolling 28-day window of real visits. Expect Search Console to reflect a fix gradually over about four weeks. Low-traffic pages may not have enough field data at all; in that case Google groups them with similar pages, so fixing the shared template fixes them together.
Speed is one ranking signal among many, so passing Core Web Vitals will not lift a page on its own. It does remove a reason to lose to a competitor of similar relevance, and it measurably reduces the number of visitors who leave before the page has finished loading.