Website speed and Core Web Vitals: why it is money

Picture someone on their phone. They tap your product, the screen is still grey and thinking, and after two seconds they back out and tap the next result in Google. That result opened instantly. The sale was decided before your headline ever showed up. Open your own analytics and the pattern is right there: the slower the page, the fewer people ever reach the form, the cart or the “Buy” button.

Google took that gut feeling and gave it numbers. The set is called Core Web Vitals, and it’s how the browser measures how quickly and smoothly a page actually loads for a real person, not for a server in a data centre. This article walks through what the three metrics mean, how they touch both your revenue and your search rankings, what tends to bog a site down, and what a properly fast build looks like underneath.

What Core Web Vitals are in plain terms

There are three of them. Each one stands in for something a visitor feels in the first few seconds, told from their side of the screen rather than the server’s.

• LCP (Largest Contentful Paint) measures when the biggest thing on the first screen finally shows up, usually your main image or heading. Roughly, it’s the moment the page looks ready. You want it under 2.5 seconds.
• INP (Interaction to Next Paint) is about response. Someone clicks, taps, or types into a field, and this is the lag before anything happens back. Half a second of nothing and the page feels jammed. Aim under 200 milliseconds, which is faster than it sounds.
• CLS (Cumulative Layout Shift) tracks how much the layout jumps around while it loads. You’ve done it yourself: you go to tap a button, the content shifts under your thumb, and you hit an ad instead. Keep it below 0.1.

Strip away the acronyms and it’s one ordinary question turned into numbers: in the first few seconds, is your site a pleasure or a chore to use? The decimals are just the paperwork.

There’s a catch worth knowing. Google scores these on real visitors (what’s called field data), not on a clean lab run. “It loads fine on my laptop” proves nothing, then. The yardstick is the ordinary phone and patchy mobile signal your actual customers are using.

Why speed affects conversion and SEO

Two separate things are going on, and both reach into your wallet.

Take conversion first. Every extra second of waiting is a few more people gone. On mobile it gets brutal, because plenty leave before the first screen has even drawn. And the damage isn’t only that first impression. It runs through the whole visit: a cart that hesitates, catalogue filters that lag a beat behind every tap, a form that stalls after you click submit. Each of those moments quietly sheds people who had already half-decided to get in touch.

Then there’s search. Core Web Vitals are an official Google ranking factor, stated outright. They won’t drag thin content to the top on their own, but when two pages are otherwise even, the slow one loses. The effect compounds, too. Visitors who bounce off a sluggish page send Google a poor signal, and a lighter site lets the crawler get through more of your pages. The technical groundwork underneath all of this is in the SEO foundation of a new site.

Now add paid ads. Point a campaign at a slow landing page and you’re buying clicks from people, half of whom give up before they see anything. You can read that loss straight off your cost per lead.

What actually makes sites slow

Open enough slow sites and the same handful of causes keep turning up.

Heavy images are usually first. One 4 MB photo, saved in a format the browser struggles to unpack, will sink a page on its own: no compression, no modern format like WebP or AVIF, no smaller copy made for phones.

Then the platform itself. A site built on Tilda, Wix, or a stuffed WordPress theme hauls around a load of third-party code you’ll never use but every visitor downloads anyway. There’s more to that story than speed, and we get into it in site builder vs custom development.

Third-party scripts pile up next. A chat widget, a couple of pop-ups, a visitor counter, two or three analytics systems, a tracking pixel for every social network you’ve ever posted on. Every one of them adds a little delay before the page can react to a tap, which is exactly what INP measures.

The last two are quieter. With no caching or CDN, the site is rebuilt from scratch on every visit and the files come from one far-off server instead of one near your visitor. And unoptimised fonts and styles make the page sit blank until everything arrives, or shove the text sideways the moment the font finally lands, which is where those layout jumps come from.

None of this is baked into the web. Each one traces back to a decision made while the site was being built, which is precisely why each one can be undone.

What a genuinely fast build looks like

No miracle plugin does this. A fast site is just a stack of sensible choices that add up:

• Images get optimised on their own: modern format, sensible compression, a size that fits the screen they’re shown on, and anything below the fold held back until you scroll to it.
• Each page carries only the code that page actually needs, instead of the whole toolbox loaded “just in case.”
• Pages that don’t change by the second are served ready-made rather than reassembled from scratch on every request.
• A CDN and caching keep files close to the visitor and stop the same things downloading twice.
• Analytics and widgets are placed so they load alongside your content instead of holding it hostage.

Approach	Typical mobile LCP	Metric stability
Heavy template or out-of-the-box builder	4 to 6 s and up	drifts, often in the red
Custom build with optimisation	under 2.5 s	reliably green

So we build on a light stack with static generation, which makes speed the resting state instead of a frantic scramble the week before launch. Already have a site that drags? That doesn’t always mean tearing it down to the studs. Often the answer is a redesign and technical rework: we move your content onto a fast stack, tidy the code, sort out the images, and pull the metrics back into the green.

Where to start if your site is already slow

A few steps you can take before changing anything big:

• Test on a real phone, not a fast laptop on wired internet. The phone is what your customers actually live with.
• Run the page through PageSpeed Insights. It gives you both the field and lab numbers and points to the specific problems.
• Start with images. Nine times out of ten it’s the cheapest, fastest win on the board.
• Tally up your third-party scripts and weigh each one. Does it earn back what it costs you in speed?

Do all that and if the numbers are still red, the trouble is in the foundation, not the settings. Past that point, tweaking on and on quietly costs more than rebuilding the base once and being done with it.

If you’d like to know why your own site drags and what would actually help, send over a few sentences about the project or get in touch. We’ll read the metrics and tell you plainly where the bottleneck sits, then say whether a rework would pay for itself.