Website speed affects revenue because slow, unstable pages lose visitors before they convert. Published A/B tests on web.dev show it: Vodafone saw 8% more sales after a 31% LCP improvement, and Rakuten 24 saw revenue per visitor rise 53%. Speed also feeds Google's ranking systems through Core Web Vitals, though relevance still comes first.
Key takeaways
- Core Web Vitals measure loading (LCP under 2.5s), responsiveness (INP under 200ms) and visual stability (CLS under 0.1) at the 75th percentile.
- Controlled A/B tests from Vodafone and Rakuten 24 tied Core Web Vitals improvements to higher sales and revenue per visitor.
- Google uses Core Web Vitals in ranking systems, but good scores don't guarantee top rankings.
- The usual culprits are heavy images, third-party scripts, bloated themes and slow servers.
- Measure with real-user data, then fix the pages that make money first.
Does website speed really affect sales?
Yes, and the best evidence comes from controlled tests, not surveys. Speed changes behavior at every step: whether a visitor waits for the page, whether they scroll, whether they tap the button, whether the checkout feels trustworthy.
A slow page doesn't just annoy people. It filters out the impatient ones before they see your offer, and on mobile that's a lot of people.
What do real case studies show about speed and revenue?
Google's web.dev site publishes case studies with methodology. A few worth knowing:
- Vodafone: ran an A/B test on paid media landing pages where the only difference was Web Vitals optimization. A 31% improvement in LCP led to 8% more sales, a 15% improvement in lead-to-visit rate and an 11% improvement in cart-to-visit rate.
- Rakuten 24: a month-long, 50/50 A/B test of an optimized page found a 53.37% increase in revenue per visitor and a 33.13% increase in conversion rate.
- redBus: improved Interaction to Next Paint by 72% and reported a 7% overall increase in sales.
- Swappie: cut LCP by 55% and CLS by 91%, and reported a 42% increase in mobile revenue.
- The Economic Times: brought INP from over 1,000ms to 257ms and reported a 50% decrease in bounce rate on topic pages.
For lead-generation businesses, the Google-commissioned Milliseconds Make Millions study by 55 and Deloitte found that a 0.1-second improvement in mobile site speed was associated with a 21.6% improvement in users progressing to the form submission page among the lead-gen sites studied.
These are other companies' results. Your gain depends on how slow you are now and how much traffic you have. But the direction is consistent.
What are Core Web Vitals and what scores should you aim for?
Core Web Vitals are Google's three user-experience metrics. web.dev sets these "good" thresholds:
| Metric | Measures | Good |
|---|---|---|
| Largest Contentful Paint (LCP) | How fast the main content appears | 2.5 seconds or less |
| Interaction to Next Paint (INP) | How quickly the page responds to taps and clicks | 200 milliseconds or less |
| Cumulative Layout Shift (CLS) | How much the layout jumps while loading | 0.1 or less |
web.dev recommends measuring at the 75th percentile of page loads, split by mobile and desktop. In plain terms: three out of four real visits should hit the target, not just your fast office connection.
Server response matters too. web.dev suggests most sites aim for a Time to First Byte of 0.8 seconds or less.
Does website speed affect Google rankings?
Yes, but less than many people claim. Google states that Core Web Vitals are used by its ranking systems. It also says it "always seeks to show the most relevant content, even if the page experience is sub-par," and that good Core Web Vitals scores don't guarantee top rankings.
So treat speed as a tiebreaker in search and a multiplier in conversion. The bigger payoff is usually what happens after the click. That's also why we tie performance work to conversion optimization rather than treating it as a separate technical project. For local businesses, it's part of what makes a website rank locally.
What usually makes a business website slow?
- Oversized images and video. Hero images exported at print resolution, no modern formats, no responsive sizes.
- Third-party scripts. Chat widgets, heatmaps, multiple tracking pixels, review embeds and booking widgets, each loading its own code.
- Page builders and heavy themes. Generic code that ships features you don't use on every page.
- Slow hosting and no caching. A slow server delays everything after it.
- Web fonts loaded poorly, causing invisible text or layout jumps.
- Layout shifts from images without dimensions, late-loading banners and ads.
Look at what changed in the case studies above: Vodafone moved rendering work to the server and optimized images. Swappie worked on images, fonts, third-party scripts and code bundling. These aren't exotic fixes.
How do you measure website speed properly?
- Start with real-user data. Search Console's Core Web Vitals report and PageSpeed Insights field data show how actual visitors experience your pages.
- Use lab tools to diagnose. Lighthouse and Chrome DevTools show what's causing the problem on a specific page.
- Prioritize by money. Fix the templates that carry revenue first: service pages, product pages, landing pages for paid traffic, checkout.
- Tie it to business metrics. Track conversion rate and lead volume before and after. That's how you know it paid off.
If you run Google Ads, landing page speed matters twice: you pay for every click, so a slow page wastes budget that already left your account.
Which speed fixes usually pay off first?
Not every optimization is worth the same. On most business sites, the order of operations looks like this:
- The hero image. It is frequently the LCP element. Serve it at the right size, in a modern format, and don't lazy-load it.
- Third-party scripts. Remove the ones nobody uses. Delay the rest until after the main content loads.
- Reserved space. Give images, embeds and banners fixed dimensions so the layout doesn't jump.
- Main-thread work. Long JavaScript tasks are the usual cause of poor INP. Break them up or remove them.
- Server and caching. Static pages served from a CDN remove most server delay.
Measure after each change. It's easy to spend a week on a fix that moves nothing while the real bottleneck sits untouched.
Is mobile speed more important than desktop?
Measure both, but start with mobile. Phones have slower processors and less reliable connections, so the same page usually performs worse there. A site that feels instant on an office desktop can fail every Core Web Vital on a mid-range phone.
web.dev's guidance is to segment Core Web Vitals by mobile and desktop for exactly this reason. Search Console's Core Web Vitals report does the same. If your customers find you from their phones, the mobile numbers are the ones that decide whether they call.
Why we hand-code fast websites
We build sites by hand rather than with page builders, so pages ship only the code they need. Images are sized and compressed at build time, third-party scripts are justified one by one, and templates are tested against Core Web Vitals before launch.
A fast site doesn't fix a weak offer. But a slow site can sink a strong one. If you want to see where your site stands, our website design team will include a speed review in the free website, SEO and AI-visibility audit. Request it here.
Frequently asked questions
What is a good page load time for a business website?
Google's Core Web Vitals set Largest Contentful Paint at 2.5 seconds or less as good, measured at the 75th percentile of real visits. web.dev also suggests a Time to First Byte of 0.8 seconds or less for most sites.
Is there proof that faster websites make more money?
Yes. Published A/B tests on web.dev include Vodafone, where a 31% LCP improvement led to 8% more sales, and Rakuten 24, which saw a 53.37% increase in revenue per visitor on an optimized page.
Will improving Core Web Vitals boost my Google rankings?
It can help. Google says Core Web Vitals are used by its ranking systems, but relevance comes first and good scores don't guarantee top positions. The clearer gain is usually in conversions.
What replaced First Input Delay in Core Web Vitals?
Interaction to Next Paint (INP). It measures how quickly a page responds to user interactions across the visit, with 200 milliseconds or less considered good.