Core Web Vitals for SEO in 2026: LCP, INP and CLS Fixes

Core Web Vitals are Google's three user experience metrics: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). A page passes when, at the 75th percentile of real visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less and CLS is 0.1 or less. Google's ranking systems do use them, but as part of page experience, not as a dominant factor. Relevant, helpful content still wins first, and good vitals help most when several pages are equally useful.

This guide covers the thresholds as of September 2026, what Google Search Central actually says about rankings, the difference between field and lab data, concrete fixes for each metric and a measurement workflow you can repeat every release. Every threshold and claim below is checked against web.dev, Chrome's developer docs and Google Search Central. In my work as an IT manager and web developer, the sites I look after get the most out of this when performance is treated as routine maintenance rather than a one-off project.

Key takeaways

• Thresholds: LCP 2.5 s or less, INP 200 ms or less, CLS 0.1 or less, measured at the 75th percentile of page loads, separately for mobile and desktop.
• Rankings: Google says Core Web Vitals "are used by our ranking systems," but also that there's "no single signal" for page experience and that good scores don't guarantee top positions.
• Field data decides. Search Console and the PageSpeed Insights assessment use real Chrome user data from CrUX over a 28-day window. Lighthouse lab scores are for debugging.
• INP replaced FID as a Core Web Vital on 12 March 2024. If your tooling still reports FID, it's out of date.
• Most fixes are small: fetchpriority="high" on the LCP image, never lazy-loading it, breaking up tasks longer than 50 ms, and reserving space for images, ads and fonts.

What are the Core Web Vitals thresholds in 2026?

The thresholds haven't changed since INP joined the set. Google's Web Vitals overview sets the "good" targets, and the thresholds methodology article defines the full bands:

The important detail is the 75th percentile. Google recommends measuring "the 75th percentile of page loads, segmented across mobile and desktop devices." In plain terms, three out of four visits need to hit the target. The methodology article explains the choice: it "strikes a reasonable balance" between covering most visits and not letting a handful of outliers skew the result. Your median might look fine while a slow quarter of mobile users drags the page into "needs improvement."

A few details about how each metric is calculated matter when you're debugging:

• INP looks at interactions over the whole visit, not only the first one. Per web.dev's INP article, on pages with many interactions it ignores one of the highest for every 50, so a single random hiccup doesn't define the score.
• CLS isn't a simple sum. web.dev's CLS article describes "session windows," bursts of shifts less than 1 second apart and up to 5 seconds long, and CLS is the largest burst. Shifts within 500 ms of a tap, click or keypress are excluded, because the user expects something to move.
• FID is gone. The INP launch announcement confirms INP became a Core Web Vital on 12 March 2024, and FID support was being deprecated in Chrome's tools, with 9 September 2024 given as the transition deadline.

How does Google use Core Web Vitals for ranking?

Google uses them, but it's careful not to oversell them. The page experience documentation on Google Search Central says: "Core Web Vitals are used by our ranking systems. We recommend site owners achieve good Core Web Vitals for success with Search." The same page adds three qualifications worth reading closely:

• "There is no single signal. Our core ranking systems look at a variety of signals that align with overall page experience."
• "Google Search always seeks to show the most relevant content, even if the page experience is sub-par."
• Good results in Search Console or third-party tools don't guarantee "that your pages will rank at the top of Google Search results."

Google also says page experience can contribute to success when "there is lots of helpful content available" for a query. That's the practical reading: vitals act as a tiebreaker between pages of similar quality, not a way to outrank a more relevant page.

So don't promise anyone a ranking jump from shaving 300 ms off LCP. Do fix poor scores, because they're a real user problem, and slow, jumpy pages lose visitors whether or not Google is watching.

Field data vs lab data: which numbers count?

Field data is what counts for Search. Lab data is how you find and fix the causes.

The PageSpeed Insights documentation spells this out. Its field data comes from CrUX and covers "the previous 28-day collection period." Its lab data comes from Lighthouse running "a simulated load of a page on a single device and fixed set of network conditions." A URL or origin "passes the Core Web Vitals assessment if the 75th percentiles of all three metrics are Good."

CrUX has limits you should know. Per Chrome's CrUX methodology, a page must be publicly discoverable and "sufficiently popular" to be included, and data only comes from Chrome users on desktop and Android who've opted into usage statistics and history sync. Chrome on iOS doesn't contribute. For a low-traffic site, you may see origin-level data only, or nothing at all. That's normal, and it's a good reason to collect your own field data too (more on that below).

The Search Console Core Web Vitals report groups similar URLs together and labels each group by its worst metric. Its own example: a mobile URL with poor CLS and needs-improvement LCP is labeled poor. When you fix something, "Start Tracking" begins a 28-day validation, so expect results in weeks, not hours.

How do you improve LCP?

Get the LCP resource discovered early, give it priority and keep it small. web.dev's LCP guide splits LCP into four parts, and knowing which one is slow tells you what to fix:

1. Time to First Byte (TTFB): how long the HTML takes to arrive.
2. Resource load delay: the gap between TTFB and the browser starting to fetch the LCP image.
3. Resource load duration: how long the image itself takes to download.
4. Element render delay: the gap between the image arriving and it appearing on screen.

On a well-optimized page, the guide suggests roughly 40% of LCP goes to TTFB, about 40% to downloading the resource, and under 10% each to the two delays. "The vast majority of the LCP time should be spent loading the HTML document and LCP source." If load delay or render delay is large, the browser is waiting on something it shouldn't be.

The fixes that follow from that:

• Never lazy-load the LCP image. The guide puts it bluntly: "Never lazy-load your LCP image." Keep loading="lazy" for images below the fold. The original version of this post recommended lazy loading without that caveat, and it's the mistake I see most often.
• Set fetchpriority="high" on the image likely to be your LCP element, for example <img src="hero.avif" fetchpriority="high" width="1200" height="600" alt="...">. The Fetch Priority article reports that on Google Flights, LCP improved "from 2.6s to 1.9s" with this change. It's a hint, not a command, so use it on one or two resources, not everything.
• Preload what the HTML can't reveal. If the LCP image is a CSS background or injected by JavaScript, the browser can't find it early. Add <link rel="preload" as="image" href="...">, or better, render it as a normal <img> in server-rendered HTML.
• Use modern formats and a CDN. The LCP guide recommends WebP or AVIF, a content delivery network and efficient cache policies to cut download time.
• Reduce TTFB. web.dev's TTFB article says most sites should aim for 0.8 seconds or less. TTFB isn't a Core Web Vital, but it's the first part of LCP. Edge rendering and caching help here; I cover one approach in building a portfolio site on Cloudflare Workers, Hono and D1, and the D1 guide explains how read replicas cut database round trips.

How do you improve INP?

Keep the main thread free so the browser can respond to input quickly. web.dev's INP guide splits each interaction into input delay (waiting for the main thread), processing duration (your event handlers) and presentation delay (rendering the next frame). Each has its own fix.

• Break up long tasks. Per web.dev's long tasks guide, "any task that takes longer than 50 milliseconds is a long task." While one runs, clicks and taps wait.
• Yield with scheduler.yield(). Inside a long loop or handler, await scheduler.yield() pauses your work so the browser can handle input, and your code resumes ahead of unrelated queued tasks. As of September 2026, that guide lists support in Chrome 129+, Edge 129+ and Firefox 142+, but not Safari. Use a small wrapper that falls back to new Promise(r => setTimeout(r, 0)) when globalThis.scheduler?.yield isn't available.
• Do less in event handlers. The INP guide says "the best general advice in optimizing event callbacks is to do as little work as possible in them." Update the visible UI first, then yield before analytics calls or other background work.
• Avoid layout thrashing. Reading a layout property such as offsetHeight right after writing styles forces synchronous layout. Batch reads, then writes.
• Keep the DOM small. "Large DOMs do require more work to render than small DOMs." The CSS content-visibility property lets the browser skip rendering off-screen sections.
• Cut script evaluation during load. Remove unused third-party tags and defer what isn't needed for the first interaction.

Your choice of platform plays a part here. Plugin-heavy CMS installs often load scripts on every page whether they're needed or not, which is one of the trade-offs I cover in custom CMS vs WordPress architecture.

How do you improve CLS?

Reserve space for everything before it loads, and never push existing content down without the user asking. web.dev's CLS guide lists the usual causes:

• Images without dimensions. A frequent cause. Set width and height attributes so the browser can reserve the right area, or use CSS aspect-ratio for responsive media.
• Ads, embeds and late content. Reserve their slot with min-height or aspect-ratio. If you can't reserve space, place late-loading content lower in the viewport, and avoid inserting banners above content that's already visible.
• Web fonts. A fallback font swapping for the web font can move text. The font best practices article calls font-display: optional the most performant option, with text render "delayed for no longer than 100ms" and no swap shift, though the web font may not show if it arrives late. If you need swap, use metric overrides such as size-adjust on the fallback to shrink the shift, and serve WOFF2. Preload fonts sparingly, since preloading takes bandwidth from other resources.
• Animations. Animate transform (for example translate) instead of top or left. Composited animations don't move other elements.
• Back and forward button visits. web.dev's bfcache article explains that pages restored from the back/forward cache appear instantly. Don't use the unload event (use pagehide), and keep Cache-Control: no-store for genuinely sensitive pages.

A Core Web Vitals measurement workflow

This is the loop I'd suggest for any site, from a brochure site to an internal tool.

1. Start in Search Console. Open the Core Web Vitals report, check mobile first, and note which URL groups are poor or need improvement and which metric is responsible.
2. Confirm in PageSpeed Insights. Test a representative URL from each group. Look at the field section first to see whether URL-level data exists, then at the origin data.
3. Collect your own field data. Add Google's web-vitals library (onLCP, onINP, onCLS) and send results to your analytics with navigator.sendBeacon. The attribution build tells you which element was the LCP and which interaction was slow.
4. Diagnose in the lab. Reproduce the problem in the Chrome DevTools Performance panel with CPU and network throttling. Use the LCP subparts to find the slow phase, and look for long tasks around slow interactions.
5. Fix one thing at a time. Apply the relevant fix from the sections above and re-run the lab test so you know which change helped.
6. Release and validate. Deploy, then click "Start Tracking" on the issue in the Search Console Core Web Vitals report. Allow the 28-day window before judging.
7. Guard against regressions. Run Lighthouse in CI for key templates and watch your own field data after each release. A single new tag or unsized banner can undo months of work.

Core Web Vitals checklist

• The LCP image is in the initial HTML, not lazy-loaded, and has fetchpriority="high".
• Images are served as AVIF or WebP, correctly sized, from a CDN with long cache lifetimes.
• TTFB is 0.8 s or less for key pages, using caching or edge rendering where it helps.
• Render-blocking CSS is small, and non-critical JavaScript is deferred.
• No main-thread task runs longer than 50 ms during common interactions; long work yields.
• Every image, video, iframe and ad slot has reserved dimensions.
• Fonts are WOFF2, with font-display chosen deliberately and fallback metrics adjusted.
• No unload listeners, so pages stay eligible for bfcache.
• Real-user metrics are collected with web-vitals, and Search Console is checked monthly.

If you're planning where your site runs, hosting and CDN choices set your TTFB floor. My overview of modern cloud infrastructure on AWS, Azure and GCP covers those options.

FAQ

Are Core Web Vitals a ranking factor in 2026?

Yes, but not a dominant one. Google Search Central says Core Web Vitals "are used by our ranking systems," while also stating there's no single page experience signal and that Google shows the most relevant content even when page experience is poor. Treat good vitals as a tiebreaker and a user experience win, not a replacement for helpful content.

Why does PageSpeed Insights give me a good score while Search Console says poor?

The Lighthouse score in PageSpeed Insights is lab data from one simulated test. Search Console uses field data from real Chrome users over the previous 28 days, judged at the 75th percentile. Real visitors on slower phones and networks often have a worse experience than the lab simulation. Go by the field data, and use the lab report to find causes.

What replaced First Input Delay?

Interaction to Next Paint (INP) replaced FID as a Core Web Vital on 12 March 2024. INP measures responsiveness across all interactions during a visit, not only the first one. A good INP is 200 ms or less, and anything over 500 ms is poor.

My site has no Core Web Vitals data in Search Console. What should I do?

That usually means the site doesn't have enough eligible Chrome traffic for CrUX. Pages must be public and popular enough, and only opted-in Chrome users on desktop and Android are counted. Add the web-vitals library to collect your own real-user data, and use Lighthouse and DevTools to find problems in the meantime.

Should I lazy-load all images to improve LCP?

No. Lazy-load images below the fold, but never the LCP image. Lazy-loading it delays the fetch and makes LCP worse. Load the hero image eagerly, give it fetchpriority="high" and set its width and height so it doesn't cause layout shift.

If you'd like help auditing Core Web Vitals on your own site, you can get in touch here.