Core Web Vitals (2026): LCP, INP, and CLS Explained Without Jargon

Everyone talks about how your website needs to be fast. But "fast" is imprecise. Core Web Vitals are Google's attempt to measure it concretely, and since 2024, the numbers from these metrics determine whether your site feels modern or sluggish.

What are Core Web Vitals?

Core Web Vitals are three metrics that together describe how fast and pleasant a web page feels:

• LCP (Largest Contentful Paint) — how long it takes for the largest visible element to load.
• INP (Interaction to Next Paint) — how long it takes for the page to react when a user clicks or types.
• CLS (Cumulative Layout Shift) — how much content moves around while the page is loading.

Google measures these via real user data from Chrome (collected in the Chrome User Experience Report, CrUX) and uses the results as part of the "Page Experience" ranking signal.

LCP: Largest Contentful Paint

What it measures: The time from when the user clicks a link until the largest visible element is displayed in the viewport. On most pages, this is the hero image, a video, or a large heading.

Thresholds:

• Good: under 2.5 seconds
• Needs improvement: 2.5 to 4 seconds
• Poor: over 4 seconds

Common causes of poor LCP:

• Large, unoptimised images (especially hero images above the fold)
• Slow server (high TTFB)
• Render-blocking JavaScript or CSS
• Images without loading="eager" on the LCP element (yes, this is the opposite of the usual recommendation)
• Font loading that delays the text

What works:

• Compress images (WebP or AVIF format, correct dimensions).
• Use <img fetchpriority="high"> on the LCP image.
• Preload critical resources: <link rel="preload" as="image" href="/hero.webp">.
• Reduce CSS to the critical above-the-fold portion, and defer the rest.
• Use a CDN so images are delivered from closer to the user.

INP: Interaction to Next Paint

What it measures: How long it takes for the page to visually respond when the user clicks, types, or taps. The metric records the slowest interaction (or the 98th percentile for pages with many interactions) throughout the entire visit.

Thresholds:

• Good: under 200 ms
• Needs improvement: 200 to 500 ms
• Poor: over 500 ms

INP replaced FID (First Input Delay) in March 2024. FID only measured the first click and was often green even for heavy websites. INP is stricter because it tracks the entire visit.

Common causes of poor INP:

• Heavy JavaScript tasks that block the main thread
• Too many third-party scripts (chat widgets, tracking, A/B testing)
• Inefficient React/Vue components that re-render too often
• Large DOM trees (over 1500 elements on a single page)

What works:

• Break up long JavaScript tasks into smaller chunks (setTimeout, requestIdleCallback).
• Remove or lazy-load third-party scripts you don't need immediately.
• Reduce the DOM size (especially if you use heavy page builders).
• Use content-visibility: auto on heavy sections below the fold.
• Consider web workers for heavy logic.

CLS: Cumulative Layout Shift

What it measures: How much visible content shifts while the page is loading. The score is an accumulated value (measured over the session), where higher is worse.

Thresholds:

• Good: under 0.1
• Needs improvement: 0.1 to 0.25
• Poor: over 0.25

Common causes of poor CLS:

• Images without width and height attributes
• Ads or embeds that load in and push content down
• Font-swap that changes text size after rendering
• Content that is loaded dynamically above the fold

What works:

• Always set width and height on images and iframes (or use CSS aspect-ratio).
• Reserve space for ads and embeds with a minimum-height container.
• Use font-display: swap with a deliberately chosen fallback font that looks similar (subset of the same metrics).
• Don't insert new elements above existing content after rendering (use a toast/modal instead).

Lab data vs. field data: why it's important

When you open pagespeed.web.dev, you get two sets of numbers:

Lab data (Lighthouse): Google spins up a simulated device with a simulated network (4G, often 4x throttling) and measures everything on the spot. This is useful for debugging because it's reproducible, but it's not what Google uses for ranking.

Field data (CrUX): Real measurements from Chrome users who have visited your site over the last 28 days. This is what Google uses for ranking. The downside is that it takes time for changes to appear, and small sites don't get enough traffic to have field data.

Rule: fix based on lab data first, then verify with field data over the following weeks. If you don't have enough field data, use lab data as a proxy.

How to measure systematically

• Ad-hoc: pagespeed.web.dev on key pages.
• Continuous monitoring: Google Search Console has a dedicated Core Web Vitals report (which groups pages that pass/fail).
• Developer setup: The Chrome DevTools > Performance tab, or the web-vitals library to collect your own metrics and send them to your analytics.
• Real-time: WebPageTest for detailed flame graphs and waterfalls.

What I often see go wrong

• Everyone measures the homepage, nobody measures the product pages. The homepage is often optimised, while product and category pages are where users actually land, and where the problems lie.
• "Fast in lab, slow in field." The lab test runs from Google Cloud in the US on a simulated 4G connection. Real UK users are on actual 4G with latency and slow devices. Field data doesn't lie.
• Fixed LCP, broke INP. You add preloads, animations, and tracking to measure conversions, and INP silently collapses.
• CLS on mobile menus. Pages that look stable on desktop jump around violently on mobile because the menu renders late.
• No re-testing after a fix. You deploy a fix, celebrate, and let it regress again after the next feature release.

Case study: LCP from 4.8s to 1.9s in one week

An e-commerce store with solid organic traffic noticed that its rankings for several main categories were slowly but surely falling throughout Q1. Google Search Console showed that 68% of their pages had "poor" LCP.

Diagnosis: The hero banner on the category pages was a 1.4 MB PNG image, served without a CDN, without a lazy-loading hint, and without priority fetching.

The action: Converted the image to WebP (280 KB), added fetchpriority="high", set up Cloudflare in front of the host, and removed a third-party review script that was blocking rendering for 900 ms.

The result: Field data LCP dropped from a median of 4.8s to 1.9s over 14 days. As a side effect, INP improved from 340 ms to 190 ms. Within 6 weeks, three of the five main categories had ranked up by 1 to 3 positions.

Priority: what to fix first

You can't fix everything at once. This is how I prioritise:

1. LCP first. It often has the biggest impact and is usually the easiest to fix (image optimisation + CDN).
2. CLS next. It requires design/development attention but provides an immediate UX win.
3. INP last. This often requires deeper JavaScript refactoring. It's worth it, but it's more work.

Your action plan: Step-by-step

In summary: My take on Core Web Vitals

Core Web Vitals aren't the most important ranking factor, but they are one of the most tangible. Content and links are bigger levers, but Core Web Vitals are something you can actually influence in days, not months.

Bonus: everything you do to improve Core Web Vitals also improves your conversion rate. Google has measured that improvements in Core Web Vitals consistently correlate with increased engagement and sales, regardless of ranking.

Start with LCP. Fix your images. Add a CDN. See what happens in your field data over the next 14 days. Go from there.