Core Web Vitals in 2026: Fixing LCP, INP and CLS, with a PageSpeed Walkthrough

TL;DR: Core Web Vitals are three measurements of real visits: Largest Contentful Paint (LCP, loading, good at 2.5 s or less), Interaction to Next Paint (INP, responsiveness, good at 200 ms or less) and Cumulative Layout Shift (CLS, visual stability, good at 0.1 or less). Google judges each at the 75th percentile of visits. In PageSpeed Insights, the field data at the top is what counts; the lab score below it is for finding causes. Most LCP problems are a slow or late-discovered hero image, most INP problems are long JavaScript tasks, and most CLS problems are images and embeds without reserved space. Test your page with our free Speed test.

Speed advice has a way of turning into a list of 40 things to try. This article is shorter on purpose: three metrics, what each one is really measuring, and the handful of causes behind most failures we see in audits.

What are Core Web Vitals?

Core Web Vitals are three metrics Google uses to describe how a page feels to real visitors: how fast the main content appears, how quickly the page responds to input, and how much the layout jumps around. Largest Contentful Paint (LCP) is the time until the largest image or text block in the viewport has rendered. Interaction to Next Paint (INP) is roughly the slowest response to a click, tap or key press during the visit. Cumulative Layout Shift (CLS) scores how much visible content moves unexpectedly. Google publishes the definitions and thresholds on web.dev. Each metric is judged at the 75th percentile of page loads from the Chrome UX Report, separately for mobile and desktop. So a page "passes" LCP when at least three out of four visits get the main content within 2.5 seconds, which means the slowest quarter of visits can be slow without failing the page, and the median visit is not the bar.

The thresholds have not changed since the metrics were introduced. The metric set has: INP replaced First Input Delay on 12 March 2024.

Do Core Web Vitals affect rankings?

They do, and less than performance vendors suggest. Google's Core Web Vitals documentation says they are used by its ranking systems as part of page experience, and in the same breath says great page experience does not replace relevant content. In practice they act as a tiebreaker between pages that answer a query about equally well.

The better reason to care is people. A slow page loses visitors before they read anything, and a page that jumps as it loads gets misclicks. Those costs show up in conversions whatever the ranking effect is.

How do you read a PageSpeed Insights report?

PageSpeed Insights puts two different things on one screen, and most confusion comes from mixing them up.

The top section, titled "Discover what your real users are experiencing", is field data from the Chrome UX Report: 28 days of real Chrome visits, with LCP, INP and CLS at the 75th percentile and a pass or fail for the Core Web Vitals assessment. A toggle switches between this URL and the whole origin. If your page has too little traffic, this section says there is not enough data, and you only get the lab test.

The lower section, "Diagnose performance issues", is a Lighthouse lab test: one simulated load on a throttled mid-range phone, producing the famous 0 to 100 performance score. It is useful for finding causes and useless as a verdict, because it varies from run to run and never measures INP (it has no real user to interact with). Read the field data to know whether you have a problem, then read the lab diagnostics to find out why.

How do you fix a slow LCP?

Start by finding the LCP element. The PageSpeed diagnostics name it, and it is usually a hero image or a large heading. Then break the time into the four parts that web.dev's LCP optimisation guide uses: time to first byte, the delay before the browser starts loading the resource, the time to download it, and the delay before it renders. Whichever part is biggest is where the fix is.

The most common case we see is a hero image the browser discovers late, because it is set as a CSS background or injected by JavaScript, or because it is marked loading="lazy". Put it in the HTML as an <img>, tell the browser it matters, and give it sizes it can choose from:

<img
  src="/images/hero-800.webp"
  srcset="/images/hero-800.webp 800w, /images/hero-1600.webp 1600w"
  sizes="100vw"
  width="1600" height="900"
  alt="Studio mixing desk with the lights on"
  fetchpriority="high">

If the LCP element is text, the usual culprit is a web font that blocks rendering. Self-host the font, preload the one file the first screen needs, and use font-display: swap. If time to first byte is the biggest part, the fix is on the server: caching, a CDN, or static generation instead of building each page on request.

How do you fix a poor INP?

INP fails when the browser's main thread is busy when a visitor clicks. JavaScript runs on that thread, and while one task is running the browser cannot paint the response. Long tasks, anything over 50 milliseconds, are the cause almost every time. Chrome DevTools' Performance panel shows them as red-flagged blocks; record a click on the slow control and look at what runs.

The fixes, from the INP optimisation guide:

• Do less on each interaction. Update what the visitor sees first and defer the rest.
• Break long tasks up by yielding to the main thread between chunks of work.
• Remove or delay third-party scripts that run on every interaction, such as chat widgets and heavy tag managers.
• Keep the DOM small, because every re-render and style recalculation scales with it.

Yielding looks like this. scheduler.yield() is available in Chromium browsers; the fallback covers the rest:

function yieldToMain() {
  if (globalThis.scheduler?.yield) return scheduler.yield();
  return new Promise((resolve) => setTimeout(resolve, 0));
}

async function saveForm(fields) {
  showSavingState();        // the visitor sees a response immediately
  await yieldToMain();
  validate(fields);
  await yieldToMain();
  sendAnalytics(fields);    // work nobody is waiting for goes last
}

How do you fix a high CLS?

Layout shift happens when something appears or changes size after the content around it has been drawn. Three causes account for most of it, according to web.dev's CLS guide and what we see in audits: images and videos without dimensions, embeds and ad slots that load late without reserved space, and web fonts that swap in with different metrics than the fallback.

Give every image and video width and height attributes (the browser uses them to reserve the right aspect ratio even with responsive CSS). Give embeds a container with a fixed aspect-ratio or min-height. For fonts, match the fallback to the web font so the swap does not reflow text:

@font-face {
  font-family: "Heebo Fallback";
  src: local("Arial");
  size-adjust: 104%;
}
body { font-family: "Heebo", "Heebo Fallback", sans-serif; }

And never insert banners, cookie notices or "related posts" above content that is already on screen. Overlay them, or reserve the space from the start.

What does a passing site look like?

A small business site does not need heroics to pass. Static or server-rendered HTML, self-hosted fonts, a preloaded hero image in WebP and a few kilobytes of JavaScript will usually put mobile LCP under a second in the lab and CLS close to zero, far inside the 0.1 "good" threshold. The sites that fail tend to fail for the same handful of reasons: a slider of full-size photos at the top, a chat widget and three tracking scripts loading before anything else, and web fonts that swap in late and push the text around. Our worked example walks through what fixing those looks like for a made-up dental clinic.

Watch page weight too. A common audit finding is a background video of a megabyte or more that makes up most of the home page's weight on desktop. It may not hurt LCP, if the LCP element is a preloaded image, but it is still waste on every visit. Passing Core Web Vitals and being efficient are related, not identical, and a good audit reports both.

A 30-minute Core Web Vitals check

1. Run your home page and your most important landing page through the free Speed test on mobile.
2. Read the field data first. Note which of LCP, INP and CLS fail, if any.
3. If there is no field data, treat lab LCP and CLS as estimates and ignore the headline score.
4. For LCP, find the element in the diagnostics and check it is a real <img>, not lazy-loaded, with fetchpriority="high".
5. For CLS, check every image has width and height and nothing is injected above the fold after load.
6. For INP, record the slowest interaction in Chrome DevTools and look for long tasks.
7. Re-test after each change, and remember field data takes up to 28 days to reflect a fix.

Core Web Vitals are one of seven categories in our audit, weighted at 10%. The full report measures them on every key page next to the other six, and the free SEO + GEO guide includes the checks you can run yourself.