Core Web Vitals: why your site's speed is revenue

A slow site isn't a "technical" problem. It's a revenue problem. Every extra second of waiting, a share of visitors closes the tab before they even see what you offer. Google knows this, and for years it has measured three numbers, the Core Web Vitals, that affect both ranking and how long people stay and buy.

Let's look at what they are, why they matter, and how we handle them in practice.

The three numbers that matter

Core Web Vitals are three metrics that describe the real experience of opening a page:

• LCP (Largest Contentful Paint): how long the biggest element takes to appear, usually the main image or headline. It's the perception of "how fast". Target: under 2.5 seconds.
• INP (Interaction to Next Paint): the time between a tap/click and the page's visible response. It's the perception of "how responsive". Target: under 200 ms.
• CLS (Cumulative Layout Shift): how much elements "jump" while the page loads. That annoying feeling of clicking a button that moves. Target: under 0.1.

Three numbers, three feelings: fast, responsive, stable.

Why they affect revenue

This isn't theory. These are correlations measured across millions of sessions:

• every loading delay raises the chance of leaving before any interaction;
• a layout that jumps makes people click the wrong thing, and they leave frustrated;
• Google uses Core Web Vitals as a ranking signal: with equal content, the faster site wins.

In an e-commerce store or an acquisition landing page, this turns into more completed checkouts and leads, or fewer. Performance isn't an end-of-project detail: it's a commercial lever.

Where problems come from (and how we avoid them)

Most slow sites suffer from the same mistakes, almost all preventable while building:

1. Heavy, unsized images. We serve them in modern formats, with explicit dimensions to avoid jumps (CLS) and lazy loading for anything below the fold.
2. Render-blocking fonts. We use font-display and preload critical fonts, so text shows up immediately instead of leaving blank gaps.
3. Too much JavaScript. Every library has a cost. We ship only the code that's needed, split and deferred, so the page becomes interactive sooner (INP).
4. Unreserved space. Banners, ads and embeds that appear later push everything around: we reserve the space upfront.

None of this needs magic: it needs treating performance as a requirement, not an afterthought.

How we keep it under control

The rule we follow is simple: what you don't measure, you can't improve.

• We measure Core Web Vitals in the field (real users) and in the lab before every release.
• We set a performance budget: if a change degrades the numbers past a threshold, it doesn't ship.
• On every deploy we check that LCP, INP and CLS stay green, not once, but over time.

The result is a site that stays fast even after months of additions, not just on launch day.

In short

Core Web Vitals aren't a checklist to please Google: they're the most honest way to measure whether your site respects people's time. A fast, responsive, stable site converts more, ranks better and costs less to maintain.

If you want to know how your site performs today, and what it would take to get it into the green, we can take a look together.