Google Core Web Vitals: What They Are and How to Pass in 2025

Back in early 2024, one of my health niche sites dropped 40% of its Google traffic over two weeks. No algorithm update had been announced. No manual penalty. No spike in crawl errors.

I checked everything—backlinks, content quality, keyword rankings. All looked normal on the surface. Then I opened Google Search Console and saw it. Red across the board on Core Web Vitals. Every single one was failing.

My LCP was 5.1 seconds. My INP was 380ms. My CLS was 0.34. That site felt like wading through mud on a cheap phone, and Google had clearly noticed.

It took me about three weeks of focused work to fix everything. LCP dropped to 1.6s. INP came down to 85ms. CLS hit 0.02. Six weeks later, the traffic came back—and then some. We ended up 25% higher than before the drop.

That experience taught me more about Core Web Vitals than any course or guide ever did. I want to share what actually works, not just the textbook definitions.

What Core Web Vitals Actually Are

Core Web Vitals are Google's way of measuring how real users experience your website. Not lab scores. Not theoretical performance. Real people on real devices with real network conditions.

Google collects this data from actual Chrome users who have opted into sending usage statistics. So when you see your scores in Search Console, that's not a bot testing your page—that's thousands of real visitors telling Google how your site felt to them.

There are three metrics that matter right now:

1. LCP (Largest Contentful Paint) — How fast the main content loads
2. INP (Interaction to Next Paint) — How responsive your page feels when someone clicks something
3. CLS (Cumulative Layout Shift) — How much things jump around while the page loads

Google uses these as ranking signals. They've said this repeatedly since 2021. But here's what most people miss: it's not a hard threshold where you either pass or fail. It's more like a gradient. Better scores give you a gradual ranking advantage, especially when you're competing against similar content.

If two pages have equally good content, the faster one wins. I've seen this play out across my sites dozens of times.

If you're serious about ranking, you should already be thinking about how to write SEO friendly blog posts. But great content on a slow site is like putting premium fuel in a car with a clogged filter—the potential is there but nothing flows.

LCP: Largest Contentful Paint

What It Measures

LCP tracks how long it takes for the largest piece of content in the viewport to become visible. Usually this is a hero image, a large heading, or a block of text near the top of the page.

The key word there is visible. Not loaded in the background. Not cached. Actually rendered on screen for the user to see.

The Scores You Need

• Good: Under 2.5 seconds
• Needs improvement: 2.5s to 4.0s
• Poor: Over 4.0 seconds

I aim for under 2.0 seconds on all my sites now. Anything above 2.5s is a problem that needs attention.

What Actually Caused My LCP Problems

On that health site, the issue was painfully simple once I found it. The theme was loading a 1.2 MB hero image that had been uploaded directly from an iPhone. Nobody had compressed it. Nobody had converted it to WebP. It was just sitting there, raw and enormous, slowing down every single page load.

On another site, the culprit was different. The theme was loading six different CSS files and three JavaScript files before anything rendered. The browser couldn't paint anything until all of them downloaded and parsed.

Fixes That Actually Worked

Compress and convert every image. I use ShortPixel on most of my sites. On the health site, converting that hero image to WebP and running it through compression knocked it from 1.2 MB down to 85 KB. LCP dropped by 1.4 seconds on that change alone.

Use a CDN. I moved all my sites to Cloudflare years ago. The difference was noticeable, especially for visitors far from my server. If your server is in the US and half your traffic comes from India, a CDN alone can shave 1-2 seconds off LCP.

Defer non-critical JavaScript. Most WordPress sites load way more JS than they need. I went through each plugin and asked: does this need to run before the page renders? If the answer was no, I deferred it. On one site, this cut 800ms off LCP.

Preload your LCP image. This one's easy and most people skip it. Add a fetchpriority="high" attribute to your largest above-the-fold image. It tells the browser to prioritize that specific resource. I've seen this shave 200-500ms off LCP consistently.

Upgrade your hosting. I know nobody wants to hear this because it costs money. But if you're on $3/month shared hosting and getting any real traffic, your LCP will suffer. I moved my sites to Cloudways and the improvement was immediate across the board.

Avoid lazy loading above-the-fold images. This one surprises people. Lazy loading is great for images below the fold. But if you lazy load your hero image, you're actually delaying when the browser starts downloading it. The browser waits until it calculates the viewport position, then starts the download. That adds unnecessary time.

INP: Interaction to Next Paint

What It Measures

INP replaced First Input Delay (FID) in March 2024. It's a much better metric because FID only measured the initial delay before the browser could start processing your click. INP measures the full time from when you click or tap something to when the browser actually updates the screen.

This matters more than most people realize. Every button click, every menu toggle, every accordion expand—INP is watching all of it. Google takes the worst interaction during the page session (with some smart filtering for outliers) and that becomes your INP score.

The Scores You Need

• Good: Under 200 milliseconds
• Needs improvement: 200ms to 500ms
• Poor: Over 500 milliseconds

What Actually Caused My INP Problems

The health site had a table of contents plugin that was doing some heavy JavaScript work every time someone clicked a section link. The plugin was recalculating positions of every heading on the page, running multiple DOM queries, and then smoothly scrolling to the section. On a low-end phone, that entire chain took over 600ms.

I also had an email popup plugin (I know, I know) that was injecting a modal with animations. Every time the page loaded, it was running complex animations that blocked the main thread.

Fixes That Actually Worked

Audit your plugins ruthlessly. I deactivated the table of contents plugin and replaced it with a lightweight custom implementation that just uses smooth scrolling. INP for those interactions dropped from 600ms to about 45ms.

Remove or replace heavy popups. I got rid of the email popup entirely on that site. Popups are conversion tools, but if they're tanking your INP, they're costing you traffic which costs you more conversions than the popup would generate. If you must use one, test it with Chrome DevTools and make sure it doesn't spike your INP.

Break up long JavaScript tasks. If you have any custom code running on your site, make sure you're not doing too much work in a single task. Use setTimeout or requestAnimationFrame to break up heavy computations. This is more relevant if you have custom-built features rather than just using WordPress plugins.

Reduce third-party scripts. Analytics, ad scripts, chat widgets, social sharing buttons—each one adds to your main thread workload. I cut my third-party scripts down to the essentials: Google Analytics, AdSense (where applicable), and nothing else. On one site, removing a heavy chat widget dropped INP from 320ms to 110ms.

Use will-change sparingly for animated elements. If you have CSS animations that trigger layout or paint work, adding will-change: transform to those elements can help the browser optimize them. But don't overdo it—applying it to too many elements actually hurts performance.

CLS: Cumulative Layout Shift

What It Measures

CLS measures how much visible content moves unexpectedly while the page is loading. You know that annoying thing where you're about to tap a link and suddenly an ad loads above it and you tap the wrong thing? That's what CLS measures.

Google calculates this by looking at how much content shifts and how far it shifts. A small element moving a long distance is worse than a large element moving slightly. The final score is a number between 0 (no shifting) and 1 (constant chaos).

The Scores You Need

• Good: Under 0.1
• Needs improvement: 0.1 to 0.25
• Poor: Over 0.25

I aim for under 0.05 on all my sites. It's very achievable if you're deliberate about it.

What Actually Caused My CLS Problems

The health site had two CLS issues. First, the ads. I was using AdSense with auto-ads, and the injected ad units were pushing content down after the page had already rendered. Second, images in the blog post content didn't have explicit width and height dimensions set. As each image loaded, the text below it would jump down.

On a different site, I had a sticky header that would appear after scrolling past a certain point, but the header had a different height than the space reserved for it. Every time it appeared, the entire page content shifted down.

Fixes That Actually Worked

Set explicit dimensions on all images and videos. This is the single biggest CLS fix. Every image needs a width and height attribute, or the container needs a fixed aspect ratio. When the browser knows the dimensions upfront, it reserves the exact space and nothing shifts. If you're using WordPress with a modern theme, this often happens automatically. But check anyway—especially for images inside post content.

Reserve space for ads. If you're running ads, you need to wrap each ad unit in a container with a fixed minimum height. This prevents the page from reflowing when the ad loads. I use a simple CSS approach: set the ad container to the expected ad height with min-height. The content doesn't shift because the space is already allocated.

Don't inject content above the fold after initial render. This includes popups, banners, notification bars, and dynamically loaded widgets. If you absolutely must show something, inject it at the bottom or use a fixed position that doesn't affect document flow.

Preload web fonts or use font-display: swap with fallback sizes. Web fonts are a sneaky CLS culprit. When a custom font loads, the text reflows because the new font has different character widths than the fallback. Using font-display: swap is the standard advice, but it actually causes a layout shift. A better approach is to preload your fonts and set font-display: optional, which tells the browser to only use the custom font if it loads within a very short window. If it doesn't load in time, the fallback stays and nothing shifts.

Use CSS contain property. On pages with complex layouts, adding contain: layout to sections can prevent layout calculations from cascading across the page. This is an advanced optimization, but it helped me on a site that had lots of dynamic content modules.

How to Measure Core Web Vitals

You need to check your scores in two places because they tell you different things.

Google Search Console (Field Data)

This is your real-world data. It shows what actual Chrome users experienced on your site. Set up Google Search Console properly if you haven't already—it's free and it's the only place to see your official Core Web Vitals report.

Go to Experience > Core Web Vitals in Search Console. You'll see your URL groups rated as Good, Needs Improvement, or Poor. Click into any group to see specific URLs and their scores.

The catch: Search Console data has a 28-day rolling window and it updates slowly. You won't see the impact of your fixes for a few weeks. This frustrates a lot of people, but it's just how Google's data pipeline works.

PageSpeed Insights (Lab + Field)

PageSpeed Insights at pagespeed.web.dev gives you both field data (from real users) and lab data (a controlled test run). The lab data is useful for debugging because it gives you specific diagnostics.

I run PageSpeed Insights on key pages after making changes to verify the fixes worked in a controlled environment. Then I wait for Search Console to confirm with real user data.

Chrome DevTools (Real-Time Debugging)

For deep debugging, nothing beats Chrome DevTools. Open the Performance tab, record a page load, and look at the flame chart. You can see exactly what's blocking your LCP, what's causing long tasks that hurt INP, and when layout shifts happen.

The Lighthouse tab in DevTools also runs a quick audit with specific recommendations. I use this during development before pushing changes live.

The Priority Order I Use for Fixes

When a site is failing Core Web Vitals, I don't try to fix everything at once. I follow this order based on what usually gives the biggest impact:

1. Image optimization (affects LCP and CLS the most)
2. Remove unnecessary plugins and third-party scripts (affects all three metrics)
3. Set explicit dimensions on media (fixes CLS fast)
4. Defer non-critical CSS and JS (helps LCP significantly)
5. Reserve space for ads and dynamic content (fixes remaining CLS)
6. Optimize interaction handlers (fixes INP)
7. Upgrade hosting if needed (can improve everything)

Steps 1 through 4 usually get most sites to passing. I rarely need to go beyond that unless there's something unusual going on.

Common Mistakes I See All the Time

Obsessing over lab scores instead of field data. I've seen people spend days optimizing for a 100/100 Lighthouse score while their real-world Core Web Vitals in Search Console are still failing. Lab tests run on fast connections with powerful hardware. Your real visitors are on 4G with budget phones. Always optimize for field data.

Only checking the homepage. Your homepage might be perfectly optimized while your blog posts—which get most of your search traffic—are a disaster. Check your highest-traffic pages individually.

Installing more plugins to fix plugin problems. I've seen sites with 5 caching plugins, 3 image optimization plugins, and 2 minification plugins all running at the same time. More plugins means more code to parse and execute. Pick one good solution for each problem and stick with it.

Ignoring mobile. Most of your traffic is mobile. Google uses mobile-first indexing. If your Core Web Vitals are good on desktop but terrible on mobile, you're failing. Test on a mobile connection throttled to "Fast 3G" in DevTools—that's closer to what many real users experience.

Fixing things once and never checking again. Core Web Vitals can regress. A theme update, a new plugin, a change in your ad setup—all of these can break your scores. I check my Core Web Vitals report in Search Console at least once a month.

Serving responsive images without srcset. If you're serving the same 2000px wide image to every device, mobile users are downloading way more data than they need. Use srcset so mobile devices get a smaller, appropriately sized version.

How This Connects to the Bigger Picture

Core Web Vitals are one piece of the SEO puzzle, but they're a piece you can't ignore anymore. Google has made it clear that page experience matters alongside content quality. If you're starting a profitable niche website, building performance in from day one is way easier than retrofitting it later.

I've also seen Core Web Vitals intersect with content issues in unexpected ways. For example, duplicate content problems can cause Google to crawl and index multiple versions of the same page, each with different performance characteristics. Clean up your content structure and your Core Web Vitals data becomes more reliable.

And while we're talking about the bigger picture—yes, backlinks still matter for SEO in 2025. But I'd argue that Core Web Vitals matter more for small and medium sites. You might not be able to out-link a major competitor, but you can absolutely out-perform them. Speed is the one advantage that's accessible to everyone.

What I'd Do If I Were Starting Fresh

If I were building a new site today, here's what I'd do from day one:

• Use a lightweight theme (I like GeneratePress and Kadence for WordPress)
• Host on decent cloud hosting (Cloudways, Kinsta, or similar)
• Set up Cloudflare (free tier works fine)
• Compress every image before uploading
• Use WebP format for all images
• Set explicit dimensions on every image and video
• Limit plugins to under 10 total
• Defer all non-critical JavaScript
• Preload the LCP image with fetchpriority="high"
• Reserve space for any ads I plan to run
• Test with PageSpeed Insights weekly for the first month

Doing this upfront takes maybe an extra hour during setup. Trying to fix it on a site with 500 published posts is a multi-week project. Save yourself the headache.

Quick Reference Cheat Sheet

| Metric | What It Measures | Good Score | Most Common Cause | |--------|-----------------|------------|-------------------| | LCP | Main content load speed | < 2.5s | Unoptimized images, slow hosting | | INP | Click/tap responsiveness | < 200ms | Heavy JavaScript, too many plugins | | CLS | Visual stability | < 0.1 | Missing image dimensions, late-loading ads |

Save this table. I refer to it constantly when auditing new sites.

Final Thoughts

Core Web Vitals aren't going away. If anything, Google is going to rely on them more over time. The sites that treat performance as a core feature—rather than an afterthought—are the ones that will consistently rank higher and keep their visitors happy.

I learned this the hard way with that 40% traffic drop. Don't wait for Google to punish your site before you take this seriously. Run a quick PageSpeed Insights test on your top 10 pages right now. If anything's red, you know what to do.

Got questions about a specific Core Web Vitals issue on your site? Drop a comment—I read every one.