Site Speed Is a Revenue Lever, Not a Tech Detail
Performance gets filed under engineering housekeeping. The data says a faster site is one of the most direct levers on conversion and revenue you have. Here is the business case.
Performance gets filed under engineering housekeeping, the thing you tidy up after the "real" work ships. Then you look at what speed does to conversion and revenue, and the filing is backwards. A fast site is one of the most direct, best-measured levers you have on the number that matters. It just happens to be owned by engineering, so it gets treated as a cost instead of the growth investment it actually is.
Every second has a price
Start with the cost of slow. The BBC found it lost an additional 10 percent of users for every extra second its site took to load (via Google web.dev). Not 10 percent of a rounding error. 10 percent of the audience, gone, for each second. Those users do not file a complaint. They just leave, and you never see them in your funnel because they never entered it.
That is the quiet tax on a slow site. You spend on ads, content, and SEO to earn the click, then lose a chunk of those hard-won visitors in the two seconds before your page finishes rendering. The leak sits upstream of everything your marketing actually measures.
Speed shows up on the revenue line, repeatedly
Here is the part that should end the debate, because it is causal, not correlational. These are controlled tests and before-and-after investments, not "fast sites also happen to convert well."
When Vodafone ran a proper A/B test and improved its Largest Contentful Paint by 31 percent, it drove 8 percent more sales, a 15 percent better lead-to-visit rate, and an 11 percent better cart-to-visit rate (Google web.dev case study). Same site, same traffic, same offer. The only variable was speed, and it moved sales by 8 percent.
One speed test moved three revenue metrics
The pattern repeats across very different businesses. After investing in Core Web Vitals, Rakuten 24 grew revenue per visitor by 53.37 percent and its conversion rate by 33.13 percent, and redBus lifted sales by 7 percent (Google web.dev). Different markets, different products, same direction: performance work shows up on the revenue line.
If a consultant offered you an 8 percent sales lift with no change to your product, your price, or your ad spend, you would take the meeting.
A serious performance investment is that meeting.
Why so many sites are quietly slow
If speed pays this well, why are so many sites slow? Because the people who own them almost never feel the problem. You browse your own site on a fast laptop, on office wifi, with everything cached. Your buyer opens it on a mid-range phone, on a patchy connection, cold. The gap between those two experiences is enormous, and the owner lives on the comfortable side of it.
Slowness is also not a single switch you flip. It accumulates: oversized images, blocking scripts, heavy third-party tags, fonts that hold up the render, a framework doing too much in the browser. Each is small. Together they are the two seconds that cost you the 10 percent. Fixing it is a build discipline, not a plugin you install at the end.
Performance is conversion work
The most useful reframe is this: speed is not a technical metric that sits next to conversion, it is part of conversion. A page cannot persuade a visitor who has already left. Every improvement to load time widens the top of the funnel by keeping people who would otherwise have bounced, and it does it before your headline, your proof, or your offer gets a chance to work.
That makes performance one of the highest-leverage fixes you have, because it compounds with everything else. A sharper message on a slow page still leaks visitors. The same message on a fast page keeps them long enough to land. It is the same logic behind why most A/B tests lose: the biggest wins usually come from removing friction, not from clever tweaks, and nothing is more friction than a page that has not loaded yet. That is why we treat speed as step one of the Conversion System, not an afterthought.
What actually moves the numbers
If you want the revenue results above, fix what Google actually weighs, in the order that pays. Here is the sequence, and it starts by measuring the right thing. Working through these on your own site? Our free B2B website audit checklist is the page-by-page version you can run as you go.
Measure on real-user data, not a lab score
Your Lighthouse score on a fast laptop is not what a buyer feels on a mid-range phone. Use field data, the Chrome UX Report behind PageSpeed Insights or your own real-user monitoring, and read the 75th-percentile experience on real devices and connections. That is the number tied to revenue, and it is often far worse than the lab score you have been reassured by.
How to do it
- In PageSpeed Insights, enter your URL and read the "Discover what your real users are experiencing" field panel first, not the Lighthouse lab score below it.
- Switch to the Mobile tab and record the 75th-percentile LCP, INP, and CLS against the good thresholds of 2.5s, 200ms, and 0.1.
- Cross-check the origin in the Chrome UX Report so the numbers reflect a 28-day trend, not a one-off reading.
- For low-traffic pages that return no field data, add Google's web-vitals library to capture your own real-user numbers.
See a worked example
A marketing homepage might score 95 in a Lighthouse lab run on a fast laptop, yet its Chrome UX Report field data shows a 75th-percentile LCP of about 4.2s on mid-range Android phones. Treating the field number as the real one is what surfaces the problem the lab score hid.
Tools to use
PageSpeed Insights, the Chrome UX Report docs, and the web-vitals library.
Steal our AI prompt
I'll paste the Core Web Vitals field data from PageSpeed Insights for my page. Tell me which of LCP, INP, or CLS is failing at the 75th percentile on mobile, how far each is from the "good" threshold (2.5s / 200ms / 0.1), and which one to fix first for the biggest real-user gain. Then list any data you still need. Field data: [paste]
Fix Largest Contentful Paint first, it is usually the biggest lever
LCP is how fast the main content appears, and it is mostly images, fonts, and server response time. Right-size and compress the hero image, serve modern formats, preload it, and get render-blocking fonts out of the critical path. Most of the revenue gain lives in this one step.
How to do it
- Run the URL through PageSpeed Insights and read the "Largest Contentful Paint element" diagnostic to confirm which element is your LCP.
- Drop the hero image into Squoosh, export it as AVIF or WebP at its real display size, and ship responsive
srcsetwidths so no oversized bytes load on mobile. - In the HTML head, preload the LCP image and set
fetchpriority="high"on it so the browser fetches it before lower-priority resources. - Get render-blocking fonts out of the critical path: self-host them, set
font-display: swap, and preload only the weight the hero actually uses.
See a worked example
Right-sizing a 1.8MB full-width JPG hero down to a ~150KB AVIF at its actual display dimensions, then preloading it with fetchpriority="high", can move LCP from roughly 4.2s to under 2s on a mid-range phone. Pulling a render-blocking web font off the critical path with font-display: swap often shaves another few hundred milliseconds.
Tools to use
Squoosh for in-browser image compression, web.dev on optimizing LCP, and web.dev on the Fetch Priority API.
Steal our AI prompt
Here is the Largest Contentful Paint breakdown from PageSpeed Insights for my page (TTFB, load delay, load time, render delay): [paste]. Tell me which phase dominates my LCP, the three highest-impact fixes for that phase, and the exact HTML or CSS changes to make (image format and size, preload, fetchpriority, font-display). My LCP element is: [describe]
Cut the JavaScript that delays interaction
Interaction to Next Paint measures how quickly the page responds when someone taps or clicks, and heavy JavaScript is the usual culprit. Defer and split non-critical scripts, delete what you no longer use, and audit third-party tags, which are frequently the worst and least-noticed offenders.
How to do it
- Run the page through PageSpeed Insights and read the "Reduce JavaScript execution time" and "Reduce the impact of third-party code" diagnostics to see which scripts cost the most.
- Open Chrome DevTools, switch to the Coverage tab, reload, and delete or code-split whatever it flags as unused.
- In the DevTools Performance panel, record an interaction, find main-thread tasks over 50ms, and break them up with
scheduler.yield()orsetTimeout. - Audit third-party tags in the Network panel or your tag manager, then defer, lazy-load, or remove any that first interaction does not need.
See a worked example
On a product page where a 600KB main bundle plus a chat widget and two analytics tags all execute up front, deferring the non-critical scripts and code-splitting the bundle can move INP from around 350ms to under 150ms, making taps and clicks feel instant instead of laggy.
Tools to use
Steal our AI prompt
I'll paste my PageSpeed Insights "Reduce JavaScript execution time" and "Reduce the impact of third-party code" diagnostics. Identify the scripts costing the most main-thread time, tell me which are safe to defer, lazy-load, or remove, and how to code-split the rest. Flag any third-party tag that is not needed before first interaction. Diagnostics: [paste]
Reserve space so the page stops jumping
Cumulative Layout Shift is the page lurching as it loads, and it comes from media and embeds with no space held for them. Set an explicit width and height or aspect ratio on images and video, and reserve a slot for ads and late-loading widgets. It mostly disappears once you do.
How to do it
- Run the URL through PageSpeed Insights and read the CLS value plus the "Avoid large layout shifts" diagnostic to see which elements move.
- In Chrome DevTools, open the Rendering tab and turn on "Layout Shift Regions" to watch exactly which elements jump as the page loads.
- Add explicit
widthandheightattributes to every image and video, or set a CSSaspect-ratio, so the browser reserves the box before the media arrives. - Give ads, embeds, and late-loading widgets a fixed-height container with
min-heightoraspect-ratio, so injected content fills a reserved slot instead of shoving the page down.
See a worked example
Adding explicit width and height plus a CSS aspect-ratio to a hero image and reserving a fixed slot for a late-loading cookie banner can move a page's CLS from about 0.28 (poor) to under 0.05 (good), so buttons and copy stop jumping under the reader's cursor as the page settles.
Tools to use
Steal our AI prompt
Here are the elements flagged in my PageSpeed Insights "Avoid large layout shifts" report: [paste]. For each one, tell me the most likely cause (missing dimensions, injected content, a font swap, a late banner) and the exact CSS or HTML fix (width and height, aspect-ratio, or a min-height reservation) to stop the shift.
Re-measure against conversions, not the tool
After each fix, measure again on the devices your buyers actually use, and grade it against sales, sign-ups, and calls rather than a Lighthouse number. Going from slow to fast is transformative; chasing a perfect score past that point is not. That prioritized work is exactly what website optimization is for, and building it in from the first line is what our web development work bakes into every site.
How to do it
- Add the web-vitals library to your site and send LCP, INP, and CLS as events into Google Analytics 4.
- In GA4, build an exploration comparing real conversions (form submits, calls, sign-ups) for sessions with good versus poor INP and LCP.
- Re-run the fixed page in PageSpeed Insights and read the field panel on the Mobile tab, not just the lab score.
- Watch the page in Search Console's Core Web Vitals report over the following weeks to confirm real users move into the Good bucket.
See a worked example
After lazy-loading a chat widget and other third-party scripts, a B2B pricing page's mobile INP can fall from around 450ms to about 180ms, and in GA4 the demo-request submit rate from those previously-slow sessions might rise from roughly 1.9% to 2.6%, even while the lab Lighthouse score barely moves.
Tools to use
Steal our AI prompt
I want to tie Core Web Vitals to conversions in GA4. Walk me through sending LCP, INP, and CLS from the web-vitals library into GA4 as events, then building an exploration that compares my conversion rate (form submits, calls, sign-ups) for sessions with "good" versus "poor" INP and LCP. My current analytics setup is: [describe]
The honest part
Speed is a means, not a trophy. A perfect Lighthouse score on a page nobody buys from is worth nothing, and past a point the returns flatten: going from slow to fast is transformative, going from fast to slightly faster is not. The goal is never a number in a tool. It is the sales, sign-ups, and calls that number protects.
So treat speed the way you treat a marketing channel rather than an engineering chore, and it becomes what the data already says it is, one of the most reliable growth levers you own.