By Mehdi HassanAlmost every speed article opens with the same statistic, and almost none of them link to where it came from. That's a problem, because speed decisions cost real design and engineering time, and they should be based on evidence you can check. This hub sorts the reliable data from the recycled myths, explains how speed actually affects conversion, and sets practical targets for landing pages. Each section links to deeper guides on fast builds, animation and measurement.
How much does page speed affect conversion rate?
Page speed affects conversion rate in a real but variable way: slower pages generally convert worse, but the size of the effect depends on the device, the visitor's intent, the page's starting speed and the type of conversion. There is no single universal percentage that applies to every site, and the most quoted ones are misreadings.
The reliable pattern is directional. When pages get slower, more visitors leave before they see the offer, and those who stay engage less. The effect is strongest where patience is lowest: mobile visitors, cold paid traffic and impulse-level conversions. It's weaker where intent is high, such as a buyer returning to book a demo they already decided on. That's why your own data on your own traffic is worth more than any industry figure.
- Conversion drop SOASTA's data linked to a 100ms delay
- ~7%
- Conversion drop SOASTA's data linked to a one-second delay
- ~20%
- Mobile conversion drop found in a SiteSpect controlled delay test
- 4.4%
Where did the '1 second = 7%' statistic come from?
The '1 second delay = 7% fewer conversions' statistic is a misquote of performance research associated with SOASTA. As our research found, the original data actually linked about 7% to a 100-millisecond delay and about 20% to a one-second delay. Over years of being copied between blog posts, the numbers were merged into one tidy, wrong sentence.
This matters for two reasons. First, if you quote it, you're quoting something the source doesn't say, which costs credibility with any reader who checks. Second, it creates false precision: teams expect a fixed return per second saved and are disappointed or confused when their results differ. Treat speed statistics the way you'd treat conversion rate benchmarks: useful context, not a forecast.
Other speed claims worth checking before you repeat them
Our research flagged the speed claim above as part of a wider pattern of recycled conversion statistics, alongside claims like 'multi-step forms convert 300% better' and 'logos lift conversion 43%', which also trace back to misattributed or unsourced figures. A good rule: if a statistic is quoted without a link to the original study, or the link goes to another blog post, assume it's been changed in transit. Look for the original source, the sample, the date and what was actually measured. If you can't find them, don't use the number.
What does controlled testing show about site speed and conversions?
Controlled testing, where a site deliberately adds delay for a random group of visitors, shows that speed affects conversions, usually by less than the popular figures suggest and by different amounts per device. A SiteSpect controlled test, cited in our research, found a 4.4% drop in mobile conversions from added delay.
Controlled tests are the strongest evidence because they isolate speed. Observational comparisons, like 'fast sessions converted twice as well as slow ones', mix in other factors: slow sessions often come from older devices, weak networks and less engaged visitors who would convert less anyway. So when you see a dramatic speed effect, ask whether it was tested or observed. Our companion piece on whether website speed affects conversions goes deeper into how to read the evidence.
Evidence type | What it measures | Strength | Typical weakness |
|---|---|---|---|
Controlled delay test | Conversion change when delay is added at random | Strongest | Few published; results are site-specific |
Observational comparison | Conversion of fast vs slow sessions | Medium | Confounded by device, network and intent |
Before-and-after redesign | Conversion before and after a speed project | Weak to medium | Other changes ship at the same time |
Industry survey | What people say about waiting | Weak | Stated behavior differs from actual behavior |
What page speed should a landing page target?
A landing page should target Google's 'good' Core Web Vitals thresholds, measured on real users at the 75th percentile: Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint within 200 milliseconds, and Cumulative Layout Shift below 0.1. These are documented on Google's web.dev Core Web Vitals page and are the closest thing to an agreed standard.
Metric | What it measures | Google's 'good' threshold | Common landing page culprit |
|---|---|---|---|
Largest Contentful Paint (LCP) | When the main content appears | 2.5 seconds or less | Large hero image or video, late-loading fonts |
Interaction to Next Paint (INP) | How fast the page responds to input | 200 milliseconds or less | Heavy JavaScript, chat widgets, tag managers |
Cumulative Layout Shift (CLS) | How much content jumps around | Less than 0.1 | Images without dimensions, late banners, font swaps |
For landing pages, LCP usually matters most because the hero is the largest element and the first thing a visitor judges. Measure field data from real visitors, not just a lab score on a fast laptop. A page that scores well on a developer's machine can still be slow for a visitor on a mid-range phone over mobile data, which is exactly the visitor most paid campaigns reach.
What makes landing pages slow?
Landing pages are usually slow because of design and marketing decisions, not server problems: an unoptimized hero image or autoplay video, several custom font files, heavy animation libraries, and a pile of third-party scripts for analytics, chat, heatmaps and ads. Each one seemed reasonable when it was added.
- Hero media. A full-width video or uncompressed image is often the largest element and directly sets LCP.
- Fonts. Multiple families and weights, loaded late, delay text and cause layout shifts.
- Animation. Scroll-triggered effects powered by large libraries add JavaScript and can block interaction.
- Third-party scripts. Tag managers, chat, heatmaps, A/B testing tools and pixels compete for the main thread.
- Client-side rendering. Marketing sites built like single-page apps can show a blank screen until JavaScript runs.
The last one is common on startup sites built by product engineers in a hurry. A marketing site that renders entirely in the browser is slower to show content and harder for search and AI crawlers to read. Our guide to moving a React SPA to an SEO-friendly website covers the fix.
How do you make a landing page fast without losing the design?
You make a landing page fast without losing the design by making speed a design constraint from the first sketch: choosing hero media that loads fast, limiting font files, using motion that runs on the GPU, and loading third-party scripts after the main content. When one team owns design and code, these trade-offs get made early instead of discovered late.
Set a budget
Agree on target Core Web Vitals and a rough weight budget for the hero before design starts.
Design the hero for LCP
Use a well-compressed image or a poster frame for video, sized for each screen, and load it with priority.
Limit fonts
One or two families, the weights you actually use, self-hosted and preloaded.
Choose light motion
Animate transform and opacity, keep entrances short, and avoid libraries you don't need.
Defer third parties
Load chat, heatmaps and non-essential tags after the page is interactive, or on interaction.
Test on real devices
Check a mid-range phone on a mobile connection before launch, then watch field data afterward.
Our full guide to fast landing pages goes through each of these decisions with the trade-offs, and our guide to landing page animation covers how to keep motion that explains the product while cutting motion that only delays it.
Is page speed worth fixing before other conversion problems?
Page speed is worth fixing first only when it's clearly poor, such as failing Core Web Vitals on mobile for your main traffic. Once a page is reasonably fast, the message, offer and proof usually matter more. A fast page with a confusing headline still won't convert, and a slow page with a strong offer loses some visitors before they see it.
Pros
- Speed fixes help every visitor, every campaign and search visibility at once.
- Many fixes, like image compression and deferring scripts, are cheap and low-risk.
- Fast pages make A/B tests and ad spend more efficient by losing fewer visitors early.
Cons
- Past 'good' thresholds, further speed gains often have small conversion effects.
- Chasing a perfect lab score can strip out design and content that persuade.
- Speed can't fix an unclear message, a weak offer or the wrong audience.
A practical order: check whether the page passes Core Web Vitals on mobile. If it fails badly, fix speed first. If it passes, look at the message, proof and form. If you're not sure where visitors drop off, start with measurement, using the guides to calculating conversion rate and setting up conversion tracking. For pages like pricing, where visitors are already deep in evaluation, our pricing page conversion rate guide covers the diagnostics that matter more than speed.
How do you measure whether speed improvements changed conversions?
You measure whether speed improvements changed conversions by tracking real-user speed and conversion rate together, split by device and traffic source, before and after the change, and ideally by testing the change against a control. A single before-and-after comparison is weak evidence, because other things change at the same time.
- Record a baseline. Collect at least a few weeks of real-user Core Web Vitals and conversion rate by device and source.
- Change one thing. Ship the speed fix on its own, not alongside a new headline or offer.
- Compare like with like. Same traffic sources, similar season, same device split.
- Test if you can. If traffic allows, run the faster version against the current one.
- Look at engagement too. Bounce rate, scroll depth and form starts often move before final conversions do.
Many startup pages don't have enough traffic for a clean test. Our research notes that detecting a 15% lift from a 2% baseline takes roughly 15,000 to 20,000 visitors per variant. If you're below that, rely on the direction of real-user metrics and engagement, and make speed decisions on principle rather than waiting for statistical proof.
Does page speed matter more in some industries?
Page speed tends to matter more where visitors are impatient or comparing many options: ecommerce, consumer apps, paid lead generation and mobile-heavy audiences. It still matters in B2B, but high-intent visitors such as returning buyers or referrals are often more tolerant of a slower page.
Regulated industries add a twist. Fintech and healthcare sites often carry extra scripts for consent, compliance and fraud checks, plus heavy legal content, all of which can slow pages down. Those sites need speed planned alongside compliance from the start, which is one reason they cost more to build well; our fintech website cost guide covers this. Wherever you are, if one page carries most of your traffic, fixing just that page can be the right scope, as we explain in homepage-only redesigns.
