Core Web Vitals in 2026: What LCP, INP and CLS Mean and How to Improve Them

A website can appear to load quickly while still responding slowly when someone clicks a button. Another site may display its content immediately but shift elements around the screen while additional resources load.

This is why “website speed” is more complicated than a single number.

Core Web Vitals measure three different aspects of the user experience: how quickly primary content appears, how responsive the interface is to interaction and how visually stable the page remains.

In 2026, the three Core Web Vitals are:

• LCP — Largest Contentful Paint;
• INP — Interaction to Next Paint;
• CLS — Cumulative Layout Shift.

These metrics are useful for both technical SEO and web development, but they need to be interpreted correctly.

Core Web Vitals are not an overall website quality score or a formula for sales. They are measurable signals describing three specific aspects of real user experience.

What are Core Web Vitals?

Core Web Vitals are metrics used by Google to evaluate important aspects of how users experience a web page.

Each metric focuses on a different area:

• LCP measures loading performance;
• INP measures responsiveness;
• CLS measures visual stability.

An important characteristic of Core Web Vitals is that they are not limited to laboratory testing.

Google can use field data collected from real Chrome users.

This means a developer may run a local test and see an excellent result while Search Console still reports a real-user performance problem.

What are good Core Web Vitals scores?

Metric Good Needs improvement Poor LCP 2.5 s or less over 2.5 s to 4 s over 4 s INP 200 ms or less over 200 ms to 500 ms over 500 ms CLS 0.1 or less over 0.1 to 0.25 over 0.25

Google does not evaluate the metrics using only the fastest or slowest individual visit.

The recommended assessment uses the 75th percentile. In simplified terms, at least around 75% of measured visits should meet the recommended threshold or perform better.

Mobile and desktop experiences should also be reviewed separately.

LCP: how quickly users see the main content

Largest Contentful Paint measures how long it takes for the largest relevant content element within the visible viewport to render.

The LCP element might be:

• a large image;
• a hero banner;
• a video poster;
• a large block of text;
• another significant element near the top of the page.

LCP attempts to answer a practical question: when did the user see the main content of the page?

A good target is an LCP of 2.5 seconds or less.

What commonly causes poor LCP?

Oversized hero images

A large image at the top of the page is one of the most common causes of poor LCP.

If the browser needs to download several megabytes before it can display the primary visual element, the LCP result will naturally suffer.

Slow server response

If the initial HTML arrives slowly, the browser cannot begin rendering important page content immediately.

The cause may involve hosting, server-side logic, a database, missing caching or an external API.

Render-blocking resources

CSS, JavaScript and fonts can delay the moment when the browser is able to render important content.

Not every resource is a problem. The key is identifying which files are essential for the first screen and which can be loaded later.

Incorrect resource prioritization

The browser may discover the LCP resource too late, particularly when it is introduced through complex JavaScript or CSS.

Even a properly compressed image can start loading too late if its priority is not clear.

How to improve LCP

Depending on the cause, improvements may include:

• reducing the size of the main image;
• using an appropriate image format;
• implementing responsive images;
• improving server response time;
• using caching effectively;
• reducing unnecessary render-blocking resources;
• prioritizing the critical LCP resource;
• simplifying an overloaded hero section.

The important point is to optimize the actual cause rather than blindly following the metric name.

If the LCP element is a large text block, compressing every image on the page may not solve the underlying problem.

INP: how quickly the website responds to users

Interaction to Next Paint evaluates interface responsiveness.

It considers interactions such as:

• mouse clicks;
• touchscreen taps;
• keyboard interactions.

INP reflects the delay between a user action and the next visual update the browser can present.

A good INP target is 200 milliseconds or less.

INP replaced the previous FID metric as a Core Web Vital in 2024.

What causes poor INP?

Heavy JavaScript

When the browser's main thread is occupied by a long JavaScript task, a user may click a control but the interface cannot respond immediately.

The delay may be difficult to notice on a high-end laptop.

The same code can feel considerably slower on a less powerful smartphone.

Expensive event handlers

A single interaction may trigger a substantial amount of synchronous work: calculations, DOM updates, filtering a large data set or rendering many components.

Third-party scripts

Chat widgets, analytics platforms, advertising systems, A/B testing tools and other integrations also compete for browser resources.

One small service may have very little impact. A collection of many third-party integrations can create a very different performance profile.

Unnecessary re-rendering

Complex JavaScript applications can suffer from poor INP when interactions trigger unnecessary updates across large parts of the interface.

The issue in such cases is not the framework name itself but how the application has been architected and implemented.

How to improve INP

Depending on the cause, useful techniques may include:

• breaking up long JavaScript tasks;
• removing unnecessary code;
• optimizing event handlers;
• reducing expensive DOM operations;
• reviewing third-party scripts;
• deferring non-critical logic;
• optimizing component updates and rendering;
• testing on real mobile hardware.

It is important not to judge responsiveness solely by how quickly the page initially appears.

A website can have an excellent LCP and still suffer from poor INP.

CLS: how visually stable the page remains

Cumulative Layout Shift measures unexpected movement of visible page elements.

A classic example occurs when someone is about to tap a button and a banner suddenly loads above it, moving the content and causing the user to tap the wrong element.

Another example is text shifting after a web font loads and changes its dimensions.

A good CLS target is 0.1 or less.

Unlike LCP and INP, CLS is not measured in seconds or milliseconds. It is a unitless score representing visual instability.

What commonly causes poor CLS?

Images without reserved space

If the browser does not know an image's dimensions in advance, it may render text first and then move the content once the image arrives.

Ads and dynamic banners

A component inserted after the rest of the page without reserved space can push existing content down.

Web fonts

Replacing a fallback font with a downloaded web font can change the width or height of text and cause surrounding elements to shift.

Content inserted above the current viewport

Cookie notices, promotional messages and other dynamically inserted elements should be designed carefully so they do not unexpectedly move content the user is already viewing.

How to improve CLS

Common techniques include:

• setting dimensions or aspect ratios for media;
• reserving space for advertisements and widgets;
• managing web font loading carefully;
• avoiding insertion of new content above existing content without user action;
• reviewing asynchronously loaded components;
• testing the page beyond the initial load.

Why the 75th percentile matters more than one perfect test

Core Web Vitals are designed to represent the experience of a broad real-world audience.

Visitors use different:

• devices;
• processors;
• network connections;
• browser environments;
• geographic locations;
• cache states.

A single test on a powerful laptop connected to fast Wi-Fi therefore cannot describe the experience of every customer.

The 75th percentile provides a way to evaluate a large proportion of real visits.

For example, a 75th-percentile LCP of 2.3 seconds means that approximately 75% of measured visits experienced an LCP of 2.3 seconds or better.

Why Search Console does not turn green immediately after a fix

The Core Web Vitals report in Search Console is based on real-user field data rather than today's laboratory test alone.

The data is aggregated over time.

This means fixing a performance issue today does not necessarily cause the report to change completely tomorrow.

New visits need to gradually replace older data within the reporting period.

This is why laboratory tools are useful for immediate development diagnostics while field data is more appropriate for evaluating the real-world result over time.

Why does Search Console group URLs?

Search Console can group pages that provide similar experiences.

For example, dozens of product pages may use the same template and suffer from the same LCP problem.

In that situation, it may not be necessary to optimize each URL manually.

The underlying issue may exist in one shared template or component.

Core Web Vitals work therefore often involves identifying systematic causes rather than treating each affected page as an independent problem.

Core Web Vitals vs PageSpeed Insights

PageSpeed Insights is a tool.

Core Web Vitals are metrics.

PageSpeed Insights can display real-user field data where sufficient information exists, as well as Lighthouse laboratory analysis.

These are different parts of the report.

Laboratory testing is useful for immediate diagnostics during development.

Field data is useful for understanding how the page has actually performed for real users over time.

Core Web Vitals and SEO

Google recommends achieving good Core Web Vitals and uses these metrics within its ranking systems.

Their role should not be exaggerated, however.

Good LCP, INP and CLS do not guarantee first-page rankings.

A page still needs to satisfy search intent and provide relevant, useful content.

Removing valuable information purely to gain a small technical improvement can therefore be counterproductive.

A stronger approach combines useful content with a good user experience.

Core Web Vitals and conversion

Poor performance can create friction in the customer journey.

If primary content appears slowly, controls respond with a delay or the layout constantly shifts, users may find it more difficult to complete an intended action.

There is no universal formula, however, in which improving LCP by one second automatically produces a fixed percentage increase in sales.

The effect depends on the audience, website type, traffic source, product, UX and many other factors.

After performance improvements, businesses should review commercial metrics as well as technical ones, including enquiries, purchases and form completion.

Can WordPress or website builders achieve good Core Web Vitals?

Yes.

The technology alone does not determine the result.

WordPress, Webflow, Wix, custom development and other platforms can all produce either good or poor Core Web Vitals depending on their implementation.

Performance can be influenced by:

• themes;
• plugins;
• content;
• images;
• third-party services;
• animation;
• hosting;
• architecture;
• development quality.

Custom development can provide greater control over performance, but poorly implemented custom code can still produce a slow website.

Platforms are better evaluated according to actual metrics and the requirements of the specific project.

How to measure Core Web Vitals properly

PageSpeed Insights

Useful for reviewing field data where it is available and for obtaining laboratory diagnostics.

Google Search Console

Useful for monitoring groups of URLs and identifying systematic Core Web Vitals issues.

Chrome DevTools and Lighthouse

Useful during development when investigating a specific technical cause.

Real devices

Manual testing should not be underestimated.

A delayed button response or significant layout shift can sometimes be easier to feel on an ordinary smartphone than to understand from a table of metrics.

What order should Core Web Vitals problems be fixed in?

1. Identify which specific metric is failing the recommended threshold.
2. Find the affected page types.
3. Identify the relevant element or user interaction.
4. Find the underlying technical cause.
5. Implement the change.
6. Verify the improvement using laboratory testing.
7. Confirm that functionality still works correctly.
8. Monitor field data as it updates.

This is generally more effective than installing another generic “speed plugin” every time a tool displays a red warning.

When should Core Web Vitals become a priority?

Performance work deserves a high priority when:

• important page groups consistently fall into the poor range;
• the problem is particularly severe on mobile;
• users visibly wait for primary content;
• the interface freezes during important interactions;
• layout shifts interfere with normal use;
• the issue affects an entire template;
• performance declined after a new script, plugin or redesign.

If all three metrics already fall within the good range, spending a large development budget to reduce LCP from 2.1 to 1.9 seconds may be less valuable than improving weak content or a confusing enquiry form.

The TimeKairos approach

At TimeKairos, we treat Core Web Vitals as part of the technical quality of a website rather than three magic numbers that directly determine sales.

The first step is understanding which metric is creating a problem and which users are affected.

The next step is identifying the root cause: an image, server response, JavaScript, third-party service, font, component or page architecture.

Only then does optimization begin.

This approach helps avoid random changes and prevents important functionality from being sacrificed simply to produce a more attractive technical report.

Conclusion

Core Web Vitals in 2026 consist of LCP, INP and CLS.

LCP shows how quickly users see primary content. INP measures how quickly the interface responds to interaction. CLS evaluates how visually stable the page remains.

Useful targets are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less and a CLS of 0.1 or less.

But the numbers themselves should not become the final objective.

Core Web Vitals are most valuable when they help identify a real user problem — not when a website is optimized purely to make a report turn green.