How to Pass Core Web Vitals: Step by Step (2026)

The Fastest Path to Passing Core Web Vitals

You know your Core Web Vitals need work. Maybe Google Search Console is showing red or orange. Maybe a client is asking why their site is not passing. Maybe you just ran PageSpeed Insights and the numbers are bad. You do not need another article explaining what the metrics are. You need a workflow that takes you from failing to passing in the most efficient way possible.

This guide is that workflow. I have used it to help sites pass Core Web Vitals on hundreds of thousands of pages. It works on WordPress, Shopify, custom builds, and every platform in between. The key insight: the order in which you fix things matters. Fix the foundation first, then work outward. Otherwise you waste time optimizing things that a deeper problem will override.

Where the Web Stands Right Now

According to the 2025 Web Almanac (based on CrUX data from July 2025), 48% of mobile websites and 56% of desktop websites pass all three Core Web Vitals. That is an improvement from 44% mobile in 2024, but it still means more than half the mobile web is failing.

Breaking it down by metric (percentage of origins rated "good" on mobile):

Sources: 2025 Web Almanac (HTTP Archive, July 2025), DebugBear CrUX analysis (Oct 2025), NitroPack CrUX analysis.

The math is clear: LCP is the bottleneck. If 87% pass INP and 80% pass CLS but only 66% pass LCP, then LCP is what drags the overall pass rate down to 48%. This is why the workflow below prioritizes TTFB and LCP first.

CoreDash aggregate data tells the same story. Across sites that implemented this exact workflow (TTFB → LCP → INP → CLS in order), the average time from "failing" to "passing all three metrics" in CrUX was 4 to 6 weeks: 1 to 2 weeks for implementation, plus 2 to 4 weeks for the 28 day CrUX rolling window to reflect the improvements. Sites that skipped straight to JavaScript optimization without fixing TTFB first took 2 to 3 times longer to reach passing because the foundation was unstable.

Step 1: Assess Where You Stand

Before changing anything, you need to know exactly which metrics are failing and on which pages. Do not skip this step. Guessing leads to wasted effort.

Check Google Search Console

Go to your Search Console property and open the Core Web Vitals report under "Experience." This shows you:

• How many URLs are rated Good, Needs Improvement, or Poor
• Which specific metric is failing (LCP, INP, or CLS)
• URL groups that share the same issue (e.g., all product pages failing on INP)

Search Console uses real field data from Chrome users over a 28 day rolling window. This is the data Google uses for ranking. If Search Console shows you are passing, you are passing, regardless of what Lighthouse says.

Run PageSpeed Insights on Key Pages

Test at least one URL of each page type: your homepage, a blog post, a product page, a category/collection page. PageSpeed Insights gives you both field data (if available) and lab data with specific diagnostics.

Look at the field data section first (labeled "Discover what your real users are experiencing"). If it shows green for all three metrics, that page passes. If field data is unavailable, the page does not have enough traffic for CrUX data. Google may use origin level or URL group data instead.

Set Up Real User Monitoring

Search Console and CrUX have a 28 day rolling window, which means improvements take weeks to show up. To see the immediate impact of your changes, set up a Real User Monitoring (RUM) solution like CoreDash. RUM gives you real time field data for every page, every device, and every country, so you can verify each fix works before moving to the next one.

Step 2: Identify Which Metric to Fix First

If multiple metrics are failing, fix them in this order:

TTFB is not a Core Web Vital itself, but it is the foundation. If your TTFB is above 800ms, no amount of image optimization or JavaScript deferral will save your LCP. Learn more in our Time to First Byte guide.

Step 3: Fix the Foundation (TTFB)

If your Time to First Byte is above 400ms consistently, start here. Common causes and fixes:

• Slow hosting: upgrade to quality hosting with server level caching. Managed hosts for WordPress (Kinsta, SiteGround, Cloudways) or Shopify's built in infrastructure handle this.
• No page caching: ensure your CMS caches the fully rendered HTML so the server does not regenerate it on every request.
• No CDN: set up a CDN (Cloudflare is free) to serve pages from edge locations close to visitors. See Cloudflare configuration guide.
• Redirects: every redirect adds a full round trip. Eliminate unnecessary redirect chains.
• Slow backend: unoptimized database queries, excessive WordPress plugins, or heavy server side processing. Use query monitoring tools to identify bottlenecks.

Target: get TTFB below 200ms for most visitors. At minimum, below 400ms.

Step 4: Fix LCP

Once TTFB is solid, fix Largest Contentful Paint. The process:

Identify Your LCP Element

Run your failing page in PageSpeed Insights and find the "Largest Contentful Paint element" in the Diagnostics section. It is usually a hero image, featured image, or large text block.

If LCP Is an Image

1. Preload it. Add <link rel="preload" as="image" href="..." fetchpriority="high"> in the <head>.
2. Do NOT lazy load it. Remove loading="lazy" from the LCP image. Add fetchpriority="high" to the <img> tag instead.
3. Optimize the file size. Convert to WebP or AVIF. Serve the correct dimensions for the viewport (use srcset and sizes).
4. Make the URL discoverable in HTML. The image URL must be in the HTML source (via <img src="">), not loaded dynamically by JavaScript. 7% of websites hide their LCP image behind data-src attributes that require JavaScript to render.

If LCP Is Text

1. Eliminate render blocking CSS. Generate and inline critical CSS so the browser can render text without waiting for external stylesheets.
2. Optimize font loading. Self host your fonts and preload the primary font file to reduce the time before text renders.
3. Minimize render blocking JavaScript. Defer non critical JavaScript so it does not block the HTML parser.

Step 5: Fix INP

Once LCP is passing, address Interaction to Next Paint. INP fails when JavaScript blocks the main thread during user interactions.

Find the Bottleneck

Open Chrome DevTools, go to the Performance panel, and record yourself interacting with the page. Look for long tasks (tasks over 50ms, shown as red bars). These are what block the browser from responding to your clicks.

Common causes on most sites:

• Third party scripts (analytics, ads, chat widgets, marketing tags) competing for main thread time
• Large JavaScript bundles from frameworks, page builders, or plugins executing during page load
• Unoptimized event handlers that do too much work in response to a click or keypress

The Fix Priority

1. Delay third party scripts. Chat, analytics, social, and marketing scripts should load after the first user interaction, not during page load.
2. Defer non critical first party JavaScript. Use defer or async on scripts that do not need to execute before the page is interactive.
3. Break up long tasks. If your own code has functions that take over 50ms, yield to the main thread using scheduler.yield() or setTimeout to allow the browser to process user input between chunks of work.
4. Remove unused JavaScript. Use Chrome DevTools Coverage tab to identify JavaScript that loads but never executes. Remove it or load it conditionally.

For the complete INP optimization strategy, see our INP optimization guide.

Step 6: Fix CLS

CLS is usually the easiest metric to fix. The most common causes and solutions:

Images Without Dimensions

Every <img> tag needs explicit width and height attributes. Without them, the browser does not know how much space to reserve and content shifts when the image loads. This is the #1 cause of CLS globally. See our CLS guide.

Web Font Swapping

When a web font loads and replaces the fallback, text can reflow and shift surrounding elements. Fix: self host fonts, use font-display: optional or use the CSS size-adjust property to match the fallback font metrics to the web font.

Dynamically Injected Content

Cookie banners, notification bars, ad slots, and popups that push content down after load. Fix: reserve space for these elements with CSS min-height or load them in a way that does not affect surrounding layout (e.g., overlays instead of inline injection).

Step 7: Verify with Field Data

After implementing your fixes, you need to verify they work in the real world, not just in Lighthouse.

• Immediate verification: use CoreDash or another RUM tool to see real time field data. Changes should be visible within hours.
• CrUX verification: the Chrome User Experience Report uses a 28 day rolling window. Expect 2 to 4 weeks before improvements fully reflect in CrUX data.
• Search Console verification: the Core Web Vitals report in Search Console updates based on CrUX. Once CrUX shows improvement, Search Console will follow.

This lag is why RUM is essential. Without it, you are flying blind for weeks after making changes.

Step 8: Monitor and Maintain

Passing Core Web Vitals is not a one time achievement. Performance regresses as you add content, install plugins, update themes, and add third party scripts. Set up ongoing monitoring:

• Check Search Console Core Web Vitals report weekly
• Use CoreDash for continuous real time monitoring with alerts
• Re test in PageSpeed Insights after every significant change (new plugin, theme update, new third party script)
• Audit third party scripts quarterly. Remove any that are no longer needed.

For a complete reference of everything you should be checking, use our Ultimate Core Web Vitals Checklist.

Quick Wins: The Fixes with the Biggest Impact

If you only have time for five things, these are the highest impact fixes across all platforms:

These impact ranges are not estimates. They come from CoreDash real user monitoring data across optimization projects. The actual improvement on your site will depend on your starting point, your hosting, and your traffic profile. Sites starting from very poor scores (LCP above 5 seconds) often see even larger improvements. Sites already close to the threshold may see smaller absolute gains but the difference between failing and passing.

The 2025 Web Almanac data supports these priorities. Home pages pass Core Web Vitals at 45% on mobile, while secondary pages pass at 56%. The gap is because home pages tend to have more dynamic content, larger hero images, and more third party scripts. If your homepage is failing but internal pages are passing, focus your LCP and INP optimization effort on the homepage template specifically.