Core Web Vitals Explained: LCP, INP and CLS for Businesses
Core Web Vitals can look deceptively simple.
Three metrics.
Three thresholds.
Three colours in a performance report.
Good.
Needs improvement.
Poor.
That simplicity is useful.
But it can also create the wrong conversation.
Businesses begin asking:
“How do we get all three numbers into the green?”
Developers chase individual recommendations.
Plugins promise instant optimisation.
Teams celebrate a high Lighthouse score.
And somewhere along the way, the reason these metrics exist can disappear.
Core Web Vitals are not primarily about pleasing a testing tool.
They are designed to measure important aspects of how a website feels to real users.
Can they see the important content quickly?
Does the website respond when they interact with it?
Does the interface remain visually stable while they use it?
Those questions correspond to the current Core Web Vitals:
Largest Contentful Paint — LCP.
Interaction to Next Paint — INP.
Cumulative Layout Shift — CLS.
Together, they provide a useful framework for three important dimensions of website performance:
Loading.
Responsiveness.
Visual stability.
They do not measure everything.
They do not tell you whether the navigation makes sense.
They do not tell you whether the copy is convincing.
They do not tell you whether the checkout is unnecessarily complicated.
And they do not tell you whether the website is commercially effective.
But they can reveal technical friction inside the experience.
That makes them useful far beyond SEO.
What Are Core Web Vitals?
Core Web Vitals are a set of user-centred performance metrics maintained by Google.
The current set focuses on three areas.
LCP measures loading performance.
INP measures responsiveness to user interaction.
CLS measures visual stability.
Google currently recommends aiming for:
LCP of 2.5 seconds or less.
INP of 200 milliseconds or less.
CLS of 0.1 or less.
Importantly, those targets are not based on one perfect visit.
Core Web Vitals are intended to reflect the experience of a substantial majority of users.
The recommended evaluation point is the 75th percentile of page visits, considered separately for mobile and desktop.
That distinction matters.
If 100 people visit a page, the question is not whether the fastest visitor had a perfect experience.
The goal is for the experience to remain strong across a much broader portion of real traffic.
This prevents performance from becoming a demonstration that only works:
On a fast office connection.
On the developer’s laptop.
With a warm browser cache.
On the newest phone.
Under ideal conditions.
A website serves real users under imperfect conditions.
Core Web Vitals attempt to bring some of that reality into performance measurement.
This is also why the metrics fit naturally within Performance by Design™.
Performance should work across the experience.
Not only inside a controlled test.
Largest Contentful Paint Measures How Quickly the Main Content Appears
Largest Contentful Paint is usually abbreviated to LCP.
It measures how long it takes for the largest relevant image, text block or other eligible content element within the viewport to render.
In practical terms, LCP asks something close to:
“When does this page begin to feel useful?”
Imagine a landing page.
The browser window opens.
The navigation appears.
The background appears.
A small logo appears.
But the large hero image and primary headline remain missing for several seconds.
Technically, something is already visible.
From the user’s perspective, the page still feels incomplete.
LCP is intended to capture that more meaningful loading moment.
A good LCP is currently considered 2.5 seconds or less.
Between 2.5 and 4 seconds is generally classified as needing improvement.
Above 4 seconds is considered poor.
But solving LCP is not simply a matter of compressing the largest image.
The final timing can be influenced by the entire delivery chain.
Server response time.
Redirects.
Network latency.
Render-blocking CSS.
Font loading.
Image discovery.
Resource priority.
JavaScript.
Client-side rendering.
Caching.
This is an important architectural lesson.
The slow hero image may be the visible symptom.
The real problem may exist much earlier in the request.
For example, if the server takes too long to begin responding, the browser already starts behind.
If JavaScript needs to execute before the browser even discovers the important image, another delay is introduced.
If the image is unnecessarily enormous, another cost is added.
LCP therefore becomes much more useful when teams stop asking:
“How do we lower this number?”
and begin asking:
“What is delaying the main content from becoming available?”
That question leads toward the underlying architecture.
Interaction to Next Paint Measures Responsiveness
A page can load quickly and still feel terrible to use.
This is where Interaction to Next Paint — INP — becomes important.
INP looks at how responsive the page is when someone interacts with it.
For example:
Clicking a button.
Opening a menu.
Selecting an option.
Using an interactive filter.
Typing into a relevant interface.
Activating controls.
The visitor performs an action.
The browser processes that interaction.
Then the interface provides visual feedback.
When that response happens quickly, the website feels immediate.
When it happens slowly, users experience delay.
That delay can be surprisingly damaging.
A user presses:
“Add to cart.”
Nothing seems to happen.
They press again.
Now two products are added.
Or they open a mobile menu.
The website freezes for a moment.
They wonder whether the tap registered.
Or they change a product filter.
The interface becomes unresponsive while JavaScript performs too much work.
This is Digital Friction™ at the interaction level.
The website knows something is happening.
The user does not.
A good INP is currently considered 200 milliseconds or less.
Above 200 milliseconds and up to 500 milliseconds needs improvement.
Above 500 milliseconds is considered poor.
INP is particularly interesting because it looks beyond initial page load.
A visitor may spend far more time interacting with a website after it has loaded than waiting for its first render.
This means performance cannot stop at:
“The page appeared quickly.”
The page also needs to remain responsive.
Common contributors to poor responsiveness can include:
Large JavaScript tasks.
Heavy client-side rendering.
Complex event handlers.
Too much work on the browser’s main thread.
Third-party scripts.
Overly complicated interfaces.
Again, the metric points toward a deeper architectural question.
How much work does the browser need to perform before it can respond to the user?
Cumulative Layout Shift Measures Visual Stability
Some performance problems do not feel slow.
They feel unstable.
You begin reading an article.
An advertisement loads above the paragraph.
The text suddenly moves downward.
You reach for a button.
An image loads.
The button moves.
You click the wrong element.
A web font appears and changes the dimensions of a heading.
The entire layout shifts.
This is the problem Cumulative Layout Shift — CLS — is designed to measure.
CLS measures unexpected visual movement during the page experience.
Unlike LCP and INP, CLS is not measured in seconds or milliseconds.
It uses a unitless score based on how much visible content moves and how significantly the viewport is affected.
A good CLS is currently considered 0.1 or less.
Above 0.1 and up to 0.25 needs improvement.
Above 0.25 is considered poor.
Common causes include:
Images without reserved dimensions.
Videos without reserved space.
Advertisements loading dynamically.
Embeds and iframes changing size.
Dynamically inserted content.
Web-font behaviour.
Widgets appearing above existing content.
CLS matters because unexpected movement damages a user’s sense of control.
The interface changes without being asked.
This can interrupt reading.
Cause accidental clicks.
Make a website feel unfinished.
And create unnecessary uncertainty.
Again, performance becomes UX.
A stable interface communicates:
“What you see will remain where you expect it to be.”
That predictability is a fundamental part of good UX Architecture™.
The Three Metrics Measure Different Parts of One Experience
LCP, INP and CLS should not be treated as three unrelated technical scores.
They describe three moments inside one experience.
LCP:
Can I see the important content?
INP:
Does the website respond when I interact?
CLS:
Does the interface remain stable while I use it?
A website can succeed at one and fail at another.
For example:
A simple page may have excellent LCP because its content appears quickly.
But heavy JavaScript loaded afterwards may create poor INP.
Another website may be extremely responsive once loaded but use oversized hero media that causes poor LCP.
A third may load and respond quickly while advertisements or dynamically inserted elements create significant layout shifts.
This is why the metrics should be diagnosed individually.
There is no universal optimisation button.
The cause of an LCP problem may be completely different from the cause of an INP problem.
The solution to CLS may require layout decisions rather than server optimisation.
The wider performance architecture determines the result.
This is the connection to our cornerstone guide, What Is Website Performance?
Core Web Vitals are important.
But they represent part of website performance.
Not the whole system.
A business should use them as diagnostic signals.
Signals that reveal where the technical experience may be creating Digital Friction™.
Then investigate the architecture responsible for the number.
The metric tells you where to look.
It does not automatically tell you what to fix.
Field Data and Lab Data Answer Different Questions
One of the most common sources of confusion around Core Web Vitals is the difference between field data and lab data.
They are not interchangeable.
And they do not answer the same question.
Lab data measures performance under controlled conditions.
A tool loads the page using a defined environment.
That environment may simulate:
A particular device.
A particular network connection.
A particular CPU profile.
A clean session.
This makes lab testing extremely useful for diagnosis.
You can reproduce conditions.
Compare versions.
Investigate bottlenecks.
See which resources block rendering.
Identify long JavaScript tasks.
Discover oversized assets.
Test changes before deployment.
But a laboratory test is still a simulation.
It does not represent every person visiting the website.
Field data is different.
Field data reflects measurements collected from real user experiences.
This introduces the variability that exists in the real world.
Different phones.
Different computers.
Different networks.
Different geographical locations.
Different browser conditions.
Different usage patterns.
This is why the two types of data can disagree.
A developer may test a page and receive excellent results.
Meanwhile, field data may show that a meaningful portion of visitors still experience poor LCP.
That does not automatically mean the lab test is wrong.
It means the two measurements are describing different environments.
The reverse can also happen.
A single laboratory run may look weak while aggregate real-user performance remains healthy.
This creates a useful rule:
Use field data to understand what users are experiencing.
Use lab data to help understand why.
The strongest performance workflow uses both.
Do Not Optimize a Lighthouse Score Instead of the Website
Lighthouse and PageSpeed Insights can be incredibly useful.
They can also become addictive.
98.
99.
100.
The number looks objective.
So teams begin treating it as the goal.
This can lead to poor priorities.
A business spends hours moving from 96 to 100.
Meanwhile:
The checkout still contains unnecessary steps.
The mobile navigation remains confusing.
The website depends on slow third-party technology.
The contact form creates unnecessary friction.
A critical product template performs poorly for actual visitors.
Or the website loads quickly but communicates the wrong message.
Performance tools should support decisions.
They should not become the product objective.
This is particularly important because Core Web Vitals do not exist in isolation.
Google’s own guidance treats page experience as a broader concept.
Good Core Web Vitals matter.
But so do factors such as:
Mobile usability.
Security.
Intrusive interstitials.
Content accessibility.
And the overall usability of the page.
A business therefore needs perspective.
If LCP is severely poor, investigate it.
If INP indicates users are waiting for interactions, investigate it.
If CLS causes the interface to jump around, fix it.
But once the experience becomes strong, additional optimisation should be evaluated against the business value of the work.
Performance has opportunity cost.
Development time spent chasing a tiny score improvement is time that cannot be spent improving another part of the customer journey.
This is exactly why Performance by Design™ is based on deliberate trade-offs.
The goal is not numerical perfection.
The goal is a high-performing digital experience.
Prioritize Core Web Vitals by User Journey and Business Impact
Not every page carries the same importance.
A homepage may receive significant traffic.
A product page may influence purchase decisions.
A checkout page may directly determine revenue.
A campaign landing page may receive expensive advertising traffic.
An old archive page may receive almost no visits.
If performance resources are limited, these pages should not automatically receive equal priority.
Instead, combine technical severity with business impact.
Ask:
How poor is the metric?
How many users are affected?
Which device type is affected?
Which template creates the problem?
Which part of the customer journey does the page support?
How commercially important is that journey?
Does the issue create visible Digital Friction™?
Can one architectural change improve many pages simultaneously?
This last question is especially important.
Core Web Vitals problems often occur at the template or system level.
If every blog article uses the same inefficient hero implementation, fixing individual articles is inefficient.
Fix the template.
If every product page loads the same heavy script, investigate the shared component.
If layout shifts come from a global cookie interface, fix the global implementation.
If an unnecessary JavaScript library affects the entire site, address the dependency.
This is architectural optimisation.
One change can improve hundreds of URLs.
This is far more valuable than manually optimising pages one by one while leaving the underlying cause untouched.
It also protects e-commerce and other high-intent journeys where technical friction can become commercially expensive.
Core Web Vitals become strategically useful when they help prioritise the architecture behind the experience.
The AETHER Perspective & Final Thought
At Bureau AETHER, we do not view Core Web Vitals as three boxes a website needs to turn green.
We view them as diagnostic windows into the experience.
LCP reveals whether important content arrives efficiently.
INP reveals whether the interface remains responsive to human intent.
CLS reveals whether the visual environment remains stable.
Each metric exposes a different form of potential Digital Friction™.
But none of them should be interpreted without context.
A number cannot tell you why a page matters.
A score cannot tell you whether an animation contributes to the brand experience.
A performance report cannot decide whether a third-party integration generates enough commercial value to justify its cost.
Those decisions require architecture.
This is where Core Web Vitals connect to Performance by Design™.
We ask:
What is causing the metric?
Is the cause necessary?
Can the system be simplified?
Can the important resource arrive earlier?
Can browser work be reduced?
Can layout space be reserved in advance?
Can the improvement be made at template level?
Will the change improve the real customer journey?
This keeps performance connected to business value.
It also prevents a common mistake:
optimising the measurement instead of improving the experience.
Core Web Vitals matter.
Google’s systems use them as part of their broader understanding of page experience, but Google also makes clear that achieving strong scores alone does not guarantee top rankings.
That is the right perspective for businesses.
Improve LCP because customers should not wait unnecessarily for important content.
Improve INP because interfaces should respond when people act.
Improve CLS because users should remain in control of what they see.
Use field data to understand reality.
Use lab testing to diagnose problems.
Prioritise important journeys.
Fix architecture before chasing cosmetic scores.
And stop when additional optimisation costs more than the value it creates.
Core Web Vitals are most useful when they stop being scores and start becoming signals.
Signals that help you design a faster, more stable and more responsive experience for the people actually using the website.