Core Web Vitals Guide: How to Improve LCP, INP & CLS to Rank Higher

Core Web Vitals are Google's official set of real-world performance metrics that measure how users actually experience a webpage — covering loading speed, responsiveness, and visual stability. Introduced as a ranking signal in 2021 and continuously refined since, they have become one of the most consequential technical factors in modern SEO. In 2026, with 47% of websites still failing at least one threshold, mastering Core Web Vitals is a genuine competitive advantage.

Core Web Vitals sit within the broader discipline of technical SEO — if you have not yet addressed crawlability, HTTPS, structured data, and site architecture, those foundations should be established before optimising for performance metrics.

This guide covers every dimension of Core Web Vitals: what each metric measures and why Google chose it, how scoring and percentile thresholds work, which tools to use for measurement, and — most importantly — the actionable, high-impact fixes for LCP, INP, and CLS that move you from "Poor" to "Good."

What are Core Web Vitals?

Core Web Vitals are a subset of Google's broader Web Vitals initiative — a programme designed to provide unified guidance on the signals that matter most for delivering a great user experience on the web. While the broader Web Vitals set includes additional metrics like Time to First Byte (TTFB) and First Contentful Paint (FCP), Core Web Vitals are the three metrics Google has elected to use directly as ranking signals.

The three Core Web Vitals are:

• LCP (Largest Contentful Paint) — measures loading performance: how quickly the largest visible element on the screen renders.
• INP (Interaction to Next Paint) — measures responsiveness: how quickly the page reacts to every user interaction throughout the visit.
• CLS (Cumulative Layout Shift) — measures visual stability: how much page content unexpectedly shifts around during loading.

These three metrics were selected because they each capture a distinct dimension of user frustration: waiting for content to appear, waiting for actions to register, and watching the page jump around unexpectedly. Together they paint a comprehensive picture of real-world page quality.

Why do Core Web Vitals matter for SEO?

Core Web Vitals became an official Google ranking signal with the Page Experience update in June 2021. Since then, their influence on rankings has grown steadily. In competitive SERPs where two pages offer comparable content quality, Core Web Vitals function as a tiebreaker — and the page with the better user experience wins.

The business case goes beyond rankings. Research from SparkToro analysing 150 million search queries found that pages with "Good" Core Web Vitals scores had a 31.4% higher click-through rate from organic search compared to pages with "Poor" scores. A 100ms improvement in LCP has been shown to increase conversions by 0.6–1.2%, according to agency data collected across hundreds of client sites.

There is also a compounding effect. Faster, more stable pages produce lower bounce rates, longer dwell times, and higher engagement rates — all signals that reinforce Google's confidence that the page is worth ranking. Investing in Core Web Vitals is therefore not purely a technical exercise; it is a direct revenue lever.

How does Core Web Vitals scoring work?

Each Core Web Vitals metric is scored at the 75th percentile of real user visits — meaning the score reported is the value that 75% of visits meet or beat. This design intentionally targets your worst-performing quarter of users, not your median experience. A fast experience for most users does not count if a significant fraction still receives a poor one.

To achieve an overall "Good" Core Web Vitals assessment for a URL, all three metrics — LCP, INP, and CLS — must individually reach the "Good" threshold at the 75th percentile. If any single metric fails, the URL's overall status is determined by its worst-performing metric, regardless of how strong the others are.

Google measures these scores at the URL level first, then at the URL group level (groups of structurally similar pages), and finally at the origin level (the entire domain) if there is insufficient data at lower levels. The scores you see in Google Search Console reflect aggregated real-user data from Chrome browsers — the Chrome User Experience Report (CrUX) dataset.

Field data vs. lab data: What counts for rankings?

Field data (also called real-user monitoring or RUM data) is collected from actual Chrome browser sessions visiting your site. It is aggregated into the CrUX dataset and is the only data source that affects Google rankings. Field data reflects the true distribution of user experiences across different devices, browsers, and network conditions.

Lab data is generated by simulating a page load under controlled conditions using tools like Lighthouse, PageSpeed Insights, or WebPageTest. It is reproducible and deterministic, making it excellent for diagnosing specific issues — but it does not directly affect your rankings. A perfect Lighthouse score does not guarantee good field data if real users are on slower devices or networks.

The practical implication: always cross-reference lab data findings with field data before prioritising fixes. An issue that appears in lab testing but does not show up in your CrUX data may have minimal real-world impact. Conversely, field data failures should be investigated even if your Lighthouse scores look healthy — slower users and devices may be experiencing problems your lab simulation does not capture.

LCP: Largest Contentful Paint explained

LCP measures the time from when the page first starts loading to when the largest content element in the viewport has fully rendered. The LCP element is almost always one of: a <img> image, a <video> poster image, a block-level element containing text (like an <h1> or <p>), or a CSS background image loaded via url().

Google chose LCP because it closely correlates with when a user perceives the page as "loaded." Earlier metrics like First Contentful Paint (FCP) could be triggered by a small spinner or a single character — LCP targets what actually matters: the dominant visual content.

LCP is currently the hardest Core Web Vital to pass, with only 59% of mobile URLs achieving a "Good" score. The primary bottleneck is almost always image loading — specifically, large hero images that are discovered late, fetched from a distant server, and served in inefficient formats.

Key LCP sub-components to diagnose

• Time to First Byte (TTFB): How quickly the server responds. High TTFB delays everything downstream.
• Resource load delay: Time between receiving the first byte of HTML and the browser discovering the LCP resource.
• Resource load duration: How long it takes to download the LCP resource itself.
• Element render delay: Time between the LCP resource finishing download and the element actually rendering on screen.

INP: Interaction to Next Paint explained

INP officially replaced First Input Delay (FID) as a Core Web Vital in March 2024. It measures the latency of all user interactions on a page — clicks, taps, and keyboard inputs — throughout the entire page lifecycle. The INP score for a URL is the worst interaction latency recorded across the visit (with outliers removed for very long sessions).

FID only measured the delay before the browser could begin processing the first interaction — it ignored how long that processing actually took. INP measures the complete interaction cost: from the user's input to the next visual frame the browser paints in response. This makes INP a significantly stricter and more honest measure of whether a page feels responsive.

High INP scores are almost always caused by long tasks on the main thread — JavaScript execution that blocks the browser from responding to user input. Third-party scripts (analytics, advertising, chat widgets) are a common culprit, as are large, inefficient event handlers and frameworks that do excessive DOM manipulation on every interaction.

Understanding the INP interaction flow

• Input delay: Time the browser waits before it can start processing the interaction (due to other tasks running).
• Processing time: Time spent executing event handlers and rendering logic triggered by the interaction.
• Presentation delay: Time between the browser finishing processing and actually painting the next frame to the screen.

CLS: Cumulative Layout Shift explained

CLS measures the visual instability of a page — specifically, how much content unexpectedly jumps around during or after loading. The score is calculated from individual layout shift events, each scored by multiplying the fraction of the viewport the shifted element occupied by the distance it moved. CLS accumulates all such shifts throughout the page visit.

The user experience impact is tangible and often infuriating: a button moves just as you are about to tap it, causing an accidental click; a headline jumps down as an ad banner loads above it; a form field shifts away from the keyboard as a cookie banner appears. These moments damage trust and increase task failure rates.

The most common causes of CLS are images and iframes without declared dimensions, dynamically injected content inserted above existing content, web fonts that cause a Flash of Unstyled Text (FOUT) or Flash of Invisible Text (FOIT), and animations that use CSS properties (like top, left, margin) that trigger layout recalculation instead of the GPU-composited transform property.

How to measure Core Web Vitals

Use the right tool for each type of measurement:

Start with Google Search Console for a site-wide triage — it shows which URL groups are failing and which metric is the bottleneck. Then use PageSpeed Insights or Lighthouse on specific URLs to identify the exact technical causes. The Web Vitals Chrome Extension is invaluable for debugging CLS issues in real-time as you scroll and interact with a page.

How to improve LCP

LCP improvements typically require addressing image delivery, server response times, and render-blocking resources simultaneously. The following fixes are listed in approximate order of impact:

<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

How to improve INP

INP improvements require identifying and reducing long tasks on the JavaScript main thread. The browser cannot respond to user input while it is busy executing long tasks — any task over 50ms is considered "long" by the browser and will cause perceptible input delay.

async function processData(items) {
  for (const item of items) {
    processItem(item);
    await scheduler.yield(); // Yield to the browser after each item
  }
}

How to improve CLS

Most CLS issues are predictable and preventable. The root cause is almost always content that the browser did not know about in advance, causing it to re-flow the layout after the initial render:

new PerformanceObserver((list) => {
  list.getEntries().forEach(entry => {
    if (!entry.hadRecentInput) {
      console.log('CLS shift:', entry.value, entry.sources);
    }
  });
}).observe({type: 'layout-shift', buffered: true});

Core Web Vitals on mobile vs. desktop

Google measures Core Web Vitals separately for mobile and desktop users. The same three metrics apply to both, but mobile scores are consistently harder to achieve — mobile devices have slower processors, less RAM, and are more likely to be on variable or congested network connections.

Since Google uses mobile-first indexing, your mobile Core Web Vitals are the most critical to optimise. A page that scores "Good" on desktop but "Poor" on mobile will still be penalised in rankings. Prioritise your mobile performance analysis and test on mid-range Android devices, not just on a high-end iPhone or your development laptop.

Chrome DevTools' Device Mode with network throttling (Slow 4G or Fast 3G) provides a reasonable simulation of real mobile conditions. For even more accurate testing, use WebPageTest's real mobile device testing feature on a Moto G Power — one of the most commonly owned Android devices globally and Google's own testing baseline.

Core Web Vitals for e-commerce

E-commerce sites face specific Core Web Vitals challenges. Product pages typically have multiple high-resolution images, complex JavaScript for variant selectors and cart functionality, and numerous third-party tracking scripts — all of which combine to degrade performance.

The most impactful e-commerce-specific improvements are:

• Lazy-load below-the-fold product images but never the primary product image (LCP element).
• Implement a product image CDN with automatic WebP/AVIF format negotiation and on-the-fly resizing.
• Audit your tag manager for unused pixels — marketing and retargeting scripts are a leading source of INP failures on product and category pages.
• Reserve space for product reviews and UGC loaded via API calls — these are a common CLS source.
• Test your checkout funnel separately — heavily scripted checkout pages often have the worst Core Web Vitals scores on a site.

Core Web Vitals for WordPress sites

WordPress powers a significant share of the web and has dedicated tooling for Core Web Vitals optimisation. The following plugins and settings address the most common WordPress-specific issues:

• WP Rocket or LiteSpeed Cache: Full-stack performance plugins that handle caching, CSS/JS minification, lazy loading, and critical CSS generation with minimal configuration.
• Imagify or ShortPixel: Bulk image compression and automatic WebP/AVIF conversion for your entire media library.
• Perfmatters: Script manager for disabling unnecessary WordPress scripts (emojis, embeds, jQuery migrations) on a per-page basis.
• GeneratePress or Kadence: Lightweight themes with clean, minimal code that score well on Core Web Vitals out of the box — avoid page builders that inject excessive CSS and JavaScript.
• Disable or defer Gutenberg block library CSS if you are not using the block editor on the front end.

For WordPress specifically, the most common INP culprit is excessive JavaScript from page builders, slider plugins, or WooCommerce variant scripts running on the main thread. Conduct a JavaScript audit with Chrome DevTools Coverage tab to identify unused code before purchasing additional plugins.

How Core Web Vitals interact with other ranking factors

Core Web Vitals are one signal among hundreds in Google's ranking algorithm. The hierarchy, from most to least influential, is roughly: content relevance and quality, E-E-A-T signals (Experience, Expertise, Authoritativeness, Trustworthiness), backlinks and domain authority, Core Web Vitals and page experience, and other signals like mobile-friendliness and HTTPS. Excellent Core Web Vitals will not overcome thin content or a lack of authoritative backlinks — but poor Core Web Vitals can prevent great content from achieving its full ranking potential.

Pages ranking at position 1 are statistically 10% more likely to pass all three Core Web Vitals thresholds compared to pages at position 9. This correlation has strengthened year over year as Google continues refining how page experience signals influence rankings. The practical implication: in competitive niches where the top results all have strong content and authority, Core Web Vitals can be the decisive differentiator.

Core Web Vitals and conversion rates

The relationship between page speed and conversion rate is well-documented. Google's own data indicates that as page load time increases from one second to three seconds, the probability of a bounce increases by 32%. At five seconds, that probability rises to 90%. For every 100ms improvement in LCP, e-commerce conversion rates improve by 0.6–1.2%.

CLS failures are particularly damaging to conversions because they cause accidental clicks — a user intending to click one button hits a different one because the layout shifted. This causes frustration, increases task abandonment, and erodes brand trust. In e-commerce, accidental add-to-cart or checkout errors from CLS can directly inflate cart abandonment rates.

Technical speed optimisation is therefore not just an SEO task — it is a direct business investment with a measurable return on investment. Frame Core Web Vitals improvements to stakeholders in terms of conversion rate improvements and revenue per visitor, not just rankings and traffic.

How long before improvements show in rankings?

Google updates the CrUX dataset that powers Core Web Vitals scores on a rolling 28-day window. This means a fix you deploy today will not be fully reflected in your scores for approximately four weeks — the old data gradually phases out as new data accumulates. There is no way to accelerate this process; you cannot request a CrUX refresh.

Once your field data improves, ranking changes typically follow within one to two crawl cycles. For frequently crawled pages on authoritative domains, this can be as fast as one to two weeks after the CrUX data improves. For less frequently crawled or lower-authority pages, allow six to ten weeks from the time of implementation before assessing the ranking impact.

Core Web Vitals audit checklist

Use this checklist when auditing a site for Core Web Vitals issues: