Page speed and conversion: how much does a second really cost?

Every fraction of a second your page takes to load, a slice of your visitors makes a quiet decision: is this worth waiting for? Often, they decide it is not. They leave before your form renders, before your pricing appears, before you have had a chance to persuade them of anything.

That abandonment is not hypothetical, and it is not free. It compounds across every campaign you run, every ad dollar you spend, every organic visitor you earn. Speed sits upstream of every other conversion intervention, which means it deserves the same rigour you would give to copy, layout, or a pricing test.

Why speed kills conversions: the mechanism #

Slow pages do not just inconvenience users. They erode trust.

When a page stalls, the browser gives almost no feedback. The visitor sees a blank screen, a spinner, or a half-drawn layout. In that gap, uncertainty creeps in. Is the site broken? Did my click register? Is this company even real? On mobile, where most web traffic now originates, that uncertainty is amplified by variable networks and small screens that make every loading artifact more visible.

Perceived performance is a proxy for perceived quality, and perceived quality is a proxy for trust.

Abandonment is steepest at the very start of the load. A visitor who would tolerate a few seconds on a site they know will not extend that patience to an unfamiliar brand. First impressions form in the first moments of visible content. If that content is a blank screen, the impression is formed by absence.

The chain is straightforward: slow load raises perceived risk, perceived risk raises hesitation, and hesitation lowers the probability of conversion. You do not need a study to accept the logic. You need measurement to learn what it costs your site, with your audience, on their devices.

Core Web Vitals: what Google measures and why it matters #

Google’s Core Web Vitals are the clearest shared framework for diagnosing how a page’s performance actually feels. Three metrics carry the load:

• LCP (Largest Contentful Paint): how long until the main content block (usually the hero image or headline) becomes visible. This is the dominant “is it loaded?” signal. The threshold for a good experience is under 2.5 seconds.
• INP (Interaction to Next Paint): how quickly the page responds when someone clicks, taps, or types. A poor INP means the page looks ready but feels broken. Good is under 200 ms.
• CLS (Cumulative Layout Shift): how much the layout jumps around as the page settles. A button that shifts the instant before a tap is both maddening and a conversion killer. Good is under 0.1.

These matter for two independent reasons. First, Google uses them as a ranking input: weak Core Web Vitals can suppress your organic reach before a visitor ever arrives. Second, they map directly onto the experiences that drive abandonment.

CLS deserves special attention on lead-gen and e-commerce pages. If a form or CTA shifts position as the page loads (because a late image, ad, or web font pushed everything down), visitors either misclick or lose confidence and stop. The fix is mundane (reserve space for images, ads, and fonts), and the payoff is direct.

Lab vs field: measure what is actually happening #

There are two modes of speed measurement, and conflating them is the most common mistake operators make.

Lab measurement (PageSpeed Insights, Lighthouse, WebPageTest) runs your page in a controlled environment with a fixed device and connection. It is excellent for diagnosing specific technical faults and tracking progress against a known baseline. Its limit: it does not reflect the messy reality of real users.

Field measurement (also called Real User Monitoring, or RUM) captures performance from actual visitors on their actual devices and networks. Google’s Chrome User Experience Report (CrUX) is the most accessible source, and PageSpeed Insights shows it beside the lab score. Google Search Console’s Core Web Vitals report groups field data by page type so you can see which templates fail.

The gap between lab and field is often wide. A page that scores well on a fast simulated connection can perform badly for mobile users on congested networks far from your server. Lab data tells you what is technically wrong; field data tells you whether your visitors feel it.

The order matters. Lab tools are loud about problems that may not affect anyone, and quiet about problems that only show up on a mid-range Android phone on a busy network. Let the field set your priorities; let the lab tell you what to change.

The biggest wins: where to spend your effort #

Most of the gain comes from a handful of changes. Here is where to look, in rough order of payoff.

Image weight

Images are the single biggest contributor to page weight on most marketing sites. A 3 MB hero is common and quietly catastrophic for LCP.

Compress and convert to modern formats: WebP or AVIF, handled by Squoosh, ImageOptim, or your CDN’s built-in pipeline. Size images for the device: a 2000px image served to a 375px screen wastes bandwidth, so use responsive srcset. And if the hero is your LCP element, <link rel="preload"> it in the <head> so the browser fetches it sooner.

Render-blocking resources

By default, CSS and JavaScript in the <head> block the browser from rendering anything until they download and parse. Every render-blocking script adds straight to your LCP, and heavy scripts hurt INP too, by tying up the main thread when the user tries to interact.

Audit the <head> for third-party tags: chat widgets, analytics, tag managers, A/B testing tools. Load non-critical JavaScript with async or defer, inline the small slice of CSS needed above the fold, and load the rest asynchronously.

Third-party scripts get overlooked precisely because they are not your code. But they are your users’ problem. And yours, the moment they cost you a conversion.

TTFB and hosting

Time to First Byte (TTFB) is how long your server takes to begin responding. A high TTFB (north of 800 ms) means the page is slow before the browser receives a single character of HTML. No amount of frontend tuning offsets a sluggish server.

Common causes: underpowered shared hosting, no server-side caching, a database query on every request, or a server geographically far from your audience. The fixes are infrastructure calls: move to a faster host or managed platform, add page-level caching, and put a CDN (Content Delivery Network) in front to serve assets from nodes near your users. For most marketing and lead-gen sites, a CDN alone delivers a meaningful TTFB improvement.

Lazy-loading below the fold

Images and videos below the visible viewport do not need to download immediately. The loading="lazy" attribute tells the browser to defer them until the user scrolls close, cutting initial page weight and improving LCP.

Apply it to anything outside the first screen. Do not apply it to your LCP element: that asset should load as early as possible, never deferred.

Speed within the CRO programme #

Page speed is a prerequisite, not a substitute, for conversion optimisation. A fast page that converts poorly still converts poorly, but a slow page sets a ceiling on every improvement you stack on top of it.

The practical implication: before you test copy or layout on a page, check whether load time is the dominant friction. If your session recordings show a real share of visitors leaving before the page finishes rendering, that is the first thing to fix: the hypothesis is not about your headline, it is about whether speed is destroying the very audience your other tests depend on.

Fold speed into your friction audit alongside form length, value-proposition clarity, and social proof. Once the page is fast enough that it is no longer the bottleneck, the CRO process takes over: measure, hypothesise, test, learn.

The question is not whether speed matters; it does, by every available measure. The real question is where it ranks among your current conversion problems, and whether you have measured it precisely enough to know what fixing it is worth. Measure first, then act with precision instead of instinct. Convert more, guess less.

Frequently asked questions #

Is page speed a Google ranking factor or a conversion factor?

Both, and they reinforce each other. Core Web Vitals are a ranking input, so weak scores can suppress your organic traffic before anyone arrives. They also map onto the experiences that drive abandonment, so the same fixes that help rankings tend to help conversion. You do not have to choose which problem to solve.

How fast does my page actually need to be?

Fast enough to clear the Good thresholds on field data: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. Those are floors, not goals: below them, speed stops actively hurting you. Beyond that, weigh further speed work against other conversion problems rather than chasing a perfect score.

Why does my page score well in PageSpeed Insights but still feel slow?

Because lab scores run on a fixed, often generous device and connection, while your real visitors are on a range of phones and networks. Check the field data (CrUX in PageSpeed Insights, or Search Console’s Core Web Vitals report) to see what people actually experience. When lab and field disagree, the field is the truth.

What single change usually delivers the biggest speed win?

On most marketing sites it is image weight: compressing the hero, converting to WebP or AVIF, and serving the right size per device. After that, deferring render-blocking and third-party scripts. Measure your own pages before committing effort, because the biggest offender varies by site.