Why Site Speed Actually Matters (for Conversions, SEO and Your Sanity)
How site speed affects conversions, SEO and revenue. The honest version, with evidence from real businesses and where to spend first.
On this page
- The short version
- What “good” means: Core Web Vitals from real users
- SEO: what Google actually says (and what it doesn’t)
- Conversions: why milliseconds turn into money (or lost leads)
- What to fix first (almost every time)
- How we approach performance work
- A practical roadmap (without pretending every site is the same)
- FAQ: site speed and revenue
- Does site speed actually affect conversion rate?
- How fast does my site need to be?
- Is site speed a Google ranking factor?
- What usually slows a website down the most?
- Will a faster site recover lost revenue immediately?
- Closing thought
Everyone says performance matters. Fewer people can explain how it shows up in your numbers; or where the hype ends and the honest trade-offs begin. Here’s a straight take, grounded in what Google publishes and what large sites have measured in the wild.
At XIII Studios (opens in new tab), we treat performance as part of the product, not something to clean up later. Most of the time, the work is less glamorous than people think: smaller files, fewer scripts, cleaner priorities, better trade-offs.
The short version#
Website performance changes how people behave. The shape of that change depends on your site: a brochure site lives or dies on first impression; an ecommerce site compounds friction at every step from category page to checkout.
Across several large-brand studies, tiny improvements in mobile speed correlated with meaningful lifts in conversions; think on the order of ~8% higher retail conversions for roughly 0.1 seconds faster loads in one multi-brand analysis. Vodafone ran an A/B test where Web Vitals work was the only change: ~31% better LCP mapped to ~8% more sales, with lifts in lead and cart funnel steps too.
Those numbers are useful as directional evidence, not as a promise you can paste into a forecast. Observational studies mix in traffic, seasonality, and product changes. The strongest story is still controlled experiments (A/B tests, clean rollouts) on your templates and your audience.
If you only remember one thing, remember this: speed work is usually a prioritisation problem, not a rebuild problem. Start with revenue-driving templates, fix the biggest bottlenecks first, and measure the result.
What “good” means: Core Web Vitals from real users#
Google’s Core Web Vitals aren’t lab trivia; they’re measured from real users, and “passing” is about the slow tail, not your laptop on fibre. The exact tooling and UI labels shift over time; the idea, that loading, responsiveness, and stability should hold up for most visits, doesn’t.
At a high level, the usual “good” thresholds at the 75th percentile are:
Metric
What it measures (in plain terms)
Good target (p75)
Metric
What it measures (in plain terms)
Good target (p75)
Metric
What it measures (in plain terms)
Good target (p75)
| Metric | What it measures (in plain terms) | Good target (p75) |
|---|---|---|
| LCP | When the main content in view is visibly ready | ≤ 2.5s |
| INP | How snappy the page feels when people tap and click | ≤ 200ms |
| CLS | How much the layout jumps around | ≤ 0.1 |
LCP is your loading story. INP is your “does this feel broken on a phone?” story. CLS is your “did I just tap the wrong thing?” story.
Accessibility-first, not accessibility-later: these metrics aren’t separate from inclusive design. CLS isn’t a cosmetic issue when shifting layouts make people miss buttons—especially on mobile or with motor difficulty. INP matters when every interaction should respond predictably, including keyboard and assistive-tech users on underpowered devices. LCP is part of whether content is actually available to everyone, not only to visitors on fast networks. We treat performance and accessibility as one brief from day one; not a polish pass after launch.
Two supporting numbers are still useful. TTFB tells you whether the server is slow before the page even starts to render, and TBT is a good lab clue that too much JavaScript is blocking the main thread. Useful for diagnosis, but real-user CWV data is still the main story.
Why p75? Because a few fast visits don’t fix a product. You’re trying to improve experience for typical conditions—mid-range phones, busy networks—not just your QA device.
SEO: what Google actually says (and what it doesn’t)#
Ranking: Google is clear that Core Web Vitals feed into ranking systems—but they’re one signal among many. Treat CWV as competitiveness and user experience, not a magic “#1 on Google” lever.
Crawling: Performance also shows up operationally. If your site responds quickly and reliably, crawl capacity can rise; if it slows down or throws errors, Google may crawl less. For large ecommerce catalogues, that can mean slower discovery of new products, price changes, and stock—bad news when freshness matters.
JavaScript and indexing: Google runs JavaScript, but not exactly like a user’s browser. If critical content depends on heavy or fragile client-side work, you risk late or inconsistent rendering for search. Fixing performance often overlaps with making critical content robust and discoverable.
Conversions: why milliseconds turn into money (or lost leads)#
People don’t wait in a straight line—delay past a few seconds punishes you harder the longer you go. Mobile load-time studies have shown bounce probability climbing sharply as load time stretched from about 1s toward 5–10s. Google’s own training materials tied to CWV have also summarised that when sites meet Core Web Vitals, users were less likely to abandon the page—useful as a cross-team “experience contract,” not as a substitute for your own analytics.
Where speed hurts depends on the site:
Marketing / lead gen
Ecommerce
Marketing / lead gen
Ecommerce
Marketing / lead gen
Ecommerce
| | Marketing / lead gen | Ecommerce |
|---|---|---|
| Win condition | Fast first impression, stable page, smooth form | Fast discovery -> PDP -> cart -> checkout |
| Where it hurts | Paid landing pages: expensive clicks + high bounce | Every template adds friction; every step can leak users |
| What to watch | Hero media, fonts, tag managers, embeds | Template-level dashboards, apps/plugins drift, TTFB at scale |
On marketing and brochure sites, the main risk is a slow first impression or an unresponsive form. On ecommerce, the friction compounds. Category to product to cart to checkout means every extra second has more chances to cost you revenue.
Published programmes at large retailers and marketplaces (Vodafone, Tokopedia, and others documented on web.dev) tie serious performance work to CTR and conversion lifts. Useful as direction, not as a promise your stack will behave the same way.
One honest caveat from large observational work: sometimes aggregate conversion rates moved the wrong way even when speed improved, because real-world data is messy. That is not an argument against speed. It is an argument for measuring properly: segment by device, traffic source, and template, and run clean tests when you can. We tell clients what they need to hear from the data, not only what flatters the roadmap.
What to fix first (almost every time)#
The research keeps pointing at the same culprits:
- Loading (LCP / TTFB / FCP) — oversized hero images and video, late discovery of the LCP asset, render-blocking CSS/JS, slow server/edge.
- Responsiveness (INP / main-thread work) — too much JavaScript, long tasks, heavy third parties on the critical path.
- Stability (CLS) — media and embeds without reserved space, fonts that reflow the page, promos and widgets that pop in late.
Third-party scripts deserve their own line item. Even after your own code is lean, tags and tools can cap how fast the site ever gets. Audit what loads, defer or delay what you can, and load the rest only when needed.
If third-party weight is a big part of your bottleneck, they’ll be an upcoming article about what third-party scripts are actually doing to your site.
How we approach performance work#
We use AI-assisted workflows where they save real time — sitewide pattern matching, evidence gathering across CrUX and Search Console, drafting the routine fixes that engineers would otherwise type from scratch. The work that actually moves conversion — which money pages to defend, which third-party to drop, where the budget binds — is a conversation, not an output. AI just means we have more time for the conversation and less time spent rerunning Lighthouse.
We also keep the advice practical. If a smaller change beats a rebuild, we will say so. If the issue is third-party scripts, image weight, or bad loading priorities, we will say that too.
A practical roadmap (without pretending every site is the same)#
- Baseline in the field - CrUX, Search Console, or your own RUM. Split by device and top templates.
- Map money and traffic - Which URLs earn or convert? Fix those first.
- Quick wins - image optimisation, remove render-blocking cruft, third-party audit, CLS fixes (dimensions, font strategy).
- Deeper work - less JS on the main thread, smarter rendering for critical content, faster TTFB (cache, CDN, backend).
- Prove it - A/B or controlled rollout on key pages when you can; watch p75 move, then confirm KPIs.
Ongoing: alerts on CWV and business metrics, plus a quarterly pass—new features and new scripts have a habit of undoing last quarter’s wins.
FAQ: site speed and revenue#
Does site speed actually affect conversion rate?#
Yes, and the effect is non-linear. Google’s mobile bounce-curve research shows bounce probability rising sharply as load time stretches: ~32% higher at 1→3s, ~90% at 1→5s, ~123% at 1→10s. The clearest commercial evidence comes from controlled work: Vodafone’s A/B test reported a 31% LCP improvement driving +8% sales; Renault’s analysis of 10 million visits associated a 1-second LCP improvement with +13% conversion and -14 percentage points in bounce. The biggest gains usually come from fixing the slow tail on your highest-value templates, not from squeezing milliseconds off pages that already feel fast.
How fast does my site need to be?#
Pass Core Web Vitals at the 75th percentile on the URLs that drive revenue. That is LCP under 2.5 seconds, INP under 200ms, and CLS under 0.1. Hitting those thresholds on mobile, on a real 4G connection, on your top-converting templates is the practical bar.
Is site speed a Google ranking factor?#
Yes, but a modest one — and the bigger commercial story is direct user behaviour. Treat performance as a competitiveness lever for SEO and a conversion lever for revenue. Both stories share the same fix list.
What usually slows a website down the most?#
On most sites we see: too many third-party scripts, unoptimised hero images, render-blocking JavaScript, slow server response time, and layout shift from late-loading content. The first two account for the majority of damage on most marketing sites and ecommerce templates.
Will a faster site recover lost revenue immediately?#
You will see real-user improvements within days. Search Console and CrUX field data update on a 28-day rolling window, so SEO impact reads in weeks. Conversion impact usually shows up immediately on the templates you fixed.
Closing thought#
Performance isn’t a vanity score. It’s how much friction you put between someone and the outcome they want—whether that’s a form submit or a purchase.
The fix is usually boring and high-impact: images, scripts, and the critical path, not performance theatre or a rebranded “transformation programme.”
XIII Studios builds high-performance websites and software without the usual agency overhead.
If you are weighing up whether performance work is worth the investment, book a call with us (opens in new tab). A straightforward conversation about what speed is costing you, where the biggest gains are likely to sit, and whether it is worth doing now.
Or start with a website audit (opens in new tab) and we will give you clear, actionable feedback on performance, accessibility, SEO and conversion.
