What Are Core Web Vitals (and Why They Affect Your Sales)

There's a moment, before anyone reads a single word on your website, when they've already formed an opinion. They're not consciously aware of it, but they feel it: the page takes too long to appear, tapping a button does nothing for an agonizing second, or right as they're about to click something, the content jumps and they end up tapping something else entirely. Google put a name to that feeling a few years ago and turned it into a metric. It's called Core Web Vitals, and despite sounding like developer jargon, it's really about something very human: whether your website is pleasant to use or not.

The three metrics, explained without the technical noise

Core Web Vitals are three indicators that measure different moments of the browsing experience. They're not abstract or arbitrary — each one corresponds to a specific instant when someone might decide to stay or leave.

LCP (Largest Contentful Paint) measures loading speed. Specifically, how long it takes for the largest visible element on the screen — usually a header image, a big headline or a video — to render after someone lands on the page. If LCP takes longer than two and a half seconds, the sense of slowness is already noticeable. Past four seconds, a significant share of visits leave before seeing anything at all.

INP (Interaction to Next Paint) measures responsiveness. It replaced an older metric a while back because it better captures what actually causes frustration: the time between someone clicking, tapping or typing something, and the moment the screen actually responds to that action. A menu that's slow to open, an "add to cart" button that doesn't react instantly, or a form that freezes for a beat are all INP failures. When that happens, the feeling isn't "this site is slow" — it's "this site is broken."

CLS (Cumulative Layout Shift) measures visual stability. It's that all-too-familiar moment of being about to tap a button when, at the last second, the content shifts because an image, an ad or a font finished loading, and you end up tapping something you didn't mean to. CLS quantifies how much a page's content moves around while it loads. The higher it is, the more unstable — and more irritating — the site feels to browse.

All three metrics share the same purpose: turning something that used to be described only as a "feeling" into an actual number. And it turns out that feeling is measurable, and it has consequences.

Why Google turned them into a ranking factor

Google didn't introduce Core Web Vitals out of technical whim. It introduced them because its stated goal has always been the same: return the results that best resolve what someone is searching for, and a website that loads poorly or is frustrating to use doesn't resolve anything, no matter how good its content is.

This doesn't mean technical performance outweighs content quality in rankings — it still doesn't. But it does mean that between two pages with similar content and comparable relevance, the one offering a more solid experience has the edge. And in competitive markets, where several businesses offer nearly the same thing, that marginal edge can be exactly what decides who shows up first.

There's something more important than ranking, though: Core Web Vitals are, above all, a reliable indicator of real user experience. Google uses them for ranking because they reflect something that matters directly to your business too, regardless of what the search engine does with them. Optimizing them isn't "doing Google a favor." It's taking care of the experience of the people who have already made it to your website.

Key point: Core Web Vitals aren't an algorithm's whim. They're Google's way of measuring something that matters to you too: whether your website is pleasant to use, or whether it's pushing people away before they buy.

Why a slow or unstable website loses sales even when it looks great

Here's the point that actually matters for any business: visual design and technical performance are two different things, and a website can fail at the second one even while excelling at the first.

You can have flawless art direction, careful photography, a coherent color palette and typography that says exactly what you want it to say. If that website takes four seconds to load its main image, a large share of the people who land on it — especially from mobile, which is where most traffic comes from today — will never get to appreciate any of that. They'll already be gone.

The same happens with stability. A contact form that jumps right as someone is about to type their phone number, or a buy button that shifts at the last second, doesn't just cause a passing annoyance. It creates distrust. And on a commercial website, distrust translates directly into fewer contacts and fewer sales, no matter how excellent the design behind it is.

This connects to something we always work through from the start of a project: a well-planned custom website isn't just an aesthetic decision. It's a decision that directly affects how that website behaves in the real world — with slow connections, mid-range phones and users who have little patience.

What usually sits behind a website with poor Core Web Vitals

In practice, the same handful of causes tend to ruin a website's performance again and again, and almost none of them come down to bad luck.

Unoptimized images. By far the most common cause of a poor LCP. Uploading a twelve-megapixel photo straight from a camera or phone, without compressing or resizing it, forces the browser to download far more data than necessary before it can display anything.

Excessive scripts and plugins. Every widget, every floating chat box, every analytics script added "just in case" adds weight and execution time. Once several of these pile up, the browser has to process so much code before it can respond to the first interaction that INP suffers noticeably.

Poorly configured WordPress themes and templates. Many generic templates ship loaded with features that most sites never use: heavy visual page builders, full icon libraries hundreds of times larger than needed, animations that load even when they're never seen. All of that gets downloaded regardless, and all of it drags performance down.

Ads and pop-ups that shift the content. A badly implemented cookie banner, a subscription pop-up that appears with a delay, or an ad that reserves its space too late are the most direct and most avoidable cause of poor CLS. They're also the elements that are easiest to fix, simply by reserving their space from the very start of the design.

Why this gets solved in the process, not after the fact

The usual temptation, once a website already has performance problems, is to look for a plugin or a tool that "fixes" Core Web Vitals in one go. Some solutions genuinely help ease the symptoms, but they rarely resolve the cause, because performance isn't an adjustment you bolt on at the end — it's a direct consequence of how the website was built from the start.

When we design and develop a website, we decide from the very first sketch which images are actually necessary on each screen and in what format they should be served, which features are worth their weight in code and which don't offer enough value to justify it, and how each element's space gets reserved so nothing jumps around while the page finishes loading. That way of working has a direct effect on a project's budget and scope, something we also cover in detail in our guide on what a professional website costs: solving performance properly is part of serious work, not an optional extra.

The result isn't just a website that scores well in a measurement tool. It's a website that feels solid to use, that doesn't create friction at the exact moment someone is about to decide, and that supports the design work instead of quietly undermining it.

If you want to know how your website performs today, or you suspect that slowness or instability might already be costing you visits and leads without showing up in any report, we can look into it together. You can see examples of how we've solved this in other projects or simply get in touch and we'll talk it through.