Core Web Vitals: Why Google Quietly Ranks Slow Sites Lower

Here is an uncomfortable little experiment. Open your own website on your phone, on cellular data, not your office Wi-Fi. Count the seconds until you can actually read and tap something. Watch whether the page jumps around while it loads, so the button you were about to press slides out from under your thumb.

That lag you just felt? Google feels it too. And it has quietly decided that if your site feels sluggish to real people, it deserves to sit a little lower in the search results than the competitor whose site snaps to attention.

The metrics Google uses to measure that feeling are called Core Web Vitals. They sound like something only a developer should worry about, and for years that was mostly true. But the numbers connecting speed to lost customers have gotten so blunt that ignoring this is now a business decision, not a technical one. Let me walk you through what these things actually are, why they matter to your bottom line even more than to your ranking, and exactly what to do about a slow site, even if you have never touched a line of code.

What Core Web Vitals actually are

Google runs the biggest measurement operation on the internet. Every time someone visits your site using the Chrome browser, Chrome can quietly record how the experience went. Not "did the page load," but "did it load in a way that felt good to a human being."

Core Web Vitals are the three specific measurements Google decided matter most. Think of them as a report card with three grades, each one capturing a different way a website can annoy you.

LCP: how fast the main thing shows up

LCP stands for Largest Contentful Paint. Forget the jargon. It measures how long it takes for the biggest, most important thing on the page, usually your headline or a hero image, to actually appear.

The analogy: you walk into a restaurant and sit down. LCP is how long before a server acknowledges you exist and hands you a menu. A few seconds, fine. Five minutes staring at an empty table, you are already thinking about leaving.

Google's "good" threshold for LCP is 2.5 seconds or less, measured for most of your visitors. That number, and the two below it, come straight from Google's own documentation on how the thresholds were defined.

INP: how fast the page answers when you poke it

INP stands for Interaction to Next Paint. It measures responsiveness. When you tap a button, open a menu, or start typing, how quickly does the page visibly react?

The analogy: you ask the server a question. INP is the pause before they respond. A quick "of course, right away" feels great. A blank three-second stare while they process your existence feels broken, even if the food is fine.

Good INP is 200 milliseconds or less. That is a fifth of a second. Worth knowing: INP is new. It officially replaced an older metric called FID (First Input Delay) on March 12, 2024. The old metric only checked your very first tap on a page. INP watches all of them, because a site that responds fast once and then freezes is still a bad site. If you read an SEO article written before 2024 that talks about FID, it is out of date on this point.

CLS: how much the page jumps around

CLS stands for Cumulative Layout Shift. It measures visual stability, which is a polite way of saying "does stuff move around while the page is loading."

You know the feeling. You go to tap "read more," an ad or image finishes loading above it, the whole page lurches down, and now you have tapped something you never wanted. That is layout shift, and it is infuriating.

The analogy: someone keeps sliding your coffee cup around the table while you are reaching for it. Maddening. Good CLS is a score of 0.1 or less, where lower means steadier.

Here is the part most articles skip. These three are the "core" vitals, but they live inside a broader bucket Google calls page experience signals, which also includes things like being mobile-friendly and served securely over HTTPS. You do not need to memorize all of that. You need to know that speed and stability are officially part of how Google judges your site.

Why you should actually care

Let me be real with you. As a pure ranking factor, Core Web Vitals are real but modest. Google has been clear that great content on a slightly slow page will usually still beat thin content on a fast one. Speed is a tiebreaker, not a magic wand. So if that were the whole story, I would tell you to fix it when you get around to it.

It is not the whole story. The bigger reason to care has nothing to do with rankings and everything to do with the people who actually land on your page. Speed is quietly deciding whether they stay or bail before your site even finishes loading.

The numbers are brutal. Google found that as a mobile page's load time goes from one second to ten seconds, the probability that a visitor bounces (leaves immediately) increases by 123 percent. More than double. You paid for that click, whether through ads or months of SEO work, and a slow load hands the visitor right back to the search results.

It gets more concrete when you look at sales. A landmark study by Deloitte and Google, tellingly named Milliseconds Make Millions, analyzed 30 million-plus mobile sessions across dozens of brands. A mere 0.1 second improvement in load time, a tenth of a second, was associated with retail conversions rising 8.4 percent and average order value rising 9.2 percent. For travel sites, conversions jumped 10.1 percent. That is from a change most humans cannot even consciously perceive.

And a separate analysis by the agency Portent, studying site speed against conversion rate across millions of visits, found conversion rates were highest for pages that loaded in under two seconds, and that rates dropped by an average of 0.3 percent for every additional second of load time. The steepest cliff was in those first few seconds.

So the ranking bump is the small prize. The real prize is not silently losing a quarter of your visitors and a chunk of your sales because your homepage takes a leisurely six seconds to get dressed.

Lab data vs field data (why your two speed scores disagree)

Before you run a speed test and panic, you need to understand something that confuses almost everyone: there are two completely different kinds of speed data, and they often disagree.

Lab data is a test run in a controlled environment. A tool loads your page on a simulated device with a simulated connection and reports what happened. It is repeatable and great for diagnosing problems, but it is a lab dummy, not a real customer.

Field data is the real thing. It is the actual experience of real Chrome users visiting your real site on their real phones and connections, collected over the previous 28 days. Google keeps this in something called the Chrome UX Report (CrUX). This is the data Google actually uses for ranking. Field data is the one that counts.

Three free tools will show you this:

• PageSpeed Insights is where you start. Paste your URL and it gives you both field data (real users, at the top) and lab data (a fresh test, below), plus a specific list of what to fix.
• The Search Console Core Web Vitals report groups every page on your site into Good, Needs Improvement, and Poor buckets, using field data. This is your site-wide scoreboard. If you have not set up Search Console, that is step zero, and it pairs naturally with the fundamentals in our guide to on-page SEO.
• CrUX itself, which powers the field numbers in the tools above.

If your lab score looks rough but your field data is Good, breathe. Real users are having a fine time, and Google grades on the field data. Fix the field data first, always.

How to actually fix a slow site

Here is the good news for a non-technical owner. Most slow small business sites are slow for the same handful of boring reasons, and you can either fix several yourself or hand a developer a precise, informed brief instead of a vague "make it faster." Let me go through the big levers, roughly in order of bang for the buck.

Compress and modernize your images. This is the number one culprit, full stop. That gorgeous 4,000-pixel-wide photo straight off a phone or stock site can be several megabytes. On a page it might display at 800 pixels wide, so you are forcing every visitor to download five times more image than they will ever see. Shrink images to the size they actually display, run them through a free compressor like TinyPNG or Squoosh, and save them in a modern format like WebP, which is dramatically smaller than old JPEGs and PNGs at the same quality. On most platforms a plugin can do this automatically for your whole library.

Turn on lazy loading. Lazy loading means images and videos further down the page do not load until the visitor scrolls near them. Why download the photo in your footer before someone has even read your headline? Most modern site platforms do this by default now; if yours does not, a plugin adds it in one click. This directly helps LCP because the browser stops wasting effort on things nobody is looking at yet.

Set up caching. Caching (pronounced "cashing") means saving a ready-made copy of your page so the server does not have to rebuild it from scratch for every single visitor. Analogy: a coffee shop that brews a fresh pot to have ready versus grinding beans from scratch for each customer. On WordPress and similar platforms, a caching plugin handles this. On hosted platforms like Shopify or Squarespace it is built in.

Use a CDN. A CDN (Content Delivery Network) stores copies of your site on servers around the world, so a visitor in Sydney is served from a nearby server instead of waiting for data to cross an ocean from your host in Ohio. Services like Cloudflare offer a genuinely useful free tier, and turning it on is one of the higher-impact things a developer can do quickly.

Reduce and defer JavaScript. JavaScript is the code that makes things interactive, and it is the usual villain behind bad INP. Every chat widget, popup tool, analytics tracker, and social feed you bolt on adds code the browser must download and run before the page feels responsive. Audit your plugins and third-party scripts and kill the ones you do not truly need. Ask your developer to "defer" non-essential scripts so they load after the main content, not before it. This is the single biggest lever for that "why does tapping do nothing" feeling.

Always give images a width and height. This is the fix for layout shift, and it is almost free. When your code tells the browser exactly how much space an image will occupy before it loads, the browser reserves that spot, and nothing jumps around when the image arrives. Missing dimensions are the top cause of a bad CLS score. A developer can fix this fast; point them straight at it.

Get decent hosting. The cheapest shared hosting plans cram thousands of sites onto one overworked server, and no amount of image compression fully fixes a server that takes two seconds just to start responding. If you have done everything above and your site is still slow, upgrading to a quality managed host is often the fix that finally moves the needle.

You will notice speed and content quality reinforce each other. A fast page gives your words a fair chance to be read, which is exactly why speed sits alongside solid on-page SEO best practices rather than replacing them.

Your action plan

Here is the plan I would hand a busy owner who wants results without a computer science degree:

1. Measure first. Run your homepage and two top pages through PageSpeed Insights. Screenshot the field-data scores for LCP, INP, and CLS. This is your "before."
2. Set up the scoreboard. Get your site into Google Search Console and open the Core Web Vitals report to see which pages Google flags as Poor.
3. Fix the images. Compress and resize everything, switch to WebP, and turn on lazy loading. This alone fixes many sites.
4. Enable caching and a CDN. A caching plugin plus a free Cloudflare account. Two moves, big payoff.
5. Cut the clutter. Remove plugins and third-party scripts you do not use. Ask a developer to defer the rest.
6. Stop the jumping. Have someone add width and height to your images to kill layout shift.
7. Upgrade hosting if needed. If server response is still slow after all that, move to a better host.
8. Measure again. Two to four weeks later (field data needs time to refresh), rerun the same pages and compare to your "before" screenshots. That gap is your win.

If steps five through seven make your eyes glaze over, that is exactly the kind of work you can hand to a partner who does small business SEO day in and day out, so you can get back to running the business.

The takeaway

Core Web Vitals are just Google's way of measuring whether your website respects your visitors' time: does the main content show up fast (LCP), does the page respond when tapped (INP), and does it hold still while it loads (CLS). You now know what the three grades mean, why a slow site quietly bleeds customers and sales far more than it costs you rankings, and the exact, prioritized steps to fix it. Run the test, tackle the images first, and if you want to keep the momentum going, our guide on how to boost your on-page SEO is a solid next stop.