What Are LCP, INP and CLS in Web Performance?
A site that looks fast in a test may still feel slow to visitors. LCP measures loading experience, INP responsiveness and CLS unexpected layout shifts. Lab results and field data answer different questions.
Three thresholds, not one score
Core Web Vitals are the three measurements Google puts forward for page experience. LCP watches loading, INP the response to an interaction, and CLS visual shifting. The targets for a good experience are set for most visits. web.dev states that as the 75th percentile of page loads. Mobile and desktop are read apart. Opening the page once and finding it fast is not the same as meeting that percentile.
On the Web Vitals page updated 31 October 2024, LCP and CLS are stable measurements. INP became the stable measurement in 2024, replacing First Input Delay. A stable measurement is not changed more than once a year. It still does not have to be permanent. These three numbers do not say whether the text is right. A good load time does not repair a muddled page. This article does not promise rank either.
| Measurement | What feels wrong | Target |
|---|---|---|
| LCP | The main content appears late | 2.5 seconds or less |
| INP | The screen lags after a click, tap, or key | 200 milliseconds or less |
| CLS | The place you are reading shifts | 0.1 or less |
When the main content arrives late
LCP is the time from when a visitor starts loading the page until the largest image or text block in the viewport is painted. On many pages that element is the cover image. Fixing the time with a single switch is rarely enough. web.dev recommends looking at the initial HTML document and the file the LCP element uses, together.
A slow time to first byte, TTFB, means the server is late sending the HTML. Redirects, a visitor far from the server, or a cache that cannot be used can stretch it. A long gap between TTFB and the first content can show that the browser is downloading many files before it paints, or that the content is built with JavaScript. A long gap between the first content and LCP suggests the main image is not ready in the HTML, and that a script asks for it later.
Putting loading="lazy" on the LCP image delays the load on purpose. web.dev says never to lazy-load the LCP image. If the image is in the HTML, fetchpriority="high" can give it priority. Giving that priority to many images stops helping. In PageSpeed Insights, look at the real-user data, the CrUX section, first. The lab section is for diagnosis when it points the same way as the field data. If an address has no data of its own, the tool can show data for the whole site. A home page and an inner page do not have to share an LCP.
Fictional example
This example is not a client record. A hotel's cover photo is the largest element on the page. The photo is not in the HTML. After the page opens, a script requests it, and lazy loading is added on top. The visitor sees an empty area for a few seconds. The complaint here is not a general slowness. It is that the LCP image is requested late.
When the screen lags after a click
INP watches qualifying interactions across the visit and reports the longest one, sometimes setting outliers aside. For a good experience it is 200 milliseconds or less. Lighthouse cannot take this measurement in a test with no user input. In the lab it uses Total Blocking Time instead. An improvement in the lab may improve INP in the field. It does not stand in for it.
An interaction splits into three parts. The delay starts when the visitor clicks and lasts until the event begins to be handled. Processing is how long the code that answers the click runs. Presentation is the time after that code finishes until the browser paints the next frame. Shrinking the code before you know which part is long is a guess.
Input delay
The page can be visible while JavaScript is still being parsed. If the visitor clicks then, the click waits because the main thread is busy. Large scripts produce long tasks while the page is opening.
Processing duration
If the click's function also runs a spell check, a counter, and a save before it updates the screen, the frame is late. Doing the visual update immediately, and leaving the rest for a later task, is the split web.dev recommends.
Presentation delay
A very large DOM stretches the paint of the next frame. Producing large pieces of HTML with JavaScript carries the same cost. If the slowness is inside an iframe, the main thread to inspect is that frame's, not the page's.
Fictional example
This example is not a client record. On a catalog page, pressing the filter runs the list, a spell check, and a save request inside the same function. The visitor sees the button respond half a second later. The measurement is INP. The first place to look is how much work the button does before it updates what is on screen.
When the line shifts while you read
CLS is visible content moving when it was not expected to. The causes web.dev writes about often are images without dimensions, ads and embeds that arrive late, animations that break the layout, and a change of typeface.
Leaving width and height off an image or video postpones the space until the file has downloaded. Setting the width to 100 percent in CSS and the height to auto leaves the same gap. width and height, or aspect-ratio, let the space open in advance. Ads, maps, video embeds, and banners added later can push the page the same way. Reserve space for late content with min-height or aspect-ratio. Collapsing that space when no ad arrives causes as much shift as pushing the content later. If you cannot reserve the space, placing the late content lower on the page reduces the effect.
An animation that uses top and left shifts the layout. A move made with transform is not written to CLS. When a web font arrives and replaces the fallback, the lines move as well. The fallback should come from a family close to the final font. font-display: optional is a route that can keep the typeface from changing if the font is not ready before the first layout.
A shift within 500 milliseconds of a load the visitor started is not written to CLS. A button such as load more products is different, for that reason, from a banner that drops in from the top without warning.
Do not treat a lab score as the field
The top of PageSpeed Insights is data from real Chrome users. The bottom is the lab. When the two disagree, the field data describes the experience. The lab is for seeing the cause. Your own real-user measurement fills in the page detail CrUX does not give. A value read in JavaScript does not have to match the CrUX report.
These measurements do not change what the page says. The text, the form, and the offer stay inside the site and the software.
- Is the complaint loading, waiting after a click, or shifting.
- In PageSpeed Insights, is the number this address's own data, or an average for the whole site.
- Which element is the LCP. Is the image in the HTML, or does a script request it later. Is it lazy-loaded.
- Which interaction is late on INP. Is the time piling up at the input, in the function, or on the next frame.
- Does the image have a size. Is space reserved for a late banner or ad. Is the animation using top and left.
Sources
- Web Vitals
Accessed October 18, 2026
- Optimize Largest Contentful Paint
Accessed October 15, 2026
- Optimize Interaction to Next Paint
Accessed October 18, 2026
- Optimize Cumulative Layout Shift
Accessed October 15, 2026