Core Web Vitals Explained: LCP, INP and CLS

Core Web Vitals are three metrics defined by Google to evaluate the real experience a visitor has on a web page: LCP measures how quickly the main content renders, INP measures responsiveness to interactions, and CLS measures visual stability while the page loads. You can measure all three for free with PageSpeed Insights or Search Console.

The real problem: technical scores nobody knows how to interpret

Plenty of site owners have already seen these acronyms, LCP, INP, CLS, show up in a PageSpeed Insights report or in Google Search Console, without really knowing what they measure or why they matter. The common reflex is to treat these metrics as an abstract technical exam to pass, a score to push up without understanding what it means.

But Core Web Vitals don't measure a technical feat in itself: they measure, indirectly but fairly accurately, what a visitor actually feels while using the site. A poor score almost always corresponds to a concrete, unpleasant experience: a page that takes a while to display its content, a button that doesn't respond immediately to a click, or a layout that jumps just as the user was about to click on something else. Understanding this changes how you approach these metrics: they're not a box to tick for Google, they reflect an actual user experience.

LCP: how fast the main content renders

LCP (Largest Contentful Paint) measures the time it takes for the largest element visible in the initial viewport (often an image, a heading, or an important block of text) to fully render on screen. It's not the total page load time, but the moment the user sees what visually constitutes the heart of the content appear.

A slow LCP gives the impression of a site that takes a while to "start": the page looks empty or incomplete for several seconds before the main element appears. This is often the first impression a visitor forms about a site's performance.

Common technical causes of a poor LCP:

• Unoptimized or overly heavy images used as the main element (banner, product photo).
• Server response time too slow before the browser receives the first content.
• Render-blocking resources (large CSS or JavaScript files) loaded before the main content displays.
• No preloading for critical resources (such as an above-the-fold image).

INP: responsiveness to interactions

INP (Interaction to Next Paint) measures how responsive a page is to user actions: a click, a tap on mobile, a keystroke. In concrete terms, it evaluates the delay between the moment the user interacts and the moment the page visually responds to that action, by observing every interaction made during the visit, not just the first one.

INP replaced an older metric, FID (First Input Delay), which only measured the delay before the user's very first interaction with the page. That limitation was a real problem: a site could respond well to the first interaction and then become sluggish on subsequent ones, without FID ever detecting it. INP, by observing the entire interaction journey, gives a more faithful picture of the real experience.

Common technical causes of a poor INP:

• Heavy or poorly optimized JavaScript that blocks the browser's main thread.
• Too many third-party scripts running at once (chat widgets, ads, tracking tools).
• Complex processing triggered directly on click without being broken down into smaller tasks.
• Interface components that needlessly recompute the entire page on every interaction.

CLS: visual stability while loading

CLS (Cumulative Layout Shift) measures unexpected movement of visible elements while a page loads. It's the well-known phenomenon where a visitor is about to click a button or link, and an element that just finished loading (often an image, an ad, or a font) pushes all the content down, causing a click on the wrong element.

This shift isn't just annoying, it can have direct consequences: an accidental click on an ad, a form filled in the wrong field, or simply the impression of an unfinished site that makes people leave.

Common technical causes of a poor CLS:

• Images or videos without dimensions defined in advance in the code, which push content around as they load.
• Ads or third-party widgets inserted dynamically without reserved space.
• Custom fonts that replace a default font with a different size, shifting the text.
• Content injected dynamically at the top of the page (banner, notification) without space planned for it in advance.

Why these metrics exist: real experience, not abstract performance

It's easy to see Core Web Vitals as a purely technical SEO criterion. Their origin is actually different: Google introduced them to objectively quantify aspects of user experience that were previously hard to measure in a standardized way at scale.

A site could be fast by older criteria (total load time) while still delivering a frustrating experience: content that appears in fits and starts, interactions that don't respond, a layout that jumps around. Core Web Vitals try to capture these concrete frustrations rather than relying on a single, overall speed measurement that often masked these problems.

How to measure Core Web Vitals

Two categories of data exist, and it's worth distinguishing between them:

PageSpeed Insights combines both: it shows field data if the site gets enough traffic to appear in CrUX, along with a systematic lab analysis and detailed technical recommendations. Google Search Console offers a "Core Web Vitals" report that groups the site's pages by status (good, needs improvement, poor) based on real field data.

As for the exact thresholds to hit for each metric, Google publishes reference values that it updates regularly as usage patterns and standards evolve. Rather than trusting a fixed number found in an article, it's better to check PageSpeed Insights directly, which shows the thresholds in effect at the time of the test and places your site relative to them.

What to remember

• LCP measures how fast the main content renders, INP measures responsiveness to interactions, CLS measures visual stability while loading.
• These metrics reflect a concrete user experience, not just abstract technical performance.
• INP replaced FID to better capture responsiveness across an entire visit, not just the first click.
• The most common technical causes involve unoptimized images, heavy JavaScript, and elements without reserved dimensions.
• Exact thresholds change regularly: check PageSpeed Insights rather than a dated figure found elsewhere.
• Field data (real) and lab data (simulated) are complementary for diagnosing and monitoring a site.

Frequently asked questions

What are the three Core Web Vitals? LCP measures how long it takes the largest visible element on screen to render, INP measures how responsive the site is to user interactions (clicks, taps), and CLS measures visual stability, i.e. whether page elements shift unexpectedly while the page loads.

What thresholds should each metric hit? Google publishes reference thresholds for each metric, but these are updated regularly and shouldn't be treated as fixed. The most reliable way to check them is to run your site through PageSpeed Insights, which shows the thresholds in effect at the time of the test.

Why did INP replace FID? FID (First Input Delay) only measured the delay before the very first interaction. INP evaluates responsiveness across the entire visit, which better reflects the real experience of a user who interacts with a page multiple times, not just on arrival.

What's the difference between field data and lab data? Field data (from CrUX, the Chrome User Experience Report) comes from real visitors who used Chrome on the site. Lab data comes from a simulated test under controlled conditions. The two are complementary: field data reflects reality, lab data lets you diagnose issues before publishing.

Are Core Web Vitals a Google ranking factor? Yes, Google folds them into its page experience ranking signals, but they're just one factor among many, alongside content relevance and numerous other criteria. A good score alone isn't enough to rank well.

In summary

Understanding LCP, INP, and CLS lets you diagnose concrete problems instead of being stuck with a score you don't understand. If your site racks up "needs improvement" or "poor" signals across these three metrics, VeryAppi builds websites designed from the outset to limit these technical issues, rather than fixing them after the fact.