Core Web Vitals explained: LCP, INP and CLS

Core Web Vitals are three standardized performance metrics that Google uses to measure how real users experience the speed and visual stability of a webpage. The three metrics are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Passing all three thresholds signals to Google that your site delivers a high-quality page experience, supporting your organic search rankings and lowering bounce rates.

Google evaluates these metrics using real-world browsing data collected from Chrome users over rolling 28-day windows. Here is what each metric measures, why it matters, and how to fix common failures.

Summary of Core Web Vitals thresholds

Google categorizes performance into three tiers: Good, Needs Improvement, and Poor. To pass the Core Web Vitals assessment, a page must achieve the "Good" threshold at the 75th percentile of user visits across both mobile and desktop devices.

Metric 1: Largest Contentful Paint (LCP)

Largest Contentful Paint measures perceived loading speed. It marks the point in the page loading timeline when the main content element is rendered on the screen.

What counts as the LCP element?

The LCP element is typically the largest visual block above the fold:

• A large hero image or banner graphic.
• A featured product image on an ecommerce page.
• An embedded video poster frame.
• A prominent block of introductory headline and paragraph text.

If your hero image takes four seconds to load over a 4G mobile connection, your LCP score is four seconds, which falls into the "Poor" category.

Common causes of poor LCP

• Slow server response times (high Time to First Byte) caused by budget hosting, unoptimized database queries, or uncompressed server responses.
• Render-blocking CSS and JavaScript files that stop the browser from painting text and images until the code downloads completely.
• Oversized image files served in legacy formats like uncompressed JPEG or PNG.
• Client-side rendering frameworks that delay content display until complex JavaScript libraries finish executing.

Practical fixes for LCP

1. Compress and convert all hero images to modern WebP or AVIF formats.
2. Avoid using loading="lazy" on hero images or elements positioned above the fold.
3. Preload your critical LCP image using <link rel="preload" as="image" href="..."> in your document head.
4. Upgrade hosting or connect a content delivery network (CDN) to ensure server response times stay well below 800 milliseconds.
5. Minify CSS stylesheets and remove unused styling rules.

For a broader walkthrough on loading speed techniques, see our guide on page speed SEO.

Metric 2: Interaction to Next Paint (INP)

Interaction to Next Paint measures page responsiveness throughout a visitor entire session. In March 2024, Google replaced First Input Delay (FID) with INP.

While FID only measured the delay of a visitor very first click, INP records the response latency of every tap, click, or keystroke during a visit. It reports the worst interaction latency (excluding rare outliers) so pages remain responsive throughout the entire session.

What interactions does INP measure?

• Clicking on navigation links or mobile menu hamburger icons.
• Tapping buttons, such as "Add to Cart" or "Submit Form."
• Interacting with accordion menus, tabs, or modal dialogs.
• Typing into text search inputs or form fields.

Scrolling and hovering do not count toward INP.

Common causes of poor INP

• Main-thread congestion caused by long JavaScript tasks that monopolize the browser processor.
• Bulky third-party scripts, including customer chat widgets, heatmap trackers, and advertising pixels.
• Complex DOM structures with thousands of nested elements that force expensive style recalculations when users click.
• Heavy JavaScript frameworks updating large portions of the page simultaneously on every click.

Practical fixes for INP

1. Break up long JavaScript tasks that exceed 50 milliseconds using setTimeout or requestIdleCallback.
2. Delay loading non-essential third-party scripts until after user interaction occurs.
3. Replace heavy JavaScript libraries with native browser APIs or lightweight alternatives.
4. Optimize form inputs and filter menus so feedback renders immediately on the screen before complex background data processing begins.

Metric 3: Cumulative Layout Shift (CLS)

Cumulative Layout Shift measures visual stability. It evaluates whether visible elements unexpectedly shift positions while a visitor is reading or attempting to click a button.

We have all experienced visiting a website on a mobile phone, reaching to tap a link, only for an image or banner ad to load late and shift the button downward, causing an accidental click on the wrong element. CLS penalizes this frustrating behavior.

How Google calculates CLS

Google calculates layout shift by multiplying the impact fraction (the percentage of the screen that moved) by the distance fraction (how far the unstable element moved). The resulting score is a unitless decimal. A score of 0 indicates complete stability, while scores above 0.1 require remediation.

Common causes of poor CLS

• Images and video embeds published without explicit width and height dimensions in the HTML.
• Dynamic advertisements, newsletter signup bars, or cookie banners that inject themselves above existing content after the page renders.
• Web fonts that load late and cause layout shifts when switching between system fallback fonts and custom web fonts (Flash of Invisible Text or Flash of Unstyled Text).

Practical fixes for CLS

1. Always set explicit width and height attributes on <img> and <iframe> elements so the browser reserves space before files download.
2. Use CSS aspect-ratio properties on responsive media containers to prevent content jumping.
3. Reserve fixed container space for dynamic elements like advertising banners, alert bars, and cookie notices.
4. Preload primary web fonts and set font-display: swap or font-display: optional in your CSS styling to minimize font swapping shifts.

Field data vs lab data: which one counts?

When diagnosing Core Web Vitals, it is critical to distinguish between lab data and field data:

• Lab data is simulated during tests using tools like Google Lighthouse in Chrome DevTools. It tests performance under controlled conditions with simulated network throttling.
• Field data comes from real Chrome users browsing your site on diverse mobile phones, cellular connections, and locations. This data powers the Chrome User Experience Report (CrUX).

Google uses field data, not lab data, to determine ranking signals. If your website passes simulated tests on a high-speed desktop connection in your office, but real mobile users on cellular networks experience layout shifts and slow response times, your site will fail Google assessment.

You can view your actual field data directly inside Google Search Console under the Core Web Vitals report. Learn how to monitor these metrics in our Google Search Console guide.

How Core Web Vitals affect organic rankings

Core Web Vitals serve as a supporting ranking signal within Google page experience framework. They work as an algorithmic tiebreaker. If two competing websites offer equally helpful and authoritative answers to a search query, Google will rank the faster, more stable page higher.

Passing Core Web Vitals will not push thin, low-quality content to page one. However, failing them means a slower, jumpier page, and more visitors give up before it loads. To audit your full site architecture alongside speed metrics, use our technical SEO checklist and run an SEO audit.

Getting professional technical optimization

Diagnosing and repairing deep JavaScript bottlenecks, server caching rules, and layout shift triggers often requires professional developer support.

At Techcelerant, our team audits Core Web Vitals and eliminates the technical barriers holding your pages back. Explore our fixed-price SEO services or view our packages on our pricing page. You can also contact our team to schedule a detailed Core Web Vitals performance review for your website.