Core Web Vitals in 2026: LCP, INP and CLS Targets and How to Fix Them

Maybe your Search Console report is full of “poor” URLs. Or a client keeps asking why their PageSpeed score is red. Here is the short version. The core web vitals 2026 targets are an LCP of 2.5 seconds or less, an INP of 200 milliseconds or less, and a CLS of 0.1 or less. All three are measured at the 75th percentile of real visits.

Passing them is worth doing, but it won’t save weak content. In this guide, I cover what each metric measures, where the numbers come from, how much Google says they count, and the fixes that move each one.

What Core Web Vitals Measure in 2026

Core Web Vitals are three user-experience metrics. Google treats them as the most important part of its wider Web Vitals programme. Each one covers a different part of what a visitor feels.

• Largest Contentful Paint (LCP) measures loading. It’s how long it takes for the biggest image or text block on the screen to appear.
• Interaction to Next Paint (INP) measures responsiveness. It’s how long the page takes to visibly react after someone clicks, taps or presses a key.
• Cumulative Layout Shift (CLS) measures visual stability. It’s how much content jumps around without warning while the page is in use.

Google keeps stable metrics steady. web.dev says a stable Core Web Vital won’t change more than once a year. So the targets below are the ones to plan for in 2026.

INP Replaced FID in March 2024

The biggest change in recent years was INP replacing First Input Delay (FID) on 12 March 2024. FID only measured the delay before the browser started handling the very first interaction. Most sites passed it easily.

INP is much stricter. It watches every click, tap and key press during the whole visit. It reports something close to the slowest one, ignoring one outlier for every 50 interactions. It also measures the full journey: the input delay, the time your event handlers (the code that runs on a click) take, and the time until the next frame is painted. Scrolling, hovering and zooming are not counted.

If an old audit, plugin or agency report still talks about FID, it’s out of date. PageSpeed Insights and Search Console have used INP since the switch. When I review an old audit, this is one of the first things I look for.

The “Good” Thresholds at the 75th Percentile

These are the thresholds published on web.dev and used in Search Console’s Core Web Vitals report.

The 75th percentile is the part people often miss. A page passes only if at least three in four real visits meet the target. Mobile and desktop are judged separately.

So a page that loads in 1.8 seconds on your office fibre can still fail LCP. It fails if a quarter of your visitors use mid-range phones on patchy mobile data. You are graded on your slower users, not your fastest ones.

The full breakdown of each metric and how the thresholds work is in web.dev’s Web Vitals overview.

How CLS Is Actually Scored

CLS is not a running total of every shift on the page. Shifts are grouped into “session windows”. These are bursts of shifts less than a second apart, capped at five seconds. Your score is the worst window.

Shifts within 500 milliseconds of a click, tap or key press don’t count, because users expect the page to change when they act. Shifts after scrolling do count. That’s why lazy-loaded ads that push text down hurt you.

Field Data vs Lab Data: CrUX, PageSpeed Insights and Search Console

Most confusion about Core Web Vitals comes from mixing up two kinds of data. Google uses only one of them for Search.

Field Data (What Counts)

Field data comes from the Chrome User Experience Report (CrUX). It collects anonymous timings from real Chrome users who have opted in. It covers a rolling 28-day window, so it changes slowly.

• PageSpeed Insights shows CrUX data at the top of the report. It shows data for the exact URL if it has enough traffic, or else for the whole origin (your whole domain). If neither has enough data, you won’t see a real-user section at all.
• Search Console’s Core Web Vitals report groups similar URLs together. It gives each group a status based on its worst metric, and it splits mobile from desktop. Only indexed URLs appear, and it shows a sample, not every page.

Low-traffic sites often have no field data. That doesn’t mean they are penalised. It means Google has nothing to judge, so you should rely on lab testing and good practice.

Lab Data (What Helps You Debug)

Lab data comes from Lighthouse. It runs one simulated page load on a set device and network. It appears in the lower half of PageSpeed Insights and in Chrome DevTools.

Lighthouse can’t measure INP, because nobody is clicking anything. It reports Total Blocking Time (TBT) instead. web.dev calls TBT a lab stand-in for INP. A high TBT usually points to the same JavaScript problems that cause poor INP.

This is why a page can score 95 in Lighthouse and still fail in Search Console. The lab run is one clean visit. The field data is thousands of messy ones. When they disagree, I trust the field data and use the lab to find causes.

If you want to watch trends more closely between monthly reviews, my guide to building reports with Search Console’s AI report builder shows how to pull performance data into quicker custom views.

How Much Core Web Vitals Matter for Rankings

Google’s ranking systems do use Core Web Vitals, and Google’s documentation recommends good scores. But they are part of the wider page experience picture. They are not a big ranking lever on their own.

Google has said the same three things for a long time:

• Its systems try to show the most relevant content even when the page experience is below par. A slow page that answers the query best can still beat a fast, thin one.
• Page experience tends to matter when many pages are similarly helpful. Think of it as an edge in close contests, not a way to jump past stronger content.
• Good scores don’t guarantee top positions. Chasing a perfect score only for SEO is unlikely to be a good use of time.

Google’s own summary is on its Core Web Vitals and Search page. For how this signal sits next to relevance and quality, see how Google Search works in 2026. For the content side, which usually carries more weight, see my explanation of E-E-A-T.

In my opinion, the business case for fixing vitals is stronger than the ranking case. Slow loading, laggy buttons and jumping layouts cost you enquiries and sales, whatever your position.

How to Fix LCP

Start by finding your LCP element. In PageSpeed Insights, the diagnostics name it. In Chrome DevTools, the Performance panel marks it. It’s usually a hero image, a featured image or a large heading.

Google’s web.dev guidance splits LCP into four parts. Knowing which part is slow tells you what to fix.

1. Time to First Byte (TTFB): how long the server takes to start sending HTML.
2. Resource load delay: the gap between TTFB and the browser starting to download the LCP image.
3. Resource load duration: how long the image itself takes to download.
4. Element render delay: the time between the image arriving and it being painted.

Server and TTFB

Everything waits on the first byte. So a slow server makes every other fix less useful. TTFB is not a Core Web Vital itself, but it sits inside LCP.

• Use full-page caching so most visitors get ready-made HTML instead of a fresh database query.
• Put a CDN (a network of servers around the world) in front of the site, especially if visitors are spread across countries.
• Remove redirect chains on key landing pages. Each hop adds a round trip.
• If uncached pages are slow, look at hosting resources, slow database queries and heavy plugins before you buy a bigger server.

Images

Image problems usually show up as load delay or load duration.

• Make the LCP image easy to find in the HTML. A hero image set as a CSS background, or added by JavaScript, is found late.
• Never lazy-load the LCP image. loading="lazy" belongs only on images below the fold. This is a mistake I see very often.
• Add fetchpriority="high" to the LCP image so the browser downloads it before less important files.
• Serve modern formats such as WebP or AVIF, compress sensibly, and use srcset so phones don’t download desktop-sized files.

<img src="hero-1200.webp"
     srcset="hero-600.webp 600w, hero-1200.webp 1200w"
     sizes="100vw"
     width="1200" height="600"
     fetchpriority="high"
     alt="Team reviewing a site audit">

Fonts and Render-Blocking Files

Sometimes the LCP element is a heading, or the image arrives but isn’t painted. Then render-blocking CSS, JavaScript and web fonts are the usual cause. “Render-blocking” means the browser must wait for these files before it can show the page.

• Inline the small amount of CSS needed for the top of the page, and load the rest without blocking.
• Add defer to scripts that don’t need to run before the page appears.
• Self-host fonts in WOFF2. Preload the one or two weights used above the fold. Use font-display: swap so text shows in a fallback font right away.
• Cut the number of font families and weights. Every extra file competes with your LCP image.

How to Fix INP

Poor INP is almost always a JavaScript problem. My guide to Interaction to Next Paint goes deeper on finding slow interactions. When the browser’s main thread is busy with a long task, it can’t respond to a tap until that task finishes.

web.dev treats any task over 50 milliseconds as a long task. A few of those together are enough to push an interaction past 200 milliseconds on a mid-range phone.

Find the Slow Interactions

1. Check which page groups fail INP in Search Console, then open a typical URL from that group.
2. In Chrome DevTools, open the Performance panel and turn on CPU throttling to copy a slower phone.
3. Record yourself using the page like a visitor: open the menu, apply a filter, add to basket, submit a form.
4. Look for long tasks around each interaction and note which script they come from.

Fix Long Tasks and Heavy Scripts

• Audit third-party scripts. Chat widgets, heatmaps, A/B testing tools and multiple tag managers often cause much of the main-thread work. Remove what nobody uses. Delay the rest until after load or the first interaction. In my experience, this is the quickest INP win on most sites.
• Break up long tasks. Split large chunks of work so the browser can handle input in between.
• Do less in event handlers. Update what the user sees first. Do analytics calls and other background work afterwards.
• Keep the DOM lean. The DOM is the page’s structure of elements. Very large pages with thousands of elements make every style and layout update slower.

Here is a simple pattern for yielding to the main thread so the visual update happens first:

button.addEventListener('click', async () => {
  showLoadingState();          // visible feedback straight away
  await new Promise(r => setTimeout(r, 0)); // let the browser paint
  runFilterLogic();            // heavier work afterwards
  sendAnalyticsEvent();
});

Chromium browsers also support scheduler.yield(), which does the same job more cleanly. Keep a fallback like the one above for browsers that don’t have it.

How to Fix CLS

Layout shifts happen when the browser places content, then has to move it because something arrived late with no space saved for it. The fix is nearly always to save that space in advance.

• Images and video: always include width and height attributes, or a CSS aspect-ratio. Then the browser knows the box size before the file loads.
• Ads, embeds and iframes: give each slot a fixed minimum height that matches its most common size. An empty slot is better than a late ad that shoves the article down.
• Banners and notices: cookie bars, promo strips and “subscribe” boxes should sit on top of the page or in saved space. They shouldn’t be inserted above existing content.
• Web fonts: when a custom font swaps in, different letter widths can reflow paragraphs. Preloading the font and picking a fallback with similar sizing reduces the jump. The CSS size-adjust descriptor helps here.
• Animations: animate with transform and opacity, not properties like top, height or margin, which move nearby content.

Here’s a quick test I like. Load a key page on your phone with a slow connection and scroll gently while it loads. If the text you are reading moves, you have found a CLS source.

The WordPress Angle

WordPress sites tend to fail Core Web Vitals for the same few reasons. Most of them can be fixed without a rebuild. My guide to speeding up WordPress goes further.

• Keep core updated. Since WordPress 6.3, core adds fetchpriority="high" to the image it thinks is most likely the LCP image. It also stops lazy-loading images likely to be on screen. Themes or plugins that change image output can undo this, so check the final HTML.
• Watch out for hero images set as backgrounds in page builders. They are often found late, and core’s image handling doesn’t apply to them. Where you can, switch to a normal image block.
• Use page caching. A good caching plugin or host-level cache is the biggest single TTFB win on most WordPress sites.
• Stop plugins loading scripts everywhere. Form, slider and gallery plugins often load JavaScript and CSS on every page. Asset-management plugins let you unload them where they aren’t used. This helps both LCP and INP. I usually see this problem on sites that have collected plugins over many years.
• Be careful with optimisation plugins. “Delay all JavaScript” settings can help INP and TBT. But test menus, forms and checkout afterwards.
• Know what 6.8 added. WordPress 6.8 turned on speculative loading by default. It prefetches a page when a visitor starts clicking a link (logged-in users excluded). It can make the next page feel faster with no setup.

How Long Until Fixes Show Up

CrUX uses a rolling 28-day window, so improvements appear slowly. If you fix an issue today, the field numbers in PageSpeed Insights will move towards the new value over the next four weeks.

In Search Console, once you have fixed an issue, you can open it in the Core Web Vitals report and start validation tracking. This starts a 28-day check period. The issue passes if no URL in that group shows the problem during it. Validation doesn’t trigger recrawling or reindexing.

For faster feedback while you wait, check lab data after each change. You can also use real-user monitoring through a RUM tool or Google’s open-source web-vitals JavaScript library. It reports the same metrics from your own visitors.

Where to Start: A Priority Order

If you have a long list of failing URLs, this is the order I work in:

1. Fix whole templates, not single URLs. Search Console groups similar pages, so one template fix can clear hundreds of URLs.
2. Start with the templates that bring the most traffic or revenue: product pages, service pages, top blog posts.
3. Do mobile first. It usually fails earlier and has most visits.
4. Fix TTFB before LCP, because a slow server limits how fast anything else can be.
5. Leave cosmetic Lighthouse warnings until the field metrics pass.

Conclusion: Core Web Vitals 2026 in Practice

The core web vitals 2026 targets haven’t moved: LCP at 2.5 seconds, INP at 200 milliseconds and CLS at 0.1, all at the 75th percentile of real visits. Measure with field data, debug with lab data, and fix by template, not page by page.

I see a passing score as the baseline for a good site, not a ranking shortcut. Once your key templates are green, put the time you save into making those pages more useful. Or move on to the next technical job with my guide to which schema markup still earns rich results.