Core Web Vitals are three measurements Google uses to judge how a page actually feels to a real visitor: how fast the main content shows up, how quickly the page responds when someone interacts with it, and whether the layout jumps around while loading. They are Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift.
Google evaluates these using real visitor data, not a lab test, at the 75th percentile. That means the score reflects what most of your actual visitors experience, on their actual devices and connections, not a best-case run on a fast office computer.
Largest Contentful Paint (LCP)
LCP measures how long it takes for the largest visible element, usually a hero image, a heading, or a large block of text, to fully render after a visitor requests the page. A good score is under 2.5 seconds.
What usually causes a slow LCP
- A large hero image that is not compressed or sized correctly for the device.
- Render-blocking CSS or JavaScript that delays the browser from painting content.
- Slow server response time, often from an overloaded host, unoptimized database queries, or no caching layer.
- Fonts that block text from rendering until they finish loading.
How to fix it
- Compress and correctly size images, and serve modern formats like WebP or AVIF.
- Preload the specific hero image or font that renders the largest element, so the browser fetches it earlier.
- Reduce or defer render-blocking CSS and JavaScript that is not needed for the first paint.
- Improve server response time with caching, a faster host, or a content delivery network for static assets.
Interaction to Next Paint (INP)
INP measures how long the page takes to visibly respond after a visitor clicks, taps or types. A good score is under 200 milliseconds. INP replaced an older metric called First Input Delay because it measures responsiveness across the entire visit, not just the first interaction.
What usually causes a slow INP
- Heavy JavaScript execution that blocks the browser's main thread when a user interacts.
- Large third-party scripts, ad tags, chat widgets, analytics trackers, running expensive code on every interaction.
- Poorly optimized event handlers doing more work than the interaction actually needs.
- Large DOM size, where the browser has to check thousands of elements to update the page.
How to fix it
- Break up long JavaScript tasks so the browser can respond to input between chunks of work instead of finishing one long task first.
- Audit third-party scripts and remove or defer anything not essential to the experience.
- Debounce or simplify expensive event handlers, especially on scroll and input events.
- Reduce unnecessary DOM complexity, particularly on pages with large lists or grids.
Cumulative Layout Shift (CLS)
CLS measures how much visible content shifts position unexpectedly while a page loads or while a visitor is using it. A good score is under 0.1. This is the metric behind the frustrating experience of trying to tap a button and having an ad or image push it down at the last second.
What usually causes a high CLS
- Images and video embeds with no reserved width and height, so the page reflows once they load.
- Ads or embeds injected into the page after the surrounding content has already rendered.
- Web fonts that swap in and change text size or spacing after the page has already painted.
- Content, banners, and cookie notices inserted above existing content instead of in reserved space.
How to fix it
- Always set explicit width and height (or aspect ratio) on images and video, so the browser reserves the correct space before the file loads.
- Reserve space for ads and embeds in advance rather than letting them push content when they load.
- Use font loading strategies that avoid a visible size or spacing jump when the web font replaces the fallback.
- Place dynamic UI like cookie banners and notifications so they do not shift existing content when they appear.
Field data versus lab data
One source of confusion is seeing different numbers in different tools. Field data, sometimes called real user data, comes from actual visitors over the past 28 days and is what Google uses to judge your site for ranking purposes. Lab data comes from a simulated test run on a single device and connection profile, useful for diagnosing a specific problem but not what determines your official pass or fail status.
A page can pass in a lab test and still fail in the field, usually because the lab test ran on a fast connection that does not represent your actual visitor base. Always treat field data as the source of truth, and use lab tools to investigate why the field data looks the way it does.
Why this matters beyond the score itself
Core Web Vitals are a ranking signal, but the bigger effect is direct: a page that loads fast, responds immediately, and does not jump around keeps visitors instead of losing them to a competitor's tab. The technical fix and the user experience fix are the same fix here, which is unusual in SEO and worth taking seriously on its own merits, not just for the ranking effect.
How to check your current scores
| Tool | What it shows |
|---|---|
| Google Search Console | Real visitor field data across your whole site, grouped by URL group, the same data Google uses to evaluate you. |
| PageSpeed Insights | Field data where available, plus a lab test that pinpoints specific causes on a single page. |
| Chrome DevTools | Detailed lab diagnostics during development, useful for finding the exact script or element causing an issue. |
A note on frameworks and page builders
The platform behind a site changes how hard each fix is, not whether it applies. A heavily plugin-driven WordPress site often struggles most with INP, since every added plugin can register its own scripts that compete for the main thread. A modern React or Next.js build gives you more direct control over code splitting and script loading, but only if it is architected with performance in mind from the start, since a poorly built single-page app can produce worse INP than a simple static site.
Where to start if all three are failing
Fix LCP first, since it is usually the most visible to visitors and often shares root causes, like server response time and heavy assets, with the other two. Then move to CLS, which is typically the fastest to fix once you find the specific unreserved element. INP is often the most involved, since it usually means auditing JavaScript execution and third-party scripts rather than a single quick change.
If your site is built on an older stack, a lot of these fixes come down to how the frontend was architected in the first place, not a patch you can bolt on. Our Next.js and React team builds with these metrics in mind from the first commit, rather than retrofitting them later. And since Core Web Vitals sit inside your broader ranking picture, our SEO team can tell you honestly whether performance is actually what is holding your rankings back, or whether the real issue lives elsewhere.
