To fix Core Web Vitals, start by auditing your site with Google PageSpeed Insights to see real field data for LCP, INP, and CLS. Then target each failing metric specifically: compress and preload hero images to fix LCP, break up JavaScript tasks longer than 50ms to fix INP, and set explicit dimensions on images and embeds to fix CLS.
That’s the short version. The longer, more honest version is that “fixing” Core Web Vitals isn’t a one-and-done task – it’s a diagnostic process, and the fix that works for a slow server is completely different from the fix for a jumpy layout.
This guide walks through exactly how to audit your site, fix each of the three Core Web Vitals metrics one at a time, and validate that your fixes actually stuck once Google Search Console catches up with real user data. We’ll also cover the parts most guides skip: why your score can drop without you touching anything, how Google’s newer bfcache and prerendering techniques can fix LCP and CLS at the same time, and a real scoring framework for deciding which pages to fix first.
Everything here reflects hands-on audit work across WordPress, Shopify, and custom-built sites – not a copy-paste checklist.
What Does It Mean to “Fix” Core Web Vitals?
Core Web Vitals are three specific metrics Google uses to measure how a real visitor experiences your page: how fast it loads, how quickly it responds to input, and how visually stable it stays while loading. “Fixing” them means getting all three into Google’s “Good” range based on real user data – not just a clean test in a lab tool.
The Three Metrics and Their Pass/Fail Thresholds
Each metric has a clear Good, Needs Improvement, and Poor range:
| Metric | Good | Needs Improvement | Poor |
| LCP (Largest Contentful Paint) | ≤2.5s | ≤4s | >4s |
| INP (Interaction to Next Paint) | ≤200ms | ≤500ms | >500ms |
| CLS (Cumulative Layout Shift) | ≤0.1 | ≤0.25 | >0.25 |
A page only counts as “Good” overall when all three metrics hit the Good threshold for at least 75% of real visits. One poor metric drags the whole page down, even if the other two are excellent.
Field Data vs. Lab Data – Why They Can Disagree
Lab data comes from a simulated test – Lighthouse running your page once, in a controlled environment. Field data comes from real people loading your page on their actual phones, over their actual internet connection, from the Chrome User Experience Report (CrUX).
These two can tell completely different stories. A page can score 100/100 in a lab test and still fail its real Core Web Vitals assessment, because the lab test never accounts for a visitor on a slow 3G connection or an older phone. Google’s ranking and reporting decisions are based on field data, not the lab score – so that’s where your attention should go first.
How Do You Audit Your Site for Core Web Vitals Issues?
You can’t fix what you haven’t measured. Start every audit here.
Using PageSpeed Insights Correctly
Enter your URL into PageSpeed Insights and look at the top of the report first – that’s your field-data Core Web Vitals assessment, pass or fail. The performance score further down the page is lab data, useful for diagnosis but not the number that decides your assessment.
Test both mobile and desktop separately. Mobile scores are almost always worse, and since Google indexes primarily from your mobile experience, that’s the version that matters most.
Reading Your Search Console Core Web Vitals Report
Search Console’s Core Web Vitals report groups your pages by template, not by individual URL – it shows you patterns across your whole site rather than one page at a time. Look at the “Why URLs aren’t considered good” table first; it’s sorted by impression count, so the URLs at the top affect the most real traffic.
Click into any issue to see example URLs, then run one of them through PageSpeed Insights for a detailed breakdown of what’s actually causing the failure.
Origin Groups and “No Data” Situations Explained
If you check a specific page and see “Not enough data” or “Insufficient CrUX data,” that doesn’t necessarily mean nothing is being tracked. Google groups similar URLs together into URL groups, and if a specific group doesn’t have enough real visits to report reliably, Search Console rolls that data up into a broader origin group – essentially your whole domain’s aggregate performance.
This explains a confusing pattern many site owners hit: a brand-new or low-traffic page shows no individual data, but your domain-wide Core Web Vitals status still reflects something. The origin group exists specifically so Google can still form a meaningful judgment even when one page alone doesn’t have enough visits to measure. If you’re auditing a new site section, check the origin-level report rather than assuming a single quiet page means nothing is happening.
How Do You Fix Largest Contentful Paint (LCP)?
LCP is the metric most sites struggle with, and it’s usually the one with the biggest visible payoff once fixed.
Make Your LCP Image Discoverable and Prioritized (With a Before/After Example)
Google’s own performance data shows a huge share of poor-LCP pages load their hero image late – not because the image itself is slow, but because the browser doesn’t discover it early enough. Here’s what that looks like in practice.
Before (a common mistake):
<img data-src=”hero.jpg” class=”lazyload” alt=”Hero banner”>
This pattern uses data-src instead of src, meaning JavaScript has to run before the browser even knows this image exists. That delay gets added directly onto your LCP time.
After (fixed):
<link rel=”preload” as=”image” href=”hero.jpg” fetchpriority=”high”>
<img src=”hero.jpg” fetchpriority=”high” alt=”Hero banner”>
This version puts the image URL directly in the HTML so the browser’s preload scanner finds it immediately, and fetchpriority=”high” tells the browser to download it before less important resources. That single change alone commonly shaves a full second or more off LCP on image-heavy pages.
Compress and Preload Hero Images
Beyond discoverability, the image’s file size still matters. Convert hero images to WebP or AVIF – both offer meaningfully smaller file sizes than JPEG or PNG at the same visual quality. Never apply lazy loading to your hero or above-the-fold image; lazy loading is meant for images the user hasn’t scrolled to yet, and applying it to your LCP element actively delays the metric you’re trying to fix.
Upgrade Hosting and Add a CDN
If your server takes too long to respond in the first place, no amount of image optimization will fully fix LCP – everything downstream is waiting on that first response. A Content Delivery Network (CDN) caches your content on servers physically closer to your visitors, cutting the distance data has to travel and directly improving Time to First Byte (TTFB).
Check your current TTFB in PageSpeed Insights’ diagnostics section. If it’s regularly above 600-800ms, that’s usually a hosting or server-configuration problem worth solving before you spend more time on frontend tweaks.
Aim for Instant Navigations With bfcache and Speculation Rules
This is the technique almost nobody talks about, and it’s arguably the highest-leverage LCP fix available in 2026.
The back/forward cache (bfcache) lets a browser instantly restore a page from memory when a visitor hits the back or forward button – no reload, no re-render, near-zero LCP. Most sites are actually ineligible for bfcache without realizing it, usually because of an unload event listener or a no-store caching header somewhere in the code. Check your eligibility in Chrome DevTools’ Application panel, under the “Back/forward cache” section.
Beyond restoring previous pages, the Speculation Rules API lets a browser prerender a page it predicts a visitor is about to click, so the “next” page is already loaded before the click happens. This is a newer, more advanced technique, but it’s directly supported in Chrome and delivers close to zero LCP for correctly predicted navigations. It’s worth exploring if your site has a small number of highly predictable navigation paths, like a product listing page that almost always leads to a specific set of product pages.
How Do You Fix Interaction to Next Paint (INP)?
INP replaced First Input Delay (FID) as an official Core Web Vital, and it measures every interaction during a visit – not just the first one.
Break Up Long Tasks With scheduler.yield()
Any piece of JavaScript work that runs longer than 50 milliseconds without stopping is called a long task, and long tasks block the browser from responding to clicks or taps while they run. The fix is to periodically “yield” control back to the browser so it can squeeze in a response to whatever the user just did.
The modern approach uses the Scheduler API’s scheduler.yield() method, which pauses a long-running task at natural breakpoints and lets the browser handle pending interactions before resuming. If your site’s JavaScript framework doesn’t support this directly, breaking large functions into smaller chunks with brief pauses between them achieves a similar effect.
Remove and Defer Unnecessary JavaScript
Websites ship more JavaScript today than ever, and much of it sits unused on any given page. Open Chrome DevTools’ Coverage tab while browsing your site – it shows exactly which lines of your JavaScript and CSS never actually execute, giving you a concrete list of what’s safe to remove or split into a separate bundle that only loads when needed.
For non-critical scripts (chat widgets, marketing pixels, non-essential animations), add the defer attribute so they load after the main content finishes rendering rather than competing with it.
Manage Third-Party Script Impact
Analytics tags, ad scripts, and embedded widgets all run on your visitor’s browser, and they compete for the same main thread your own code needs. Audit these regularly – a script you added for a campaign eight months ago might still be running on every page load with no one checking whether it’s still needed.
Where possible, delay non-critical third-party scripts until the user actually interacts with the page (a scroll, a click, a mouse move), rather than loading them immediately on page load.
Avoid Large Rendering Updates
Even without JavaScript execution, the browser’s own rendering work can become a long task. Keep your DOM size reasonably small – an oversized DOM makes every layout recalculation more expensive. Use CSS content-visibility: auto on offscreen sections of long pages so the browser skips rendering work for content the user hasn’t scrolled to yet.
How Do You Fix Cumulative Layout Shift (CLS)?
CLS is the metric most sites already handle reasonably well, but the fixes that remain tend to be the most annoying-for-users kind of bug.
Set Explicit Dimensions on Images, Video, and Embeds
The single most common cause of poor CLS is an image with no declared size. Without explicit width and height attributes (or the CSS aspect-ratio property), the browser reserves zero space for the image until it loads – then the whole page jumps when it finally appears.
Add explicit dimensions to every image, video, and iframe on the page, including ones injected dynamically through a CMS or page builder. This is one of the lowest-effort, highest-impact fixes on this entire list.
Reserve Space for Dynamic Content and Ads
Ad slots and embedded widgets often load after the surrounding content, pushing everything below them down the page the moment they appear. Set a min-height on the container that holds dynamic content, even if you can’t know the exact final size – reserving some space is almost always better than reserving none.
Fix Animation-Induced Layout Shifts
This cause gets missed constantly, and it’s worth understanding the mechanism.
Any CSS animation or transition that touches a layout-inducing property – top, left, margin, width, height – forces the browser to recalculate the page’s layout on every frame of that animation. Even elements positioned outside the normal document flow (like an absolutely positioned popup) still trigger layout shifts if they animate one of these properties.
The fix is to animate transform instead wherever possible. Animating transform: translateX() or translateY() moves an element visually without forcing a layout recalculation at all, because that work happens on the browser’s compositor thread instead of the main rendering pipeline. A sliding cookie banner that animates its top property is a classic, easily fixed example – switching it to animate transform eliminates the layout shift entirely while looking visually identical.
Layout shifts that happen within 500 milliseconds of a genuine user click or tap don’t count against your CLS score – but shifts from a hover event, or shifts that happen on their own timer, do.
How bfcache Eliminates CLS on Repeat Visits
The same back/forward cache covered in the LCP section has a second benefit specific to CLS. When a page loads instantly from bfcache instead of re-rendering from scratch, there’s no loading sequence for elements to shift around during – the fully-rendered page just appears exactly as the visitor left it.
This was responsible for one of the largest single-year improvements in web-wide CLS scores when Chrome expanded bfcache support. If your site currently blocks bfcache eligibility for no strong reason, fixing that earns you both an LCP and a CLS improvement from a single change.
How Do You Fix Core Web Vitals on WordPress, Shopify, and Other Platforms?
The underlying causes are universal, but where you go to fix them depends heavily on your platform.
WordPress-Specific Fixes
WordPress applies native lazy loading to every image by default – including your hero image, which actively hurts LCP. Add loading=”eager” to your above-the-fold image manually, or use a performance plugin that automatically excludes the detected LCP element from lazy loading.
Audit your installed plugins for unused JavaScript and CSS files being loaded on every page regardless of whether that page actually needs them. A caching plugin combined with manual dequeuing of unnecessary plugin assets typically produces the biggest single improvement on a WordPress site.
Shopify and Other Hosted Platforms
Shopify and similar hosted platforms limit your access to server configuration, so your fixes concentrate on theme code and app choices instead. Audit installed apps the same way you’d audit third-party scripts elsewhere – each app you install typically injects its own JavaScript, and unused apps left installed “just in case” quietly tax every page load.
For images, use Shopify’s built-in responsive image support (the image_url filter with explicit width parameters) rather than uploading oversized originals and letting the browser scale them down.
Custom-Built and Headless Sites
On a custom or headless build, you have full control, which means the fixes above around rendering architecture matter most. If your site relies heavily on client-side rendering, your main content may not exist in the initial HTML response at all – pushing LCP later than it needs to be regardless of how well-optimized your images are.
Server-side rendering or static generation for your primary content, with JavaScript only handling genuinely interactive elements, gives you the cleanest starting point for all three metrics simultaneously.
How Do You Prioritize Which Pages to Fix First?
Trying to fix every page individually wastes time. Most sites share a small number of templates across thousands of URLs – fix the template, and the fix propagates everywhere that template is used.
A Template-Based Triage Model
Sort your pages into three groups before you start fixing anything:
- Group 1 – High traffic, high business value, currently failing. Your homepage, top landing pages, and highest-converting product or service pages. Fix these first, always.
- Group 2 – High traffic, lower business value, currently failing. Blog posts or informational pages that bring in visits but don’t directly drive revenue. Fix these second.
- Group 3 – Lower traffic pages, regardless of score. These affect fewer real visitors, so even a poor score here has limited impact on your overall Core Web Vitals status.
Scoring Pages by Traffic, Value, and Severity
For a more precise ranking within those groups, score each affected template on three factors: monthly organic sessions (from Search Console or analytics), business value (does this page drive leads or sales), and severity (how far outside the “Good” threshold the metric currently sits).
A template with high traffic, high business value, and a metric that’s only just outside the Good range often deserves attention before a lower-traffic page with a dramatically poor score – a small fix on a high-traffic template usually delivers more real-world impact than a bigger fix on a page few people visit.
Which Tool Should You Use to Diagnose and Track Fixes?
Each tool answers a slightly different question. Using the wrong one for the job wastes time.
| Tool | Data Type | Best For |
| PageSpeed Insights | Both lab + field | Quick single-URL diagnosis, seeing both score types together |
| Google Search Console | Field only | Site-wide pattern discovery, template-level grouping, official ranking-relevant status |
| Chrome Lighthouse | Lab only | Deep local debugging during development, before a page goes live |
| WebPageTest | Lab only | Advanced waterfall analysis, testing from specific locations and connection speeds |
| web-vitals JS library | Field (your own) | Capturing real user data directly from your own visitors, independent of Google’s reporting timeline |
Start diagnosing with PageSpeed Insights for a fast read. Use Search Console to find patterns across your whole site. Reach for Lighthouse or WebPageTest when you need to debug a specific, stubborn issue in detail before deploying a fix. Install the web-vitals library if you want real-time visibility into your own users’ experience without waiting on Google’s reporting cycle.
Why Did My Core Web Vitals Status Change Without Me Changing Anything?
This confuses more site owners than almost anything else in this space, and it has a real, specific explanation.
Site-Wide Events That Shift Scores
Core Web Vitals field data reflects actual usage, which means anything that changes how your site is actually used can shift your score even with zero code changes. A sudden traffic spike from a viral post or ad campaign can pull in more visitors on slower connections than your usual audience, dragging down your averages. A latency change at your image hosting provider or CDN – something entirely outside your codebase – can quietly push borderline pages from “Good” into “Needs Improvement.”
Browser and Network Shifts in Your User Base
A widely-adopted browser update, or a shift in your visitor mix toward more mobile or slower-network users, can also move your numbers without a single line of code changing on your end. Since these metrics are measured from real usage rather than a fixed synthetic test, your “starting line” is never perfectly stable.
If you see an unexplained shift, check your traffic and audience data for the same time period before assuming you broke something. Small, borderline scores are especially sensitive to these outside factors – a page that was barely passing can tip into failing from a small site-wide nudge that has nothing to do with your actual code.
How Do You Validate and Track a Core Web Vitals Fix?
Making a change and assuming it worked isn’t enough. Google gives you an actual mechanism to confirm it.
The 28-Day Validation Window Explained
Field data in CrUX uses a rolling 28-day collection window, so your fix needs real visitors to actually experience it before the data reflects the improvement. In Search Console’s Core Web Vitals report, click into a specific issue and select “Start Tracking” – this begins a formal 28-day monitoring period specifically checking whether that issue still appears on your affected URLs.
Starting tracking doesn’t trigger any re-crawling or re-indexing on its own. It’s purely a monitoring clock that watches your existing CrUX data stream for the next four weeks.
What “Passed,” “Failed,” and “Looking Good” Actually Mean
During an active validation period, each URL shows one of three states. “Looking good” means every instance of the issue checked so far has cleared – a positive early sign, but not final. “Passed” means the full 28-day window completed with no recurrence of the issue on that URL. “Failed” means the issue reappeared on at least one URL during the tracking window, which restarts your monitoring clock once you apply a further fix and start tracking again.
Don’t panic if you see “Failed” on a small number of URLs within a larger group – check whether those specific pages have a different template or added feature that’s reintroducing the same problem elsewhere.
Common Mistakes That Keep Core Web Vitals Failing
Chasing a 100/100 Lab Score Instead of Field Data
A perfect Lighthouse score feels like a finish line, but it measures a single simulated visit under ideal conditions. Real visitors on real networks and real devices are what your Core Web Vitals assessment actually reflects – optimize toward that field data, not the lab number.
Fixing Individual URLs Instead of Shared Templates
Manually patching one product page while ten thousand others share the same broken template wastes enormous effort for tiny impact. Identify the shared component or template causing the issue and fix it once at the source.
Ignoring Third-Party Script Impact
It’s easy to audit your own code and forget the six different marketing, analytics, and chat scripts a different team added over the past year. Third-party code runs with the same access to the main thread as your own – audit it with the same scrutiny.
Your Core Web Vitals Fix Action Plan (6 Steps)
- Run a full audit with PageSpeed Insights on your top templates, and pull the Search Console Core Web Vitals report to see site-wide patterns.
- Identify which metric is failing on each affected template – LCP, INP, CLS, or a combination – since the fix for each is completely different.
- Prioritize by template and business value, using the Group 1/2/3 model above, rather than fixing pages in random order.
- Apply the specific fix for each failing metric – image discoverability and CDN for LCP, long-task breakup for INP, explicit dimensions for CLS.
- Re-test with lab tools immediately to confirm the technical change worked, then wait for field data to catch up.
- Start tracking in Search Console and give it the full 28-day window before declaring the issue resolved.
FAQ
What’s a good Core Web Vitals score?
A good score means all three metrics hit the “Good” threshold for at least 75% of real visits: LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. A page with even one metric in the “Needs Improvement” or “Poor” range is not considered good overall.
Why do I have a 100/100 performance score but still fail Core Web Vitals?
Your performance score comes from lab data – a single simulated test in a controlled environment. Your Core Web Vitals assessment comes from field data based on real visitors on real devices and connections, which can tell a very different story than a clean lab test.
How long does it take to see Core Web Vitals improvements in Search Console?
Field data uses a rolling 28-day collection window, so expect roughly four weeks before Search Console fully reflects a fix. Lab tools like PageSpeed Insights will show the technical improvement immediately, which is useful for confirming your fix worked while you wait for field data to catch up.
Do Core Web Vitals directly affect SEO rankings?
Yes, Core Web Vitals are a confirmed part of Google’s page experience ranking signals, though content relevance and quality still carry more overall weight. Poor Core Web Vitals can also indirectly hurt rankings by increasing bounce rates and reducing engagement, both of which search engines factor in separately.
Can I fix Core Web Vitals without a developer?
Some fixes, like compressing images or adjusting lazy-loading settings through a plugin, don’t require coding knowledge. More involved fixes – breaking up long JavaScript tasks, adjusting rendering architecture, or fixing animation-based layout shifts – generally need a developer to implement safely without breaking other functionality.
The Bottom Line on Fixing Core Web Vitals
Fixing Core Web Vitals isn’t about chasing a perfect lab score or applying every optimization tip you can find. It’s about identifying which of the three metrics is actually failing for your real visitors, fixing the specific cause, and confirming the fix held up over a full 28-day measurement cycle.
Start with your highest-traffic templates, since one fix there reaches more real visitors than a dozen fixes on pages nobody sees. Then build the habit of checking your Core Web Vitals report regularly, not just when a client or boss asks why rankings dropped.
The sites that stay consistently in the “Good” range treat this as ongoing maintenance, not a one-time project you finish and forget.