ServicesWorkSectorsProcessFAQ
Back to Blog

Core Web Vitals: Why Site Speed Decides Your Google Ranking

What are Core Web Vitals, and what do LCP, CLS and INP mean? We explain how site speed shapes your Google ranking and the practical ways to fix a slow site.

Core Web Vitals: Why Site Speed Decides Your Google Ranking

A few months ago an e-commerce client came to us saying, "We've raised our ad spend, but sales are flat and we just can't climb on Google either." We opened the site, pulled up a product page on our phone, and spotted the problem within the first three seconds: images loaded late, buttons jumped around, and you had to wait two full seconds just to see the price. This wasn't an ad-budget problem. It was a Core Web Vitals problem.

For a long time, site speed was treated as a "technical detail" — something developers cared about and business owners didn't. But Google made these metrics an official ranking factor years ago. Today, how quickly and how steadily a page loads directly affects both whether a visitor stays and where you land in search results. In this post, drawing on more than a decade of building web projects, we explain Core Web Vitals in plain language, why they matter so much, and how to speed up a slow site step by step.

What exactly are Core Web Vitals?

Core Web Vitals are the three main metrics Google chose to measure the real-world experience of a page. What we casually call "site speed" isn't actually a single number; it has different dimensions — how quickly the page appears, how steadily it holds, and how fast it responds when you touch it. Google sums up these dimensions in three acronyms: LCP, CLS and INP.

The nice thing about these metrics is that, despite the engineering jargon, they measure very human things. Each one answers a single question: Is the visitor getting frustrated using this page, or does everything feel smooth?

LCP — Largest Contentful Paint

LCP measures how long it takes for the largest, most important visual element on the page (usually a hero image, product photo or big headline) to appear on screen. It's the moment the visitor thinks, "OK, the page has loaded." According to Google, a good LCP is under 2.5 seconds. Go above that, and the visitor starts to lose patience staring at a blank screen.

CLS — Cumulative Layout Shift

We've all been there: you start reading an article, an ad loads up top, and the whole text jumps down; or you're about to tap "buy" when the page shifts and you accidentally click somewhere else entirely. CLS measures exactly this — how much the page "moves around" as it loads. A good CLS value is under 0.1. Low CLS means the page sits on solid ground, not on a fault line.

INP — Interaction to Next Paint

INP is a relatively new metric that replaced the older FID. It measures how quickly the page reacts when you click a button, open a menu or type into a form. You clicked, but nothing happened, and half a second later the menu opened — that's poor INP. A good INP is under 200 milliseconds. In other words, the page shouldn't just look fast; it should feel fast when you touch it.

Charts showing site performance metrics and search analytics on a screen
LCP, CLS and INP aren't abstract; they turn the friction a real user feels into numbers.

Why does Google care about these metrics?

Google has a single goal: to put the page that offers the most relevant, best experience at the top. If two sites have similar content but one loads instantly and runs smoothly while the other jumps and freezes as it loads, which one do you think Google wants to recommend? It's not hard to guess. A fast site is a signal, in Google's eyes, that "this site respects its visitor."

There's a nuance we want to underline here: Core Web Vitals alone won't catapult you to number one. Content quality, relevance and trust are still the most decisive factors. But especially on competitive queries where closely matched sites are fighting it out, speed acts like the final weight on a scale. Between two pages of equal quality, the faster one wins.

Speed doesn't replace content; but it decides which of two good pieces of content wins.

There's also a commercial side that often matters even before SEO. A slow site loses money. The visitor won't wait for your page to load; they go to your competitor. So you should take Core Web Vitals seriously not just to avoid "Google penalizing me," but to avoid "losing my visitor." We covered this in a broader frame in our post on why your website isn't driving sales as well.

How do you measure Core Web Vitals?

The good news: measuring these metrics is completely free and takes a few minutes. We recommend three core tools; each looks at the picture from a slightly different angle.

  • PageSpeed Insights — Just paste your URL into pagespeed.web.dev. It shows your LCP, CLS and INP for both mobile and desktop in a color-coded report and adds concrete improvement suggestions at the bottom. It's the most practical place to start.
  • Lighthouse — Built right into the Chrome browser (right-click > Inspect > Lighthouse tab). It tests a single page under lab conditions, which is very handy during development when you're testing a page that isn't live yet.
  • Google Search Console — This is the truly valuable one. While the other two test a single page, Search Console collects the experience your real visitors have in the field and groups all your pages into "good / needs improvement / poor" in its "Core Web Vitals" report. It's not theory; it's data from your actual users.

One point worth stressing: lab data (Lighthouse) and field data (Search Console) sometimes disagree. Because your fast computer and fast internet aren't the same as your visitor's three-year-old phone on a weak mobile connection. When deciding what to fix, always prioritize field data.

The most common causes of slowness (and their fixes)

After auditing hundreds of sites, we can say this with confidence: the causes of slowness almost always fall under the same four headings.

Lines of code being reviewed on a screen for performance optimization
Most fixes aren't buried deep in the code; they hide in images, scripts and fonts.

1. Images

This is the culprit we run into most. A 4–5 MB photo snapped on a phone and uploaded without a single edit can wreck a page's LCP on its own. The fix is surprisingly easy: converting images to modern formats (WebP or AVIF) often cuts the file size to a third. On top of that, giving images the right dimensions and width/height attributes fixes both LCP and CLS, because when the browser knows in advance how much space an image will occupy, the page doesn't jump as it loads. Using lazy loading for images below the fold also speeds up that first paint.

2. JavaScript

Most modern sites carry more JavaScript than they need. Every plugin, every tracking tag, every chat bubble adds a bit more weight to the page and hurts INP in particular, because while the browser is busy processing all this code, it can't respond to the visitor's click. The fix is to clear out unused scripts, use third-party tools (analytics, ads, chat) sparingly, and load non-critical code at the end of the page, deferred (defer/async).

3. Fonts

A stylish custom font can leave your text invisible while the page loads, then make it pop in suddenly and shift everything around. That's both an annoying experience and a source of CLS. The fix is to host font files on your own server, use the modern woff2 format, and set font-display: swap so the text shows in a system font until your custom font is ready.

4. Hosting

Sometimes the problem isn't the site itself but the ground it stands on. A cheap, shared, slow server will hold back even the most optimized site, because seconds pass before the browser even receives the first byte (this is called server response time). Using a CDN (delivering your content from servers geographically close to the visitor), setting up proper caching and choosing a quality hosting provider all eliminate that foundational delay.

What should you focus on first?

Don't try to do everything at once. In our experience, the order of highest impact is:

  1. Optimize your images — the fastest, biggest win for the least effort.
  2. Check server response time and caching — strengthens the foundation.
  3. Clear out unnecessary JavaScript — improves INP noticeably.
  4. Fix fonts and CLS — polishes the experience.

These four steps are usually enough to move most sites' Core Web Vitals report from red to green. And none of them require rebuilding the site from scratch; most are targeted improvements to the site you already have.

Conclusion: speed isn't a luxury, it's the default

If we sum up Core Web Vitals in one sentence: Google is measuring the respect you show your visitors. A fast, stable page that responds instantly both pleases the visitor and earns you the place you deserve in search results. A slow site, on the other hand, loses both visitors and ranking every single day — and it does so quietly, without you noticing.

If you're not sure about your site's Core Web Vitals report, let's run a free performance audit with our SEO service and see together where you're losing seconds and where you're losing rankings. And if you'd like to build a fast, solid foundation from scratch, that's exactly what our web development service is for. Get in touch to talk.