Core Web Vitals: Why Load Time Decides Whether You Get Enquiries

Since 2021 Google has measured how fast and stable a website feels, and uses those measurements as a ranking factor. The three metrics are called Core Web Vitals.

For a business owner the practical meaning matters more than the names: a slow site loses visitors before it becomes visible and drops in search results. Both cost enquiries.

This article explains what is measured, how to check your own site in two minutes, and which causes can realistically be addressed.

Check your own site first

Before reading on, run the test. Two minutes, and you get numbers instead of guesses.

1. Open pagespeed.web.dev
2. Enter your address
3. Wait about thirty seconds
4. Look at the Mobile tab, not Desktop

The mobile score is the one that counts, because Google evaluates the mobile version first and most of your visitors come from phones.

How to read it:

• 0–49 (red): action needed, you are measurably losing visitors
• 50–89 (orange): room for improvement
• 90–100 (green): good

For comparison: this site scores 99 on mobile. You can verify that yourself — which is rather the point of a metric like this.

What the three metrics mean

LCP — when the main content becomes visible

Largest Contentful Paint measures how long it takes for the largest visible element to load. Usually that is an image or a large heading.

In plain terms: how long does the visitor stare at a half-empty page before seeing what it is about?

Target: under 2.5 seconds. Over 4 seconds is considered poor.

CLS — whether the layout jumps while loading

Cumulative Layout Shift measures how much elements change position while the page loads.

You know the experience: you go to tap a link, an image loads above it at that exact moment, everything shifts down, and you tap something else. That is layout shift.

Target: under 0.1.

The most common cause is images without defined dimensions. The browser does not know how much space to reserve and pushes everything aside as it loads.

INP — how quickly the page responds to input

Interaction to Next Paint measures the delay between a user action (tap, click) and the visible response.

If you tap a menu and nothing happens for half a second, the INP score is poor. Usually the cause is too much JavaScript blocking the browser.

Target: under 200 milliseconds.

The most common causes of poor scores

Sorted by how often they occur in practice.

1. Unoptimised images

By a wide margin the most common cause. A photo straight from a phone camera is four to eight megabytes. On a website that same image needs about 200 kilobytes — forty times smaller, at practically identical visible quality.

What helps:

• Scale images to the size actually needed (not 4000 pixels wide when displayed at 800)
• Use a modern format: WebP or AVIF instead of JPEG
• Set width and height in the code so nothing jumps
• Load images below the fold only when scrolled into view

Image optimisation alone delivers the single biggest gain on most websites.

2. Too many scripts

Every plugin, every tracking tool, every chat widget loads its own code. On a WordPress site with twenty plugins, two megabytes of JavaScript accumulates quickly, and the browser must process it before the page responds.

What helps: clear it out. Every plugin without a clear purpose goes. Tracking scripts nobody reviews, likewise.

3. Externally loaded fonts

Fonts from third-party servers (typically Google Fonts) delay rendering: the browser must establish an additional connection before text becomes visible.

What helps: self-host the fonts. This improves load time and simultaneously resolves a data protection issue — more on that in my Impressum and GDPR article.

4. Slow hosting

Budget hosting at three euros a month shares a server with hundreds of other sites. Server response time feeds directly into the LCP score.

What helps: better hosting, or a CDN that delivers content from a server near the visitor.

5. Page builders

Visual builders like Elementor or Divi generate bloated markup: nested containers where a single element would have sufficed. Convenient when building, expensive when loading.

What helps: hard to fix retroactively. This is one reason a relaunch often makes more sense than optimisation on older sites.

What can realistically be improved

Not every problem is equally solvable. An honest assessment.

Quick and inexpensive:

• Optimise images (biggest effect, least effort)
• Remove unused plugins
• Self-host fonts
• Enable caching

Moderate effort:

• Change hosting
• Set up a CDN
• Defer script loading

Only with a rebuild:

• Remove page builder markup
• Fix fundamental architecture problems
• Change framework

On a typical WordPress site the first four measures often deliver 20 to 30 points. From 45 to 70 is realistic. From 45 to 95 usually is not, without changing the foundation.

What load time means in practice

The metrics are not an end in themselves. They describe what visitors experience.

Someone staring at a white page for three seconds goes back to Google and clicks the next result. That is not a conscious decision but a habit. Google registers the quick bounce and treats it as a signal that the page did not fit.

Add the context: your customers do not view your site on a fibre connection. They view it on a train, on a building site, during a lunch break with poor reception. What feels fast in an office can be painfully slow there.

That is why the mobile score matters more.

The reverse does not follow, though: if your site does not appear in the results at all, load time is almost never the reason. That is a different problem with different causes — why a website cannot be found on Google.

Frequently asked questions

Are Core Web Vitals really a ranking factor? Yes, but not the most important one. Content and relevance count more. Between comparable pages, speed becomes the tiebreaker — and the effect on bounce rate works independently of ranking.

My desktop score is 95, mobile only 40. Which counts? Mobile. Google indexes mobile-first and most visitors come from there.

How often should I measure? After every significant change, and roughly quarterly otherwise. Scores degrade gradually as content and plugins accumulate.

Why do the numbers vary between tests? PageSpeed Insights simulates a connection with some variance. Differences of five to ten points are normal. Watch the trend, not individual measurements.

Is optimising an old site worth it? Up to a point. If after image optimisation and plugin cleanup you are still below 50, the problem is in the foundation. Then a rebuild is usually more economical than further optimisation.

Summary

Measure first. Two minutes with PageSpeed Insights says more than any assumption.

If the mobile score is below 50, start with images — almost always the biggest bottleneck and the easiest to fix. Then clear out plugins and self-host fonts.

If the score stays low after that, the issue is structural. At that point the question is no longer optimisation but whether a rebuild is worthwhile.

If you want to know what specifically is holding your site back, send me the address. I will look at the metrics and tell you what is worth doing and what is not.