How to Improve Core Web Vitals: A Practical Guide for 2026

Featured photo by Đức Trịnh via Unsplash

If you want to know how to improve core web vitals, the first thing to understand is that one of the three metrics changed fundamentally in March 2024. INP (Interaction to Next Paint) replaced First Input Delay (FID) as the responsiveness metric. That swap matters more than most SEO guides acknowledge. Two years later, the data tells a sobering story: 43% of websites still fail the INP threshold of 200 milliseconds, making it the most commonly failed Core Web Vital across the web.

This guide covers how to audit, fix, and monitor all three metrics — without pretending it’s simple when it isn’t.

What the Three Metrics Actually Measure

Core Web Vitals are three Google metrics that measure real user experience: Largest Contentful Paint (LCP) measures loading speed (good: under 2.5 seconds), Interaction to Next Paint (INP) measures responsiveness (good: under 200 milliseconds), and Cumulative Layout Shift (CLS) measures visual stability (good: under 0.1).

The passing threshold isn’t an average. To pass the Core Web Vitals, at least 75% of your visitors need to have a ‘good’ LCP, INP, and CLS score in the Google CrUX dataset on the URL level. That distinction matters when you’re trying to understand why a page looks fine in your own browser but fails in Search Console.

INP’s scope is also worth clarifying. INP captures every interaction — clicks, taps, key presses — throughout the full page lifecycle and reports the worst interaction at the 75th percentile, making it far harder to game and far more representative of actual user experience. FID only measured the very first interaction. A site could pass FID while still feeling sluggish on every subsequent click.

How to Measure Your Core Web Vitals Before Fixing Anything

Photo via Pixabay

You need both lab data and field data. Lab data (from Lighthouse, PageSpeed Insights) runs a simulation. Field data (from CrUX, Search Console) reflects what real users on real devices actually experience. Always concentrate on field Core Web Vitals over Lighthouse metrics and scores. The Performance Score of Lighthouse is a broad measure of that lab test and often does not correlate with field Core Web Vitals.

Google Search Console shows Core Web Vitals reports based on real user data from Chrome browsers. It groups URLs by status (Good, Needs Improvement, Poor) and identifies which metrics are failing. That’s your baseline. Start there before running any tool.

PageSpeed Insights (PSI) assesses the performance of web pages on both mobile and desktop, offering suggestions for optimization by analyzing lab and real-world data. It’s free, requires no account, and will tell you exactly which element is causing your LCP failure. For most non-technical site owners, PSI + Search Console covers everything needed to identify the problem.

One thing nobody mentions: Google evaluates Core Web Vitals separately for mobile and desktop. A page can pass on desktop but fail on mobile (or vice versa). Since Google uses mobile-first indexing, your mobile CWV scores are typically more important for rankings. Run both. Most teams only check desktop.

How to Improve Core Web Vitals: Fixes by Metric

LCP — The Loading Problem

Poor LCP almost always traces back to a handful of root causes. Common causes of poor LCP include slow server response times, render-blocking JavaScript and CSS, slow resource load times, and client-side rendering delays.

LCP under 2.5 seconds requires systematic optimization: image preloading, critical CSS inlining, font preloading with display swap, and server-side rendering are the four highest-impact fixes for slow LCP scores. If your LCP element is a hero image (which it usually is on blog posts and homepages), preloading that image is typically the fastest win.

Improve server response time by upgrading hosting to faster infrastructure, implementing server-side caching, using a Content Delivery Network (CDN) to serve content from locations closer to users, and optimizing database queries that slow down page generation. Shared hosting is often the real bottleneck, not the images.

INP — The Responsiveness Problem

INP is the hardest metric to fix, and it requires a different type of diagnosis. INP failures almost always trace back to JavaScript. Start by checking for third-party scripts — analytics, chat, ads — that might be blocking the main thread.

While LCP and CLS have well-established fix patterns (preload images, add dimensions, inline critical CSS), INP demands a fundamental shift in how developers think about JavaScript architecture: break long tasks, defer non-critical work, yield to the main thread during interactions, and minimize DOM complexity.

The practical version of that: audit every third-party script on your site. Analytics platforms, live chat widgets, retargeting pixels — each one competes for main thread time. Remove what you don’t actively use. Defer what you do. INP failures are concentrated on pages that have heavy JavaScript interactions, checkouts, landing pages with forms, and filter-heavy listing pages. Prioritize those page types first.

CLS — The Layout Stability Problem

CLS below 0.1 demands explicit dimensions everywhere: every image, video, iframe, and ad slot needs explicit width and height attributes. Font-display swap and reserved space for dynamic content eliminate the remaining layout shift sources.

The most common CLS culprits on real sites: images uploaded without declared dimensions, fonts that load late and reflow text, and ad slots that expand after the page renders. Product and category pages tend to struggle most with CLS from dynamic content loading. If you run an e-commerce site, check those templates first.

The Tools Worth Using (And What Each One Actually Does)

Where Semrush Fits Into This Workflow

Semrush’s Site Audit tool flags Core Web Vitals issues across your entire domain — not just a single URL. For teams managing more than a handful of pages, that’s the difference between systematic improvement and whack-a-mole fixes. According to multiple pricing sources, Semrush’s Pro plan costs $117.33/month billed annually or $139.95/month billed monthly.

The honest limitation: Semrush’s audit data is lab-generated, not pulled from CrUX real-user data. That means a page that passes in the Semrush audit can still fail in Google Search Console if real users on slower mobile devices are having a different experience. Use Semrush to find issues at scale, then validate with PageSpeed Insights field data before deciding what to prioritize.

For deeper SEO analysis alongside performance work, Semrush pairs well with a technical SEO audit workflow that treats CWV as one layer of a broader site health review — not the only thing worth optimizing.

The One Mistake That Undoes All the Work

Fixing Core Web Vitals once and moving on. CWV scores are based on a rolling 28-day CrUX window. A single bad deploy — a new third-party script, a CMS update that adds render-blocking CSS, an ad tag that shifts layout — can push a passing site back into the red within weeks.

A sudden INP spike after a deploy, a gradual LCP creep as images grow, or a CLS regression from a new ad script — you want to know about these before they affect your 28-day CrUX window and ranking. Set up alerts in Search Console. Run PageSpeed Insights on key templates after every major update.

Review third-party scripts quarterly since vendors frequently update their code, sometimes introducing performance problems. That Google Analytics update your developer applied in the background three months ago? It might be what’s failing your INP right now.

Who This Works For

• Site owners on WordPress who have never run a PageSpeed Insights test — the free tool alone will surface 80% of your issues
• In-house marketing teams responsible for SEO who need to brief a developer with specific, fixable problems
• E-commerce sites where checkout pages and product listings carry the most INP risk
• Content publishers with large page counts who need Semrush or a similar tool to audit at scale
• Agencies managing multiple client sites who need systematic monitoring, not one-off audits

Who Should Wait

• Sites with fewer than 1,000 monthly visits — Google needs enough CrUX data to even generate a CWV assessment; you may not have field data yet
• Teams whose pages are already passing all three metrics — time better spent on content and links
• Anyone planning a full site rebuild in the next 90 days — fix performance in the new build, not the current one
• Solo bloggers on budget WordPress hosting who aren’t monetizing through organic traffic — the hosting problem will cap your results regardless of other optimizations

The Role of Content-Level SEO Alongside Technical Performance

Core Web Vitals are a ranking signal, but they’re not the only one. While content relevance remains the most important ranking factor, Core Web Vitals can serve as a tiebreaker when two pages have similar content quality. Passing all three metrics on a page with weak content won’t move you up the SERP. But failing them on a page with strong content can hold you back.

If you’re working on both dimensions simultaneously, pairing a technical performance fix cycle with a content optimization tool like Surfer SEO makes sense. Surfer’s Content Editor won’t help your INP score — it’s not designed to — but it addresses the content quality side of the equation that CWV alone can’t fix. According to Surfer’s current pricing page, the Essential plan starts at $99/month billed monthly, or $79/month on annual billing.

For a broader view of the tools that affect SEO performance across both technical and content dimensions, see our best AI tools section and our guide to choosing the right SEO platform for your team size.

Frequently Asked Questions

Does passing Core Web Vitals guarantee higher rankings?

Core Web Vitals are one of many ranking factors. Fixing them won’t overcome poor content, weak backlinks, or other SEO issues. However, when competing against similar pages, better Core Web Vitals provide a ranking advantage. Think of them as a tiebreaker that helps you win when content quality is comparable.

What’s the fastest single fix for LCP?

Preloading your LCP image element is typically the highest-impact, lowest-effort change. Add a <link rel='preload'> tag in the HTML head pointing at your hero image. This tells the browser to fetch it before it would otherwise discover it during HTML parsing. Follow that with image format optimization to WebP and compression — both changes can be made without touching your site’s code architecture.

My INP is failing but I can’t find any slow JavaScript. Where should I look?

Start by checking for third-party scripts — analytics, chat, ads — that might be blocking the main thread. Tools like Chrome DevTools’ Performance panel can show you which scripts are running long tasks. If the site is built on a heavy page builder, that’s often the root cause — it’s generating JavaScript overhead that keeps the main thread busy.

Can I improve Core Web Vitals without involving a developer?

For LCP and CLS, often yes — image optimization, adding dimensions to images, and optimizing fonts are changes that can be made without a rebuild. INP is harder. If it’s caused by third-party scripts, you may be able to defer or remove them. If it’s caused by a fundamentally heavy page builder generating excessive JavaScript, there’s a ceiling to how much you can improve it without addressing the underlying build.

How long does it take for Core Web Vitals fixes to show up in Google Search Console?

Search Console CWV data is based on a 28-day rolling window of real user data from Chrome browsers. That means improvements you make today won’t fully register in the report for up to four weeks. Don’t expect overnight changes — make your fixes, verify improvement in PageSpeed Insights field data, then monitor Search Console weekly for the trend to shift.

The concrete next step: Open Google Search Console right now, navigate to Experience → Core Web Vitals, and identify the one metric with the highest count of ‘Poor’ URLs. That’s your starting point. Run PageSpeed Insights on three of those URLs — specifically the mobile version — and look for the pattern. Nine times out of ten, the fix is the same across all three pages.