Page Speed and Conversion Rate: The Math Most Marketers Ignore

Page speed and conversion rate are linked by one of the most consistently-measured effects in digital marketing. Every 100 milliseconds of additional load time costs measurable conversion. At 4 seconds load time vs 1.5 seconds, conversion rates roughly halve.

This guide covers the speed-conversion relationship in concrete terms — Core Web Vitals thresholds, what each metric actually means, where most sites leak speed, and the specific fixes that deliver the biggest conversion lift. By the end you will know exactly which speed levers move revenue and which are vanity metrics.

The math is direct. Most sites can lift conversion rate 15 to 50 percent through systematic speed optimization in 30 to 60 days.

The conversion-speed relationship

Page speed affects conversion in two compounding ways.

Direct bounce rate effect

Every additional second of load time increases bounce rate. At 1 second LCP, bounce rate is baseline. At 3 seconds, bounce rate is up ~32 percent. At 5 seconds, it is up ~90 percent. At 7 seconds, it is up ~123 percent.

These are real measured effects across the open web. The slower your page, the more visitors leave before it even renders.

Conversion-among-stayers effect

Even among visitors who stay, slower pages convert worse. Friction compounds: slow LCP means slow time-to-interactive means slow form responsiveness means abandonment.

A site that loads in 4 seconds and stays slow throughout the session converts at half the rate of a fast equivalent.

We covered the broader CRO foundation in our conversion rate optimization guide. Speed is the foundation that every other CRO tactic stands on.

Core Web Vitals — what each metric measures

Google's Core Web Vitals are three specific metrics that quantify perceived speed and responsiveness.

Largest Contentful Paint (LCP)

The time from page navigation to when the largest visible content element finishes rendering. Usually a hero image, a video poster, or a large headline.

Targets:

• Good: under 2.5 seconds
• Needs improvement: 2.5 to 4 seconds
• Poor: over 4 seconds

LCP is the most important single speed metric for conversion. Below 2.5 seconds, visitors perceive the page as fast. Above 4 seconds, they abandon.

Interaction to Next Paint (INP)

The time from a user interaction (tap, click, key press) to the next visual update. Replaced First Input Delay (FID) in 2024.

Targets:

• Good: under 200 milliseconds
• Needs improvement: 200 to 500 ms
• Poor: over 500 ms

INP matters most on interactive pages — forms, checkouts, product configurators. A page that loads fast but feels sluggish to interact with bleeds conversions.

Cumulative Layout Shift (CLS)

How much the visible content moves around during page load. A score from 0 to 1.

Targets:

• Good: under 0.1
• Needs improvement: 0.1 to 0.25
• Poor: over 0.25

High CLS causes accidental clicks — buttons shift just as the user taps them, and they end up on a different page. This is the silent killer of conversion on layout-shifting sites.

Where most sites lose speed

After hundreds of speed audits, the same culprits show up.

Unoptimised hero images

Hero images delivered at 1.5 to 3 MB on mobile is the single most common LCP killer. Compression to 100 to 300 KB at proper dimensions cuts LCP by 1 to 3 seconds.

Third-party scripts blocking the main thread

Analytics, chat widgets, A/B testing tools, social pixels, marketing tags all add JavaScript that blocks the main thread. Combined, they often add 1.5 to 4 seconds to LCP.

Render-blocking CSS

CSS files in the head that take 300 to 800 ms to download and parse before the page can render at all. Common offenders: heavy Bootstrap or theme CSS bundles.

Slow servers and unoptimised hosting

A shared hosting server with 800 ms TTFB (time to first byte) cannot achieve good LCP no matter how optimised the front-end is. Cheap hosting is often the bottleneck.

Web fonts loaded synchronously

Custom fonts that block render until they download cause the "flash of invisible text" pattern. Each web font adds 100 to 400 ms to LCP if not handled properly.

Heavy DOM with deep nesting

Pages with 3,000+ DOM nodes or 30+ levels of nesting slow down everything. Common in legacy WordPress sites with bloated themes.

The diagnostic order — fix the highest-leverage issues first

When optimising for speed, the order matters. Some fixes deliver 1 to 3 seconds of LCP improvement. Others deliver 30 milliseconds.

Step 1 — Run PageSpeed Insights

Pull your top 3 pages through PageSpeed Insights. Note the Core Web Vitals scores on both mobile and desktop.

Mobile scores matter more for conversion because most traffic is mobile. Desktop scores matter for SEO.

Step 2 — Identify the LCP element

PageSpeed Insights tells you which element is the LCP. Usually it is the hero image.

If LCP is an image, image optimization is the highest-leverage fix. If LCP is text, you have a render-blocking resource problem. If LCP is a video poster, video lazy-loading and compression matters most.

Step 3 — Audit third-party scripts

Open the Network tab in Chrome DevTools. Filter to JavaScript. Sort by size. Identify scripts larger than 100 KB that load on every page.

Each of these is a candidate for deferral or removal. Question every script: does this need to run before first paint, or can it wait?

Step 4 — Check hosting TTFB

Time to first byte under 200 ms is good. 200 to 600 ms is okay. Above 600 ms means your hosting is bleeding speed.

If TTFB is high, upgrading hosting often delivers the single biggest LCP improvement.

Image optimization — usually the biggest single win

For most sites, images are the largest contribution to page weight and LCP.

Use WebP or AVIF formats

WebP delivers 25 to 35 percent smaller file sizes than JPEG at equivalent quality. AVIF is 40 to 60 percent smaller but with less universal browser support.

Modern stacks should serve AVIF when supported, WebP as fallback, JPEG only for legacy browsers.

Resize images to actual display dimensions

Serving a 4,000 x 2,000 image for a 1,200 x 600 hero is the most common image mistake. The browser downscales it but downloads the full size first.

Resize to actual display dimensions before upload. Provide multiple sizes for responsive layouts using srcset.

Lazy-load below-the-fold images

<img src="hero.webp" alt="Hero" loading="eager">
<img src="below-fold.webp" alt="Below fold" loading="lazy">

Lazy loading defers below-the-fold images until they near the viewport. Cuts initial page weight dramatically.

The hero image should be loading="eager" (or omit the attribute — eager is default). Everything else should be loading="lazy".

Use fetchpriority="high" on the LCP image

For the single LCP image, set fetchpriority="high" so the browser knows to prioritise it.

<img src="hero.webp" fetchpriority="high" alt="Hero">

This signals the browser to fetch this image before other resources, cutting LCP by 200 to 800 ms in many cases.

Compress aggressively

For WebP at quality 80 to 85, most photos look indistinguishable from the original. Tools like Squoosh, ImageOptim, or Sharp (in build pipelines) handle this automatically.

A 2 MB JPEG can usually compress to 200 to 400 KB WebP without visible quality loss.

JavaScript optimization

JavaScript is where most modern site speed dies.

Defer non-critical scripts

<script src="analytics.js" defer></script>
<script src="chat-widget.js" defer></script>

defer lets the script download in parallel with HTML parsing and runs after the document is parsed. Cuts main-thread blocking dramatically.

Use defer on every script that does not need to run before first paint. That covers most analytics, chat widgets, social pixels, and marketing tags.

Code split application JavaScript

For sites with substantial front-end code, code splitting delivers only the JavaScript needed for the current page. Tools like Webpack, Rollup, and Vite handle this automatically.

A 500 KB JavaScript bundle is often reducible to 80 to 150 KB per page through code splitting.

Remove unused JavaScript

Coverage tab in Chrome DevTools shows what percentage of each script actually runs. Scripts with under 30 percent usage are candidates for removal or replacement.

Common bloat sources: jQuery on sites that no longer need it, full UI libraries when only 2 components are used, polyfills for browsers you no longer support.

Audit third-party tag managers

Google Tag Manager and similar tools can load 5 to 30 scripts depending on configuration. Audit which tags are actually firing and remove unused ones.

A bloated GTM is often the single biggest JavaScript performance issue on enterprise sites.

CSS optimization

CSS issues are smaller wins than JavaScript but still meaningful.

Inline critical CSS

The CSS needed to render the above-the-fold content should be inlined in the <head>. Everything else can be loaded asynchronously.

This eliminates the CSS round-trip from the LCP critical path, cutting 100 to 400 ms.

Remove unused CSS

Tools like PurgeCSS or built-in tree-shaking in modern build tools strip unused CSS. Most sites have 60 to 80 percent unused CSS shipping with every page.

Avoid CSS imports in CSS files

@import url(...) in CSS creates a chain — the browser parses the first file, then has to fetch and parse the imported one. Each chain step adds latency.

Bundle all CSS into a single file or use HTTP/2 push, not CSS imports.

Web font optimization

Custom fonts add weight and can block rendering.

Use font-display: swap

@font-face {
  font-family: 'Brand';
  src: url('brand.woff2') format('woff2');
  font-display: swap;
}

font-display: swap lets text render in a fallback font immediately, then swap to the custom font when it loads. No flash of invisible text.

Preload critical fonts

<link rel="preload" href="brand.woff2" as="font" type="font/woff2" crossorigin>

Preloading tells the browser to fetch the font immediately, parallel with HTML. Cuts the swap delay.

Subset fonts to the characters you actually use

A full font file can be 200 to 400 KB. Subsetting to only the characters used (Latin only, no Cyrillic, no rare symbols) can cut it to 30 to 80 KB.

For multi-script sites (Latin + Arabic on our own site, for example), subset per language and load conditionally.

Hosting and CDN

Server speed is the foundation. Front-end optimization cannot save a slow server.

TTFB targets

• Good: under 200 ms
• Needs improvement: 200 to 600 ms
• Poor: over 600 ms

If your TTFB is above 600 ms, no front-end fix will produce great Core Web Vitals.

Use a CDN

Cloudflare, Fastly, Bunny CDN — any modern CDN. Reduces TTFB for visitors far from your origin server, caches static assets, and offers basic optimization (image conversion, JavaScript minification) automatically.

For most SMEs, Cloudflare's free tier covers the essentials. Bunny CDN at €1 per month per site delivers similar results without the complexity.

Modern hosting matters

Cheap shared hosting (€3 to €5 per month) often delivers 800+ ms TTFB. Modern managed hosting (Vercel, Netlify, modern WP hosts) typically delivers 80 to 200 ms TTFB.

The hosting upgrade is often the single best speed improvement on legacy sites.

A 30-day page speed optimization plan

If your Core Web Vitals are failing, follow this sequence.

Days 1 to 3 — Audit. Pull all key pages through PageSpeed Insights. Capture LCP, INP, CLS on both mobile and desktop.

Days 4 to 10 — Images. Compress and resize. Switch to WebP. Add fetchpriority="high" on LCP image. Lazy-load below-fold images.

Days 11 to 17 — JavaScript. Defer non-critical scripts. Audit third-party tags. Remove or replace unused scripts.

Days 18 to 23 — CSS and fonts. Inline critical CSS. Add font-display swap. Preload critical fonts.

Days 24 to 28 — Server. Audit hosting TTFB. Enable CDN. Consider hosting upgrade if TTFB is poor.

Days 29 to 30 — Measure. Compare Core Web Vitals to baseline. Most sites move from "poor" to "good" on LCP in this window.

Speed wins that compound conversion

When speed improvements ship, watch conversion rate over the next 30 days. Common patterns:

• Mobile conversion lifts 10 to 30 percent immediately
• Desktop conversion lifts 5 to 15 percent
• Bounce rate drops 15 to 35 percent
• Pages per session rises 10 to 25 percent

These are not speed metrics — they are business metrics that speed directly enables.

We covered the broader Google Ads ROI angle in our web performance and Google Ads ROI guide. The same speed work that lifts conversion also lifts paid acquisition efficiency.

Common speed mistakes

These are the patterns we see most often.

Ignoring mobile scores. Mobile speed matters more than desktop. Optimise for mobile first.

Optimising the wrong metric. Lighthouse Performance Score is not Core Web Vitals. Focus on LCP, INP, CLS.

Adding speed tools without removing slow ones. Installing 3 caching plugins does not double the speed. Audit what is actually contributing.

Skipping image optimization. Often the single biggest win, often skipped because it feels tedious.

Trusting only synthetic tests. Lab data from Lighthouse and field data from CrUX (Chrome User Experience) tell different stories. Both matter.

Ignoring TTFB. Front-end optimization cannot save slow hosting.

Frequently asked questions

What is the most important speed metric for conversion?

Largest Contentful Paint (LCP). Below 2.5 seconds is the threshold where conversion rate stabilises. Above 4 seconds is where bounces accelerate.

How much can I lift conversion with speed optimization?

Most sites see 15 to 50 percent conversion lift from systematic speed work. The magnitude depends on starting speed — slow sites have more to gain.

Will faster speed lift SEO rankings?

Yes, indirectly. Core Web Vitals are a ranking factor. The bigger benefit is conversion rate, which raises engagement metrics, which compound into ranking improvements.

Do I need a developer to optimise speed?

For deep optimization, yes. For basic wins (image compression, lazy loading, CDN), modern site builders and WordPress plugins handle most of the work. SMEs often get 70 percent of the gain without developer involvement.

How much does speed optimization cost?

Free for basics (image compression, lazy loading, deferring scripts). €100 to €500 for plugins or CDN upgrades. €2,000 to €10,000 for full optimization with developer involvement.

How long does speed optimization take?

Quick wins (images, lazy loading, CDN) take 5 to 10 hours of work and ship in a week. Full optimization (server, code splitting, font optimization) takes 3 to 6 weeks of methodical work.

Get a speed audit

We audit page speed and conversion impact free of charge. Within 48 hours we deliver a prioritised list of fixes ranked by expected conversion lift.

Book a free 30-minute audit. We screen-share, walk through your Core Web Vitals and competitor benchmarks, and you leave with a clear action plan.

Or explore our CRO service for the full system we run on client accounts.