Skip to content
Lexiik
performance

Core Web Vitals: LCP, INP, CLS — Google's SEO Metrics Explained

Last updated : February 17, 2026

Core Web Vitals are three metrics defined by Google to measure the quality of the user experience on a web page. Introduced in 2020 and integrated into Google's ranking algorithm in 2021 through the Page Experience update, they are now an official SEO factor. For e-commerce stores, understanding and optimizing these three indicators — LCP, INP, and CLS — has become just as important as content work or link building.

What Are Core Web Vitals?

Before Core Web Vitals, web page speed was measured by technical metrics like Time to First Byte (TTFB) or First Contentful Paint (FCP) — useful indicators for developers, but ones that didn't accurately reflect what a user actually experiences. Google wanted to bridge that gap by defining three metrics centered on perceived experience: how quickly does the main content appear? Does the page respond quickly to interactions? Does content shift unexpectedly?

These three questions map exactly to the three Core Web Vitals: LCP for loading speed, INP for responsiveness, and CLS for visual stability. Google collects this data in aggregate via Chrome (the Chrome User Experience Report, or CrUX) and uses it in its algorithm to reward pages that deliver a good user experience.

LCP — Largest Contentful Paint: How Fast Your Main Content Loads

LCP (Largest Contentful Paint) measures the time elapsed from when a page starts loading to when its largest visible element is fully rendered on screen. This element can be an image, a video tag, a block of text, or any other content in the visible area without scrolling (above the fold).

For e-commerce stores, the LCP is almost always determined by the main product image — the packshot photo that occupies a large portion of the screen at the top of the product page. This image is typically the heaviest on the page, and therefore the one that takes the longest to load. That's why LCP optimization in an e-commerce context focuses primarily on improving image delivery.

Good LCP

Under 2.5 seconds. Google considers the user experience satisfactory.

⚠️

LCP Needs Improvement

Between 2.5 and 4 seconds. The page is in the orange zone — improvements are needed.

Poor LCP

Over 4 seconds. Google penalizes the page in its search results.

The main causes of poor LCP on e-commerce stores are: oversized product images (unoptimized JPEG), slow hosting with a high TTFB, no CDN causing geographic latency, and lazy loading incorrectly applied to the main image. This last error is common: the loading="lazy" attribute should never be applied to the above-the-fold image, as it prevents the browser from quickly loading the very element Google uses to calculate LCP.

INP — Interaction to Next Paint: Page Responsiveness

INP (Interaction to Next Paint) replaced FID (First Input Delay) in March 2024 as the official Core Web Vital. Where FID only measured the response delay for the first interaction, INP measures the latency of all user interactions throughout the page's lifetime — clicks, taps on mobile, keyboard inputs — and takes the value at the 98th percentile.

In practical terms, INP measures the time between when the user interacts (for example, clicking an "Add to Cart" button) and when the browser visually displays the response to that interaction. If your JavaScript is heavy and monopolizes the browser's main thread, INP will be high: the page feels "frozen" or slow to react.

Good INP

Under 200 milliseconds. The interaction feels instant to the user.

⚠️

INP Needs Improvement

Between 200 and 500 milliseconds. The user perceives a slight delay.

Poor INP

Over 500 milliseconds. The interaction feels slow and sluggish.

For e-commerce stores, the main causes of poor INP are: excessive third-party JavaScript (chat widgets, analytics trackers, price comparison scripts), overly heavy event handlers, and large UI libraries loaded synchronously. Optimizing INP involves auditing and reducing non-essential JavaScript, and deferring the loading of third-party scripts until after user interaction.

CLS — Cumulative Layout Shift: Visual Stability of the Page

CLS (Cumulative Layout Shift) measures how much visible elements on the page shift unexpectedly during loading. Every time a visible element moves — text jumping because an image loads without reserved dimensions, an ad banner inserting itself and pushing content down — the CLS score increases.

A high CLS is especially frustrating on mobile: the user is about to tap a link, and just as their finger touches the screen, an image loads and shifts the content. They end up tapping a different link — sometimes "Add to Cart" when they meant to read the description. This is a degraded experience that Google penalizes.

Good CLS

Under 0.1. The page is visually stable during loading.

⚠️

CLS Needs Improvement

Between 0.1 and 0.25. Noticeable shifts affect the experience.

Poor CLS

Over 0.25. The page is unstable and penalized by Google.

The main cause of high CLS on e-commerce stores is the absence of explicit dimensions on images (width and height attributes in the HTML). When the browser parses the HTML and encounters an img tag without dimensions, it cannot reserve the necessary space in the layout. When the image loads and reveals its actual dimensions, the layout is recalculated and everything shifts. The fix is simple: always specify width and height on img tags, or use the CSS aspect-ratio property.

How Core Web Vitals Influence Google Rankings

Google has used Core Web Vitals as a ranking signal since June 2021. Technically, they are part of a broader signal called "Page Experience", which also includes mobile-friendliness, HTTPS security, and the absence of intrusive interstitial content. Google has clarified that quality content remains the dominant signal, but that Core Web Vitals can make the difference between two pages of equivalent quality.

In practice, Google evaluates Core Web Vitals through two data sources: field data collected anonymously via Chrome from real user visits, and lab data calculated by tools like Lighthouse under controlled conditions. Field data — aggregated in the Chrome User Experience Report (CrUX) — is what feeds the algorithm. A page must receive enough Chrome traffic to appear in CrUX; pages with little traffic are assessed at the domain or root URL level.

Mobile-first: Core Web Vitals Are Primarily Assessed on Mobile

Google prioritizes mobile data when evaluating Core Web Vitals in its algorithm. Mobile connections are slower and processors less powerful than on desktop. A store that achieves good desktop scores can still have poor mobile scores if its images are not optimized for 4G/5G networks.

Challenges Specific to E-Commerce

Online stores face several challenges that make optimizing Core Web Vitals particularly difficult. First, the volume of images: a store with 1,000 products and 5 photos each must manage 5,000 images, each of which needs to be optimized for size, format, and dimensions. Then there's the complexity of pages: product pages with galleries, carousels, zoom features, description tabs, customer review widgets, and variant configurators — all JavaScript components that can degrade INP.

  • Heavy product images without format optimization (unoptimized JPEG vs. WebP/AVIF)
  • Carousels and galleries with third-party JavaScript that blocks the main thread
  • Lazy loading misconfigured and applied to the hero image (degrades LCP)
  • Images without explicit width/height attributes in templates (degrades CLS)
  • Analytics and remarketing tracking scripts loaded synchronously (degrades INP)
  • Slow shared hosting with high TTFB impacting all Core Web Vitals

How Lexiik Improves Your Core Web Vitals

Lexiik primarily acts on LCP and CLS — the two Core Web Vitals most directly linked to images. For LCP, the Cloudflare CDN drastically reduces the delivery time of the main product image by serving it from a node geographically close to the visitor, with one-year cache headers. For CLS, Lexiik ensures that images served from the CDN maintain their original dimensions, allowing the browser to reserve the correct space before full loading.

Automatic conversion to WebP and AVIF reduces image size by 30 to 50% without any visible loss in quality, which not only speeds up LCP but also improves overall perceived performance metrics. On 4G mobile connections, going from a 400 KB JPEG to a 120 KB WebP image can bring LCP down from 3.5 seconds to under 1.5 seconds.

How to Check Your Core Web Vitals Scores

Several tools allow you to measure and monitor your Core Web Vitals. Google Search Console is the reference tool for real field data (CrUX): the "Page Experience" section shows the percentage of URLs on your site rated as "Good experience", "Needs improvement", or "Poor experience", with a breakdown by metric. This is the tool that reflects what Google actually sees.

  • Google Search Console (search.google.com/search-console): real field data, by URL or URL group
  • PageSpeed Insights (pagespeed.web.dev): field data + lab data for a specific URL
  • Google Lighthouse (built into Chrome DevTools): lab data only, useful for development
  • Chrome DevTools > Performance tab: detailed analysis of rendering events and interactions
  • web.dev/measure: Google tool for a quick online analysis

Field Data vs. Lab Data

Lab data (Lighthouse) measures the page under simulated conditions on a simulated network. Field data (CrUX) reflects real visits from real users. These two sources can diverge significantly. For SEO, field data is what matters. For diagnosing issues, lab data is more useful as it provides precise detail on the causes.