Why Your Core Web Vitals Are Costing You Leads (and How to Fix Them)

The three numbers Google actually scores you on

Core Web Vitals reduce a complex user experience to three measurable thresholds. Pass all three and Google considers your page 'good'. Miss any and you sit in 'needs improvement' or 'poor' — visible in Search Console, factored into rankings, and almost always reflected in your conversion rate.

• Largest Contentful Paint (LCP) — how long the largest visible element takes to render. Target: under 2.5 seconds.
• Interaction to Next Paint (INP) — how responsive the page feels when a user taps or types. Target: under 200ms.
• Cumulative Layout Shift (CLS) — how much the page jumps around as it loads. Target: under 0.1.

Why this is a revenue problem, not just an SEO problem

Every major study from Google, Akamai, Deloitte and Cloudflare has found the same curve: every additional second of load time costs conversion. On mobile, it's brutal — sites that load in one second convert roughly three times higher than sites that take five.

If your site does $500k a year off organic and direct traffic, a passing-to-failing CWV profile is plausibly costing you $80–150k. That's the bill you don't see, because the customers who left never told you why.

Why most WordPress + page-builder sites fail

It's not the platform's fault, exactly. It's the cumulative weight of how these sites typically get built: a heavy theme, a page builder, fifteen plugins, eight tracking pixels, a chat widget, web fonts loaded from three providers, and unoptimised hero images. Each addition feels small. The stack is anything but.

When we rebuild a site for performance, the most common single win isn't 'better hosting'. It's a 60–80% reduction in JavaScript shipped to the browser, by replacing a builder-heavy stack with a modern framework that ships only what each page actually needs.

Where to look first

Run a real PageSpeed Insights test (mobile, not desktop, on a real URL — not the homepage only). Then attack in this order:

• The LCP image. It's almost always your hero. Serve it as WebP or AVIF, dimensions matched to the viewport, with width and height attributes set, fetchpriority='high', and preloaded in the head.
• Third-party scripts. Chat widgets, analytics, marketing pixels, A/B testing — every one delays interactivity. Audit ruthlessly, defer aggressively, and load on interaction where possible.
• Web fonts. Self-host the two weights you actually use, set font-display: swap, and stop loading the other six.
• Layout shift. Reserve space for images, embeds and ads. Avoid late-loading banner notices. Set aspect ratios on every media element.
• JavaScript bundle size. If your homepage ships more than 200KB of JS, you have a bundling problem, not a hosting problem.

When 'add a caching plugin' isn't the answer

Caching plugins help when the server is slow to generate HTML. They don't fix LCP if your hero image is 2MB. They don't fix INP if you're loading 800KB of unused JavaScript. They don't fix CLS if your layout shifts because half your fonts swap in two seconds after the page renders.

The honest answer for a lot of sites in 2026 is that the underlying build has aged out. The right move is a modern front-end on a stack that scores 90+ on mobile by default — and then never has to think about CWV again.

The payback compounds

Half a second faster on mobile typically lifts both rankings and conversion. Better rankings bring more traffic; better speed converts more of it; better conversion funds more of the work that drives both. It's the rare optimisation that pays back twice — and then keeps paying.