Learn what LCP, CLS and INP mean, how to measure Core Web Vitals, and what businesses can do to improve website performance and user experience.
Core Web Vitals measure three important parts of a website experience: how quickly the main content appears (LCP), how stable the page remains while it loads (CLS), and how responsive it feels when people interact with it (INP). They are part of Google's page experience and ranking systems, but good Core Web Vitals do not guarantee higher rankings. For a business website, the more practical goal is to make important pages fast, stable and responsive for real visitors.
You do not need a perfect Lighthouse score or a new framework just because one metric is poor. First find the failing metric, understand what is causing it, and then fix the part of the website that is actually creating the problem.
What Are Core Web Vitals?
Core Web Vitals are a set of user-focused performance metrics maintained by Google. The current three metrics are:
- Largest Contentful Paint (LCP) — loading performance
- Cumulative Layout Shift (CLS) — visual stability
- Interaction to Next Paint (INP) — responsiveness
Together, they answer three simple questions:
Did the page become useful quickly?
Did the page stay where it was supposed to be?
Did it respond when the visitor interacted with it?
That makes Core Web Vitals useful beyond SEO. A slow or unstable page can create friction even when the content itself is good.
The Three Core Web Vitals
1. LCP — How Quickly Does the Main Content Appear?
Largest Contentful Paint (LCP) measures when the largest visible content element in the viewport has rendered. This is often a large hero image, heading, or other prominent block.
Google's current “Good” threshold is:
LCP: 2.5 seconds or less
A poor LCP experience can happen when the browser has to wait too long for the server, critical CSS, fonts, images, or other resources.
Common causes include:
- Slow server response time
- Large or poorly optimized images
- Render-blocking CSS or JavaScript
- Late discovery of the LCP resource
- Too many third-party requests
- Fonts or other critical resources loading inefficiently
How to improve LCP
Start with the resource that is actually becoming the LCP element.
Useful improvements can include:
- Improve server response time where necessary.
- Serve appropriately sized images.
- Use modern image formats where suitable.
- Make sure the main visual resource can be discovered early.
- Reduce unnecessary render-blocking work.
- Remove or delay non-critical third-party resources.
In a Next.js project, next/image can help with responsive image delivery and sizing. The important part is not simply using the component, but making sure the actual LCP resource is delivered efficiently.
2. CLS — Does the Page Stay Stable?
Cumulative Layout Shift (CLS) measures unexpected movement of visible content.
Think about a page where you start reading a heading and, a moment later, an image loads above it and pushes everything downward. That is the kind of instability CLS is designed to capture.
Google's current “Good” threshold is:
CLS: 0.1 or less
Common causes include:
- Images or videos without reserved dimensions
- Ads or embeds that appear without reserved space
- Content inserted above existing content
- Poorly managed fonts or dynamic UI elements
How to improve CLS
Reserve space for content before it loads.
That can mean:
- Giving images and videos known dimensions or aspect ratios
- Reserving space for ads and embeds
- Avoiding unexpected insertion of content above the current viewport
- Loading fonts and UI elements in a predictable way
The goal is simple:
The visitor should not have to chase the content around the screen.
3. INP — Does the Website Respond Quickly?
Interaction to Next Paint (INP) measures how responsive a page is when visitors click, tap or use the keyboard during their visit.
Google's current “Good” threshold is:
INP: 200 milliseconds or less
Poor INP is often associated with too much JavaScript work, long tasks, expensive event handlers, or third-party scripts competing for the browser's main thread.
Common causes include:
- Heavy JavaScript execution
- Expensive click or input handlers
- Large amounts of unnecessary client-side work
- Third-party scripts
- Complex interactive components
How to improve INP
Look for the interactions that are actually slow.
Possible fixes include:
- Reduce unnecessary JavaScript.
- Break up expensive tasks.
- Delay non-critical scripts.
- Reduce unnecessary client-side rendering.
- Simplify expensive event handlers.
- Lazy-load genuinely heavy, non-critical components.
In Next.js, tools such as next/dynamic and next/script can help control when certain code and third-party scripts load. They are implementation tools, not automatic performance fixes.
What Does “Good” Actually Mean?
Google's current Core Web Vitals thresholds are:
| Metric | Good | Needs Improvement | Poor |
|---|---|---|---|
| LCP | ≤ 2.5s | 2.5s–4.0s | > 4.0s |
| INP | ≤ 200ms | 200ms–500ms | > 500ms |
| CLS | ≤ 0.1 | 0.1–0.25 | > 0.25 |
Core Web Vitals assessments are based on the 75th percentile of measurements, using field data where available.
A page that is Good for LCP but Poor for INP has not solved the overall Core Web Vitals problem. At the same time, failing a Core Web Vitals assessment does not mean Google will automatically prevent the page from ranking.
That distinction matters.
Do Core Web Vitals Affect SEO?
Yes, Core Web Vitals are part of Google's ranking systems, but they are only one part of many signals.
Good performance cannot compensate for poor relevance, weak content, poor information architecture, or a page that does not satisfy what the searcher needs.
Likewise, a page with imperfect Core Web Vitals can still rank.
So don't approach performance as:
“Get a green score and rankings will increase.”
A better approach is:
Make the website easier and faster to use, while keeping search accessibility and content quality strong.
That is a much more useful business goal.
How to Measure Core Web Vitals
You need two kinds of information:
Field data tells you how real users experienced the website.
Lab data helps you diagnose what may be causing a problem.
PageSpeed Insights
Start with PageSpeed Insights.
Enter the exact URL you want to inspect.
Look at:
- Field data, when available
- LCP
- CLS
- INP
- Diagnostics
- Opportunities
If field data is unavailable, that does not mean the page has failed. It usually means there is not enough representative Chrome user data for the URL or origin yet.
Google Search Console
Search Console's Core Web Vitals report helps you see performance problems across groups of URLs.
Use it to identify:
- Poor URL groups
- Which metric is failing
- Which pages are affected
- Whether the issue is improving after changes
Search Console field data is based on real-user measurements collected over time, so improvements should be monitored over the following weeks rather than judged immediately after deployment.
Chrome DevTools
Use Chrome DevTools when you need to understand the root cause.
For example:
- Use the Network panel to understand loading and resource timing.
- Use the Performance panel to investigate long tasks and slow interactions.
- Inspect layout shifts to identify which element moved.
The idea is:
Measure first. Diagnose second. Fix third.
Common Reasons Business Websites Struggle With Core Web Vitals
Performance problems often come from a combination of issues rather than one bad metric.
Heavy images
Large hero images and unoptimized media can delay the main content.
Too much JavaScript
Large client-side bundles can increase both loading work and interaction delays.
Third-party scripts
Chat, analytics, advertising, widgets and other integrations can compete for browser time.
Slow backend responses
If the server is slow to generate or deliver the response, everything downstream starts later.
Unstable layouts
Images, banners, embeds and dynamic components can shift the page when they appear.
Mobile constraints
A page that feels fast on a powerful desktop can behave very differently on a phone with a slower processor or network.
These problems do not automatically mean the whole website needs to be rebuilt.
What Should a Business Fix First?
A simple order helps:
1. Start with the most important pages
You do not necessarily need to optimize every URL at the same time.
Start with pages that:
- Receive important organic traffic
- Generate enquiries or sales
- Represent key services
- Are used in advertising or campaigns
- Have clear performance problems
2. Fix the biggest bottleneck
If LCP is poor because of a large hero image, fix that before spending days restructuring unrelated JavaScript.
If INP is poor because a chat widget blocks the main thread, investigate the widget before rebuilding the whole frontend.
If CLS is poor because a banner appears without reserved space, reserve the space.
Performance work should be prioritized by impact, not by the number of technical changes you can make.
Do You Need Next.js to Get Good Core Web Vitals?
No.
A business website can achieve strong performance on many different platforms.
Next.js provides useful tools and architecture options for performance, but the framework itself does not guarantee a fast website.
The result still depends on:
- The page architecture
- Rendering approach
- Images
- JavaScript
- Third-party scripts
- Server response
- Caching
- Content
- Infrastructure
This is why we recommend choosing the platform around the business requirement rather than choosing a framework first.
A Real CorgenX Example
We have worked on a WordPress to Next.js migration where the goal was to create a more flexible frontend architecture while keeping the existing content platform.
The project was not simply about adopting a newer framework. The implementation considered frontend architecture, performance, content delivery and the overall website experience.
For that project, we measured results including:
96+ Lighthouse
Under 1s LCP
Zero layout shifts
Those numbers should be understood as project-specific results, not guarantees that every Next.js website will achieve the same performance.
The important lesson is:
Architecture helps, but implementation quality is what determines the final result.
When Performance Requires More Than Optimization
Sometimes a focused performance project is enough.
Other times, the existing architecture creates so many constraints that deeper changes are justified.
For example:
- The frontend forces unnecessary client-side work.
- The backend cannot handle required traffic efficiently.
- The CMS or platform creates repeated performance bottlenecks.
- Important pages depend on expensive processing.
- Performance fixes keep treating symptoms rather than the underlying architecture.
In those cases, a rebuild or migration may become the more sensible long-term option.
But do not start there.
Diagnose first.
A Simple Core Web Vitals Checklist
Before making major changes, ask:
- Is LCP above 2.5 seconds?
- Is CLS above 0.1?
- Is INP above 200ms?
- Do we have field data or only lab data?
- Which page or resource is actually causing the problem?
- Is the issue on mobile, desktop, or both?
- Can we fix the cause without changing the entire platform?
- Is the affected page important to the business?
That last question matters.
A performance improvement is more valuable when it improves a page that actually matters to your customers and revenue.
Need Help Improving Website Performance?
Core Web Vitals are only one part of a website's overall performance.
If your site is slow, unstable, or difficult to use, the cause could be images, scripts, hosting, caching, application architecture, third-party services, or the frontend itself.
At CorgenX, we look at the wider system before recommending a major rebuild.
Explore Website Performance & Technical SEO
You can also start with the Free Website Audit to check several common website health and performance signals.
FAQs
Do Core Web Vitals directly determine Google rankings?
No. Core Web Vitals are part of Google's ranking systems, but they are only one set of signals. Good scores do not guarantee higher rankings, and poor scores do not automatically prevent a page from ranking.
What are the current Core Web Vitals thresholds?
The current Good thresholds are LCP at or below 2.5 seconds, INP at or below 200 milliseconds, and CLS at or below 0.1.
Is Lighthouse the same as Core Web Vitals?
No. Lighthouse is primarily a lab testing tool. Core Web Vitals field data describes how real users experienced the page when sufficient data is available. Both are useful, but they answer different questions.
Should I optimize for a 100 Lighthouse score?
Not as the main goal. A high Lighthouse score is useful, but the better goal is to fix meaningful performance problems for real users and important business pages.
Do I need Next.js for good Core Web Vitals?
No. Next.js can provide useful performance capabilities, but good Core Web Vitals depend on the entire implementation and architecture.
Can poor Core Web Vitals be fixed without rebuilding a website?
Often, yes. Image optimization, caching, script reduction, server improvements, layout fixes, and other targeted changes can solve many problems without replacing the whole platform.