Core Web Vitals Explained: LCP, INP and CLS

Core Web Vitals are three metrics used to assess important aspects of a website's user experience: loading speed, interactivity, and visual stability.

The three current Core Web Vitals are Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS).

However, a good score alone does not mean that the entire website is fast and trouble-free. Each of the three metrics looks at a different aspect of the user experience.

In this article, we explain what LCP, INP, and CLS measure, what values are considered good, and how you can systematically search for the cause if results are conspicuous.

Briefly explained: LCP measures, simply put, how quickly a major piece of page content becomes visible. INP evaluates how quickly the website responds to user interactions. CLS measures unexpected layout shifts during use.

What are the Core Web Vitals? #

Core Web Vitals are metrics defined by Google to evaluate certain aspects of the actual user experience of a website.

The three current Core Web Vitals are:

measured value	Full name	Rated
LCP	Largest Contentful Paint	Charging experience
INP	Interaction to Next Paint	Responsiveness
CLS	Cumulative Layout Shift	Visual stability

The values complement each other because a website can be very good in one area and problematic in another.

The Limit Values at a Glance #

Google categorizes the values into the ranges „good“, „needs improvement“, and „poor“.

measured value	Good	Needs improvement	Bad
LCP	≤ 2.5 s	2.5 s to 4.0 s	4.0 s
INP	≤ 200 ms	200 ms to 500 ms	> 500 ms
CLS	≤ 0.1	0.1 to 0.25	0,25

Important: Each of these limits corresponds to a specific metric. For example, an LCP limit of 2.5 seconds does not mean that every other conceivable loading time must also be under 2.5 seconds.

Why is the 75th percentile used? #

When evaluating real usage data, it is not just a matter of looking at the best or average page view.

The 75th percentile is used for the Core Web Vitals.

Simplified, this means: At least 75 percent of the measured experiences should reach the respective threshold or be better.

100 measured experiences

75 or more
→ good range

if the value at the 75th percentile
is within the good limit value

This ensures that the assessment is not solely determined by exceptionally fast devices and connections.

Passing Core Web Vitals: What does that mean? #

For a good Core Web Vitals assessment, the three decisive metrics LCP, INP, and CLS must be in the good range at the 75th percentile, provided there is a sufficient data basis.

So a website can, for example, have a good LCP and CLS, but fail the Core Web Vitals assessment due to a poor INP.

LCP → good
INP → poor
CLS → good

Result:
Core Web Vitals assessment failed

LCP – Largest Contentful Paint #

Largest Contentful Paint measures the time until the largest relevant content element in the visible area is rendered.

This is intended to allow LCP to approximately measure when a major part of the main content has become visible to the visitor.

A good LCP is:

2.5 seconds or less

Which element can be the LCP element? #

That depends on the structure of the respective page.

Frequently, these are, for example:

large hero image
large text headline
banner
large content image
large text block

You should check which element is actually recognized as LCP using a performance tool rather than just guessing based on the design.

Example of an LCP #

Assuming a home page has a large hero image in the upper area:

┌─────────────────────────────────────┐
│ Navigation                          │
├─────────────────────────────────────┤
│                                     │
│          LARGE HERO IMAGE          │
│                                     │
│        Web Hosting for SMEs           │
│                                     │
└─────────────────────────────────────┘

If this image represents the largest relevant element in the viewport, it can become the LCP element.

If it loads late, this can also degrade the LCP.

What can cause a poor LCP? #

A poor LCP can have various causes.

This may include, for example:

• a slow delivery of the HTML document,
• a very large LCP image,
• a late-discovered image resource,
• render-blocking resources,
• Web fonts,
• client-side rendering,
• an unfavorable charging prioritization.

The actual cause must be investigated on the specific site.

In case of poor LCP, first identify the LCP element #

Before changing any performance settings, you should determine which element is actually being measured.

Poor LCP
    ↓
Identify LCP element
    ↓
Image?
Text?
Other element?
    ↓
Investigate loading path of this element

Google PageSpeed Insights can provide clues about the LCP element and its loading behavior during the analysis.

We explain how to use the tool under How to use Google PageSpeed Insights correctly.

If an image is the LCP element #

If a hero or content image is responsible for the LCP, you should first check its technical properties.

Of interest, among other things, are:

Pixel dimensions
File size
Image format
Compression
Responsive image variants
Discovery time
Loading priority
Lazy loading

For example, an image in the immediately visible area should not be treated in the exact same way without review as an image far down the page.

We explain how to prepare images effectively at Optimizing images for the web: file size, format and SEO.

Lazy loading can be problematic for LCP #

Lazy loading is often useful for images outside the immediately visible area.

However, if an important LCP image in the upper part of the page is loaded with unnecessary delay, this can worsen the LCP.

Therefore, the following does not apply:

All images = Lazy Loading

Rather:

Use lazy loading wherever delayed loading makes sense.

A modern image format alone does not fix a bad LCP #

WebP or AVIF can help reduce the file size of an image. However, the format is only one part of the overall loading path.

A huge WebP image with unnecessary pixel dimensions can still be problematic.

Even a small image file can be loaded late if the browser discovers it late.

We will discuss the choice of image format under WebP, AVIF, JPG and PNG: Which image format to use?.

The server response can affect the LCP #

Before the browser can render important page content, it must first receive the necessary data.

If the provision of the HTML document already takes a long time, the point in time at which downstream resources can be discovered and rendered is also delayed.

A poor LCP should therefore not be viewed exclusively as an „image problem“.

INP – Interaction to Next Paint #

Interaction to Next Paint measures a page's responsiveness to user interactions.

This includes, for example, interactions via:

Mouse click
Touchscreen
Keyboard

INP considers how long it takes for an interaction to be processed and for the browser to subsequently be able to render a visual update.

A good INP is:

200 milliseconds or less

What does INP mean for a visitor? #

Imagine you click a button.

With a responsive website, you get a visible reaction almost immediately.

In the case of poor responsiveness, on the other hand, a noticeable delay can occur:

Click
  ↓
........ delay ........
  ↓
visible reaction

Precisely this type of user experience is what INP is designed to make measurable.

INP does not simply measure the first click #

INP looks at the interactions during a page visit and attempts to assess overall responsiveness based on a representative slow interaction.

It is therefore not simply a measurement of the first interaction after the page load.

What is included in interaction latency? #

In simple terms, the duration of an interaction can be broken down into several sections:

User interaction
        ↓
Input delay
        ↓
Event handler / processing
        ↓
Rendering delay
        ↓
Next visible frame

Problems can arise in different parts of this process.

What can cause a poor INP? #

A common cause is too much work on the browser's main thread.

Extensive or inefficient JavaScript can contribute to this.

Further possible causes include, for example:

• long JavaScript tasks,
• complex event handlers,
• complex DOM changes,
• extensive layout and rendering work,
• many scripts executed simultaneously,
• complex third-party code.

What is the main thread? #

The main thread of the browser takes on numerous tasks that are necessary for the rendering and interaction of a webpage.

This includes, among other things, parts of the JavaScript execution, layout calculations, and rendering work.

If this thread is busy with a task for a long time, it cannot simultaneously respond to a new user interaction immediately.

Main Thread:

████████ Long JavaScript Task ████████
                                      ↓
                         User clicks here
                                      ↓
                         Must wait first

What are long tasks? #

Long tasks on the main thread can impair a website's responsiveness.

For example, a complex JavaScript task can keep the browser busy for so long that user interactions are processed with a delay.

Therefore, during INP optimization, it is often of interest which tasks take place during a slow interaction.

INP is not the same as TBT #

In Lighthouse, you often encounter the value Total Blocking Time, or TBT for short.

TBT is a laboratory metric. INP, on the other hand, is based on actual user interactions and is a Core Web Vital.

TBT can be helpful for technical diagnosis, but it is not a replacement for INP.

TBT
→ Lab measurement

INP
→ Real interaction data possible
→ Core Web Vital

Why can't PageSpeed generate a real INP in a lab test? #

INP requires real user interactions during a page visit.

A synthetic Lighthouse load test does not possess the same collection of real interactions as field data.

That's why you should pay particular attention to available field data for INP.

What to do with poor INP? #

First, try to figure out which interactions are slow.

Examples:

Open menu
Apply filters
Select product variant
Open accordion
Fill out the form
Update shopping cart
Manage cookie banner

You should then investigate what JavaScript or rendering work is triggered by this interaction.

Practical Tip: When dealing with a poor INP, you should not just randomly disable JavaScript files. First, find out which interaction is slow and what the browser is processing during that interaction.

Third-party scripts can affect INP #

Websites often load JavaScript from external services.

Examples are:

Analytics
Tag Manager
Chat Systems
Social Media Widgets
Advertising Systems
Tracking
Maps
Marketing Tools

Even such code can consume computing time on the main thread.

That does not mean that every external service must be removed. However, its benefit should be weighed against the technical effort and potential performance impacts.

CLS – Cumulative Layout Shift #

Cumulative Layout Shift measures unexpected shifts of visible page elements.

A good CLS is around:

0.1 or less

Unlike LCP and INP, CLS is not specified in seconds or milliseconds.

It is a dimensionless value that describes the impact of unexpected layout shifts.

What does a bad CLS feel like? #

A classic example:

You want to click a button. Just before the click, another element appears above it. The button jumps down and you accidentally click on something else.

BEFORE

[ Buy ]

You want to click ...

      ↓

Image is reloading

      ↓

AFTER

[ new image ]

[ Buy ]

Button has suddenly shifted

Such unexpected movements can be very disruptive.

Not every layout shift is bad #

Layout changes can also be expected by the user and consciously triggered.

For example, when you open a menu or expand an accordion section, the interface may change accordingly.

Particularly problematic are unexpected shifts that occur without the user's anticipation.

What can cause a poor CLS? #

Typical causes can be:

• Pictures without a reserved place,
• Advertising or banner spaces without fixed dimensions,
• subsequently inserted content,
• Cookie or notification elements that shift content,
• certain web font effects,
• dynamic widgets.

Images without dimensions and CLS #

If the browser does not know how much space is needed before loading an image, the layout can shift as soon as the image appears.

For an HTML image, for example, suitable information for width and height help to consider the aspect ratio or the required space in advance.

<img
  src="beispiel.webp"
  width="1200"
  height="800"
  alt="Sample image"
>

Modern CMS often handle such information automatically. In the case of noticeable CLS, checking anyway is worthwhile.

Web Fonts and Layout Shifts #

Fonts can also affect the display.

If a fallback font is displayed first and later replaced by a web font, character widths and line breaks may change.

This can also cause the layout to shift.

Whether this actually causes a relevant CLS problem should be measured and not just guessed.

Cookie Banner and CLS #

A cookie banner can also cause layout shifts if it is subsequently inserted into the normal page flow and shifts existing content.

An overlay that appears on top of existing content behaves technically differently than an element that subsequently claims space within the layout.

Therefore, in the case of conspicuous CLS values, you should also investigate consent and notification systems.

Dynamic content and CLS #

Deferred content can be problematic if no corresponding space was previously allocated for it.

Examples:

Advertising banners
Recommendation boxes
Social media feeds
Reviews
External widgets
Personalized content

When such elements shift content downwards or to the side, they can contribute to CLS.

How is CLS calculated? #

CLS is not simply based on the number of movements.

Among other things, a layout shift takes into account how much of the visible area is affected by unstable elements and how far these elements move.

The individual relevant layout shifts are evaluated within defined session windows.

For practical website optimization, you usually don't have to calculate the formula yourself. It is more important to identify the causing elements.

LCP, INP and CLS measure different problems #

For example, a website can have the following values:

LCP: 1.9 s
→ good

INP: 180 ms
→ good

CLS: 0.32
→ poor

In this example, the page loads quickly and responds well to interactions, but suffers from significant visual shifts.

A blanket statement like „The website is fast“ would not capture the actual problem.

Another example #

LCP: 4.4 s
→ bad

INP: 120 ms
→ good

CLS: 0.04
→ good

Here the website responds well and remains visually stable. However, the main content appears too late.

Optimization should therefore initially focus on the LCP or its cause.

differentiate field data and laboratory data #

For the Core Web Vitals, the distinction between real-world field data and synthetic lab data is particularly important.

Field data show the actual experiences of real users.

Laboratory data are generated under controlled test conditions and are particularly well-suited for technical diagnosis.

We explain the differences in detail at Measure website loading time and evaluate it correctly.

Why do my real and tested values differ? #

Real visitors use different devices, network connections, and browser conditions.

A laboratory test, on the other hand, works with fixed or simulated conditions.

Therefore, for example, the following results can occur simultaneously:

Lab test:
LCP abnormal

Real-world field data:
LCP good

or vice versa.

Both results can be correct because they look at different data.

Where can I find real Core Web Vitals data? #

Actual usage data can be displayed in Google PageSpeed Insights, among other places, provided there is sufficient data for the URL or origin in question.

Google Search Console also provides a report on Core Web Vitals.

We cover the setup of the Search Console under Set up Google Search Console and verify website.

Why is Core Web Vitals data sometimes missing? #

A sufficient data basis must be available for field data.

New or infrequently visited websites or individual URLs may therefore under certain circumstances not have sufficient field data of their own.

This is not a performance bug.

Important: Missing field data does not mean your Core Web Vitals are bad. There simply may not be enough suitable measurement data available.

URL data and origin data #

Depending on availability, performance tools can display data for a single URL or aggregated data for an entire origin.

This should be taken into account during the interpretation.

URL
→ specific page

Origin
→ aggregated data
  of the same website origin

Therefore, a good Origin value does not automatically guarantee that every single page functions identically.

Core Web Vitals and mobile devices #

Mobile users may have different performance experiences than desktop users.

Differences arise, for example, through:

Computing power
Network connection
Display size
Page layout
Loaded resources
User interactions

That is why you should not evaluate performance issues exclusively on a powerful desktop computer.

Core Web Vitals and SEO #

Core Web Vitals are part of the technical signals regarding a page's user experience.

However, they should not be viewed as an isolated „Google ranking score“.

A good LCP, INP, and CLS do not guarantee a specific position in search results.

Conversely, you shouldn't ignore bad metrics just because a page is currently ranking well.

A fast, responsive, and stable website is especially useful for your visitors.

Going from 90 to 100 is not automatically the most important optimization #

The Core Web Vitals have clearly defined good ranges. That does not mean you subsequently have to eliminate every single additional millisecond at all costs.

If a website already offers a good user experience, it may make more sense to solve major problems elsewhere.

For example:

LCP 2.4 s → good

however:

Checkout does not work on mobile devices

→ Checkout issue clearly has higher priority

Do not optimize Core Web Vitals in isolation #

Technical performance measures can have side effects.

If you aggressively delay JavaScript just to improve a metric, for example, navigation, forms, or other functions can be impaired.

The same applies to excessive image compression or inappropriate lazy loading.

Basic rule: Performance optimization is only an improvement if the website not only has better metrics afterwards, but continues to function correctly and pleasantly.

Systematically optimize Core Web Vitals #

Instead of haphazardly implementing optimization measures, you should first determine which metric is actually problematic.

Check Core Web Vitals
        ↓
Which metric is poor?
        ↓
LCP?
INP?
CLS?
        ↓
Identify specific cause
        ↓
Targeted change
        ↓
Test website
        ↓
Measure again

If LCP is poor #

Start with the following questions:

Which element is the LCP element?

When is it discovered?

How large is the resource?

Is the image properly sized?

Is it lazily loaded unnecessarily?

Are other resources blocking rendering?

How quickly is the HTML provided?

Afterwards, you can optimize much more specifically.

If INP is bad #

Begin with:

Which interaction is slow?

What happens after the click or key press?

Which JavaScript tasks are running?

Is the main thread blocked for a long time?

Are third-party scripts involved?

Are large DOM or layout changes triggered?

The goal is not simply „less JavaScript,“ but less unnecessary or poorly planned work during important interactions.

If CLS is bad #

Investigate:

Which element is shifting?

What triggers the shift?

Are image dimensions known?

Is content being inserted afterwards?

Does a web font change the layout?

Does a banner shift existing content?

Are external widgets involved?

Then fix the specific cause of the unexpected shift.

Several problems can have the same cause. #

Performance issues are not always neatly separated from one another.

For example, a complex JavaScript widget can reload resources, strain the main thread, and simultaneously insert content into the layout.

This can affect multiple measured values.

A thorough root cause analysis is therefore more important than the isolated „optimization of a number“.

Measure again after making changes #

Once you have fixed a specific cause, you should test again.

Laboratory tests are well suited for immediate technical changes.

Real-world field data, on the other hand, do not change immediately because they are collected and evaluated over a longer period of time.

Therefore, do not expect an optimization performed today to immediately change all field data.

Common mistakes with Core Web Vitals #

Equate LCP with full load time

Equate INP with TBT

Interpret CLS in seconds

Consider only the performance score

Test only on desktop

Interpret missing field data as poor values

Lazy load every image across the board

Blindly disable JavaScript

Consider every layout shift a CLS issue

Equate good Core Web Vitals with good rankings

Implement multiple optimizations simultaneously

Expect new field data immediately after changes

Practical Diagnostic Matrix #

Problem	Initial examination
LCP poor	Identify LCP element and its loading path
INP poor	investigate slow interactions and main-thread work
CLS bad	identify shifted elements and triggers

Core Web Vitals Checklist #

Field data available?
        ↓
URL or origin data?
        ↓
Look at 75th percentile
        ↓
LCP ≤ 2.5 s?
        ↓
INP ≤ 200 ms?
        ↓
CLS ≤ 0.1?
        ↓
Determine problematic metric
        ↓
Find causing element / interaction
        ↓
Investigate technical cause
        ↓
Implement targeted change
        ↓
Test website functionality
        ↓
Repeat lab test
        ↓
Monitor field data trends

Summary #

Core Web Vitals look at three different aspects of a website's user experience.

LCP measures the loading experience of a major important content and applies at a value of at most 2.5 seconds Oh well.

INP evaluates the responsiveness to user interactions. A value of at most 200 milliseconds is considered good.

CLS evaluates unexpected layout shifts. A value of at most 0,1 is considered good.

For the evaluation of real usage data, the 75th percentile is crucial. This ensures that not only particularly fast individual requests are considered.

When performance metrics are poor, you shouldn't immediately change general performance settings. First, identify the affected element for LCP, the slow interaction for INP, and the unexpected layout shift for CLS.

Core Web Vitals are most helpful when you don't view them as three numbers that should be made as green as possible, but rather as clues as to which specific experience of your visitors can be improved.