By Mehdi HassanWhat are Core Web Vitals?
Core Web Vitals are three metrics Google uses to measure how a page feels to real visitors: how quickly the main content appears, how quickly the page responds when someone taps or clicks, and whether the layout jumps around while loading. Google collects them from Chrome users and reports them in Search Console and PageSpeed Insights.
For a founder or marketer, the business translation is simple. LCP is the wait before your hero message is readable. INP is the lag between clicking Book a demo and something happening. CLS is the button that moves just as someone tries to tap it. All three are about whether your site feels trustworthy and quick, and all three are measured on your actual visitors' devices, not on a developer's fast laptop.
This guide explains each metric in plain terms, gives a realistic view of their effect on rankings, and links to the detailed fixes. It's written for people who commission or own a website rather than people who debug JavaScript all day, though the linked guides go deep enough for developers.
What do LCP, INP and CLS measure?
Each metric measures one part of the experience, and each has a published threshold for good, needs improvement and poor. Google's documented thresholds, assessed at the 75th percentile of page visits, are below.
Metric | What it measures | Good | Poor | Business symptom when it fails |
|---|---|---|---|---|
Largest Contentful Paint (LCP) | Time until the largest visible element, usually the hero, renders | 2.5s or less | Over 4s | Visitors bounce before reading the headline |
Interaction to Next Paint (INP) | Delay between a tap, click or key press and the next visual update | 200ms or less | Over 500ms | Menus, tabs and forms feel broken or laggy |
Cumulative Layout Shift (CLS) | How much visible content unexpectedly moves | 0.1 or less | Over 0.25 | Mis-taps, lost reading position, a cheap feel |
The 75th percentile part matters. A page passes only if at least three out of four visits meet the threshold, so a fast experience for you on office Wi-Fi doesn't count if a quarter of your visitors are on mid-range phones. INP replaced First Input Delay as the responsiveness metric in March 2024, and it's a much stricter test because it looks at interactions throughout the visit, not just the first one.
Largest Contentful Paint in practice
On marketing sites, the LCP element is almost always the hero image, a hero video poster or the main headline. Slow LCP usually comes from a slow server response, a hero image that's too large or discovered late, render-blocking fonts or scripts, or content that only appears after JavaScript runs. Our guide on how to improve LCP on a marketing website focuses on those hero-specific fixes.
Interaction to Next Paint in practice
INP fails when the browser's main thread is busy at the moment someone interacts. Third-party tags, chat widgets, heavy animation libraries and large JavaScript bundles that hydrate the whole page are the common culprits. We cover the full playbook in how to fix INP.
Cumulative Layout Shift in practice
CLS comes from things that arrive late and push content around: images without reserved dimensions, cookie banners inserted at the top, web fonts that swap with different metrics, and embeds that resize. It's usually the easiest of the three to fix, and web font performance is a frequent part of that work.
Do Core Web Vitals affect Google rankings?
Yes, but less than many vendors suggest. Google has confirmed that Core Web Vitals are part of its page experience signals used in ranking, and it has also said clearly that relevance and content quality come first. A slow page with the best answer can still outrank a fast page with a weak one.
The realistic way to think about it is as a tiebreaker and a floor. When several pages are similarly relevant, a better experience can help. When a page is badly failing, especially on mobile, it gives competitors an edge. What vitals won't do is rescue thin content or move a page from page three to page one on their own. Treat any promise of big ranking jumps from performance work alone with suspicion.
There's also a newer reason to care: AI search tools and crawlers fetch your pages too. Pages that render their content in the initial HTML and respond quickly are easier for every kind of crawler to read. That's less about the vitals scores and more about the same build quality that produces good vitals.
How do you check your Core Web Vitals?
Check your Core Web Vitals with field data first: the Core Web Vitals report in Google Search Console and the real-user section at the top of PageSpeed Insights. Both use data from the Chrome UX Report, collected over a rolling 28-day window from real visitors.
Open Search Console's Core Web Vitals report
It groups your URLs into good, needs improvement and poor, separately for mobile and desktop, and names the failing metric for each group.
Check key pages in PageSpeed Insights
Run your homepage, pricing page and top landing pages. Read the field data panel at the top before the lab score below it.
Note which metric fails and on which device
Mobile INP and mobile LCP are the most common failures. The failing metric tells you which kind of fix you need.
Use lab tools to diagnose, not to grade
Lighthouse and the browser's performance panel show why a page is slow. Use them to find causes, then confirm the fix in field data.
Wait for the window to roll
After a fix ships, field data takes up to 28 days to fully reflect it. Search Console's validation flow tracks this.
The most common confusion we hear is a founder worried about a Lighthouse score of 60 when the site passes all three vitals in the field, or the reverse. Our guide to the PageSpeed Insights score vs real-user data explains why the two disagree and which one to act on. Small sites may have no field data at all, because there isn't enough Chrome traffic; in that case, lab tools are the best signal you have.
Why do so many sites fail INP?
Many sites fail INP because modern marketing sites run a lot of JavaScript that has nothing to do with the page's content: analytics, tag managers, chat, heatmaps, consent tools, A/B testing and animation libraries. Each one competes for the main thread, and any interaction that lands while it's busy has to wait.
Frameworks aren't immune. Field data reported by corewebvitals.io for the second quarter of 2026 shows only about two-thirds of Next.js sites passing INP, with a median of roughly 236ms, above the 200ms threshold. The cause is rarely the framework itself; it's what gets loaded on top of it and how much of the page hydrates as interactive JavaScript.
- Audit your tags. Our method for auditing third-party scripts that slow your site shows how to find which tags cost the most and which ones nobody uses.
- Delay non-essential widgets. Chat and video can load when someone clicks, not on page load.
- Keep interactive code small. Only the parts of a page that need interaction should ship JavaScript.
- Break up long tasks. Heavy work should yield to the browser so interactions get handled quickly.
How do you fix Core Web Vitals on Framer, Webflow and Next.js?
You fix Core Web Vitals differently on each platform, because each gives you different controls. Builders limit what you can change but handle much of the basics for you; coded sites give you full control and full responsibility.
Platform | What you control | Common failure | First fix to try |
|---|---|---|---|
Framer | Images, fonts, animation choices, custom code embeds | Heavy scroll animation and embeds hurting INP | Simplify animations and remove unused embeds |
Webflow | Images, interactions, custom code, page structure | Large interactions and many third-party scripts | Trim interactions and move scripts to load late |
Next.js | Everything, from rendering to hydration | Dynamic pages and over-hydrated client components | Make pages static and shrink client components |
WordPress | Theme, plugins, hosting, caching | Plugin bloat and slow hosting | Remove plugins and add proper caching |
Our guide to Core Web Vitals for Framer, Webflow and Next.js sites goes through the platform-specific fixes in detail. If heavy media is the issue, image and video optimization for fast marketing sites covers formats, sizing and video posters across all platforms.
Hypothetical example: reading a vitals report for a startup homepage
For example, suppose a startup's homepage shows good CLS, LCP at 3.1 seconds on mobile and INP at 320ms on mobile in its field data, while desktop passes everything.
The LCP number points to the hero: likely a large image or video discovered late, or a slow server response. The INP number points to scripts and hydration: likely a chat widget, tag manager and an animation library all running early. Desktop passing tells you the problem is weight and main-thread work that faster machines hide. The plan would be to fix the hero first, since it's usually quicker, then audit scripts, then re-check field data after the 28-day window rolls.
What does good Core Web Vitals work cost?
Core Web Vitals work ranges from a few hours of fixes to a full rebuild, depending on whether the problems are in content, configuration or architecture. Removing a heavy tag or resizing a hero image is cheap. Fixing a site that renders everything in the browser is a rebuild.
- Content and asset fixes: image sizes, video posters, font weights. Usually the quickest and cheapest tier.
- Script and tag cleanup: auditing and removing or delaying third-party code. Needs marketing sign-off more than engineering time.
- Template and component fixes: reserving space, reducing animation, splitting interactive components.
- Architecture changes: moving from client rendering to static or server rendering, or changing platform.
Our guide to website speed optimization services explains how to scope this kind of project around field-data targets rather than lab scores, and what typically drives the price. The best long-term protection is a website performance budget, so every new script, image and section has to fit within agreed limits before it ships.
How do you keep Core Web Vitals good after launch?
Keep Core Web Vitals good by treating performance as a rule for every change, not a one-time project. Most sites launch fast and get slower as campaigns add tags, sections and embeds.
Set a budget
Agree limits for page weight, number of third-party scripts and the three vitals, and write them down where marketing and developers can see them.
Build performance into components
Hero, image, video and embed components should handle sizing, priority and lazy loading by default, so editors can't get it wrong.
Review every new tag
Before adding a script, ask what it costs, who owns it and when it can be removed.
Check field data monthly
Look at Search Console's report on a schedule, not only when something feels slow.
Fix regressions quickly
When a page slips into needs improvement, trace it to the change that caused it while it's still fresh.
Design decisions matter as much as code. Accessible, well-structured pages tend to be lighter and steadier; see accessible design basics. A component library built for editors, as in page builder blocks marketers can use, stops performance mistakes at the source. And landing pages, which carry paid traffic, deserve extra care: fast landing pages shows how to keep good vitals without a plain design.
Which Core Web Vitals guides should you read next?
Read next based on the metric you fail or the decision you face. The guides below go deeper on each part of this topic.
If you need to | Read |
|---|---|
Fix slow responsiveness | |
Fix a slow hero | |
Understand lab vs field data | |
Fix a specific platform | |
Clean up tags and widgets | |
Optimize images and video | |
Stop font layout shift | |
Make the business case | |
Hire help | |
Keep it fast |
If you're auditing more than performance, our on-page SEO audit covers titles, headings and internal links, and the web design, SEO and AEO glossary defines the terms you'll meet along the way. Google's own explanation of the metrics is on web.dev, and how they relate to Search is documented on Google Search Central.
