The 7% Rule: How Page Speed Destroys Your Conversion Rate

Every extra second of page load time costs you 7% of conversions. On £40,000/month in ad spend converting at 2%, two seconds of bloat costs you roughly £5,600 every month. The maths is simple. The fix is cheaper than the loss. Almost nobody runs it.

If your reaction to page-speed conversations is the same as your reaction to flossing (yeah, I should, but never quite get round to it), close this tab. The rest of this is for the operators who already know their LCP and want to know what each second is costing the P&L.

Key takeaways

• Every extra second of page load time costs roughly 7% of conversions (Akamai, 2017). On a £40K/month ad spend converting at 2%, that's around £5,600 in monthly lost revenue per second.
• BeeFRIENDLY Skincare (Ezra Firestone brand): a 2.24-second page-speed reduction took annual revenue from $48,000 to $1,447,225 (~30× multiplier). Three engineering fixes, $3,000 fee.
• Affordable Golf (UK Shopify, March 2026): homepage LCP 21.3s → 6.1s (71% faster). Desktop performance score 41 → 70.
• ClickBoost.co.uk (Glasgow, March 2026): mobile PageSpeed Insights 36 → 74. Page weight 150 MB → 2.5 MB (98.3% reduction).
• Google's 2026 Core Web Vitals thresholds: LCP < 2.5s, INP < 200ms, CLS < 0.1. If you're failing any of the three, the 7% rule is compounding against you on every visit.

What the 7% rule actually says

Akamai's 2017 retail performance research found that retailers lose roughly 7% of conversions for every additional second of page load time (Akamai, 2017). That number has been repeated for nine years because nothing replaced it, and because every site I've audited since has held the pattern.

7% per second is the canonical figure. It is not a ceiling. On the worst pages (12+ seconds of load time, dozens of render-blocking scripts), the real loss compounds well past 7% because visitors abandon before the page even paints. The 7% is the linear floor. The compounding above it is where the revenue actually goes.

The 7% rule is corroborated by a more granular piece of primary research: Google and Deloitte's Milliseconds Make Millions study, which analysed 30 million user sessions across 37 European and American brand sites over four weeks of mobile data. The headline number: every 0.1 seconds of mobile load-speed improvement increased conversion rates by 8.4% in ecommerce, 10.1% in travel, and 3.6% in luxury. The Akamai 7%-per-second linear floor and the Google + Deloitte 0.1s elasticity describe the same phenomenon at different scales: page-speed loss is roughly linear, ecommerce sits near the top of the elasticity range, and the maths runs in the wrong direction every single day until the engineering work happens.

The rule is industry-standard, not a GoGoChimp claim. I cite it constantly because it's the only page-speed number a CFO will sit still for. Tell a finance director "your Largest Contentful Paint is suboptimal" and you'll get a polite nod. Tell them "every second of load time is costing you 7% of conversions, here's what that is in pounds per month" and you'll get a budget.

How to calculate what page speed is costing you right now

The maths is direct. Take your monthly traffic, your current conversion rate, your average order value, and your current page load time. The formula:

Lost revenue per month = (monthly visitors) × (current conversion rate) × (AOV) × (7% × extra seconds above the 2.5s LCP threshold)

Let me run it on a worked example.

A Shopify store doing £40,000/month in Meta ads, pulling 50,000 monthly sessions, converting at 2%, with £150 AOV and a homepage LCP of 4.5 seconds. Two seconds of bloat above the 2.5s threshold. 7% × 2 = 14% conversion erosion. Monthly revenue at 2% is £150,000. At a healed 2.28% (recovering 14% of the lost conversions), it's £171,000. Page speed is costing this store roughly £21,000 per month, or £252,000 per year. The audit costs less than a fortnight of that loss.

The maths is conservative. It assumes a linear 7% per second, which is what Akamai measured on retail sites. On pages where the LCP element competes with render-blocking scripts (Microsoft Clarity, BSS Product Labels, Hextom Timer Bar, Zendesk widgets), the actual conversion loss runs higher because the page doesn't just load slowly. It freezes the mobile CPU during render.

Plug your own numbers in

Three numbers you need before any agency conversation:

1. Your current LCP (Google PageSpeed Insights, mobile column, real-world Chrome User Experience data).
2. Your monthly site revenue (Shopify Analytics, WooCommerce dashboard, Stripe).
3. Your seconds above 2.5s (Google's 2026 LCP threshold for "Good").

Multiply revenue × (7% × extra seconds). That's your annualised page-speed tax. If the number runs into five figures per month and you haven't booked an audit, that's the most expensive procrastination on your P&L.

Core Web Vitals in 2026: the three thresholds that matter

Google's 2026 Core Web Vitals are the ranking signals and the conversion signals. They're the same thing measured from two angles.

Core Web Vitals are not abstract. LCP at 2.5 seconds is the line between "this page loaded" and "this visitor left." INP at 200ms is the line between "this button is responsive" and "this site feels broken." CLS at 0.1 is the line between "I can tap that" and "the page just jumped and I tapped the wrong thing."

The three thresholds you need to hold:

If you fail LCP, the 7% rule is compounding against you on every visit. If you fail INP, your add-to-cart taps feel broken. If you fail CLS, the user is tapping the wrong button because the page moved underneath their thumb. Each metric is a separate revenue leak. All three are fixable in weeks, not quarters.

What expert-guided AI does on top of the 7% baseline

The 7% rule is what you recover by fixing the speed. The next layer is what you make on top.

Build Grow Scale's 2026 industry review across 347 e-commerce stores found that expert-guided AI testing delivered conversion lifts of 28-34%, compared to 4-7% from DIY AI tools (industry research by Matthew Stafford, founder of Build Grow Scale, 9 April 2026). Same software, 5× the result. The AI is not the differentiator. The operator is.

Once page speed is healed, the testing programme runs on a clean sample. A/B tests on a 6-second page are running on a corrupt funnel. The visitors who bounced before the page rendered never saw your variant. They're not in your statistical population. You're testing on the survivors. Fix the speed, and your testing programme finally measures what it thinks it's measuring.

OperatorAI (GoGoChimp's CRO methodology, distinct from OpenAI's Operator agent product) is the delivery system: operator-set hypotheses, AI-driven variant generation, operator winner calls at 99% statistical significance. The 28-34% lift sits on top of the page-speed unlock, not next to it.

Receipt #1: BeeFRIENDLY Skincare, 2.24 seconds, 30× revenue

The clearest demonstration of the 7% rule (compounding past 7%) sits in the BeeFRIENDLY Skincare case. Ezra Firestone's brand. Real DTC Shopify store. The landing page was loading at 12.48 seconds.

A 2.24-second page-speed reduction took BeeFRIENDLY's annual revenue from $48,000 to $1,447,225, a ~30× multiplier. Bounce rate fell from 82.04% to 38.4%. Per-visitor value rose from $1.28 to $29.03. Three engineering fixes, $3,000 fee. The full annotated case is in the BeeFRIENDLY page-speed teardown.

Why 30× and not 16% (2.24 × 7%)? Because the 7% rule is the linear floor. On a 12-second page, almost everyone bounces. Cutting 2.24 seconds doesn't just unlock 16% of conversions. It unlocks the population of visitors who now stay long enough to see the page, view a second product, watch the video, and convert at the page-depth-driven rates the audit had already mapped (5.15% at 8 pages, 53.25% at 9, 71.23% at 13).

Page speed is the unlock that makes every other lift possible.

Receipt #2: Affordable Golf, 15 seconds off LCP in nine days

Affordable Golf is a UK golf retailer on Shopify with a physical store in Newton Mearns. Real catalogue, real organic traffic, real paid spend. In early March 2026, the homepage was loading the largest above-the-fold element at 21.3 seconds.

Affordable Golf's homepage LCP went from 21.3 seconds to 6.1 seconds across Phases 1 and 2 of the engagement (15.2 seconds faster, 71% improvement). Desktop performance score lifted from 41 to 70. Mobile LCP halved from 4.7s to 1.6s. CLS dropped from 0.123 (failing) to 0.007 (passing). All inside nine days.

Three layers of fix, in order: WebP conversion on every above-the-fold image (Attentive Signup Unit 626 KB → ~55 KB, a 91% reduction); hardcoded image dimensions to kill CLS; and `fetchpriority="high"` plus `preload` on the LCP element to bypass the CSS-blocked queue. The full annotated teardown sits in the Affordable Golf page-speed teardown.

The honest number is the mobile performance score, which only moved from 26 to 28. Mobile is capped by third-party JavaScript (47+ apps installed, including a doubled-up Microsoft Clarity, a Zendesk widget loading twice, and a TA Labels & Badges app eating 6.7 seconds of mobile main-thread time). Phase 3 of the engagement targets those scripts. The 7% rule says every one of those seconds is still costing revenue.

Receipt #3: ClickBoost.co.uk, 150 MB to 2.5 MB

ClickBoost is a Glasgow B2B site I rebuilt the page-speed infrastructure on in March 2026. The numbers are absurd.

ClickBoost mobile PageSpeed Insights: 36 → 74 (+105% homepage lift). Total Blocking Time: 1,120ms → 10ms (a 99.1% reduction). Page weight: 150 MB → 2.5 MB (98.3% reduction). Video assets compressed from 121.5 MB to 17.2 MB. Core Web Vitals: PASS across the board. SEO score 100/100, Best Practices 100/100. Source: ClickBoost Page Speed Optimisation Report, 14 March 2026.

The 150 MB page weight is not a typo. The site was loading an uncompressed product video on the homepage. Compressing the video alone (121.5 MB → 17.2 MB) cut more weight than most ecommerce sites carry across their entire homepage. The TBT drop from 1,120ms to 10ms is the kind of number that makes Google's Lighthouse score swing wildly within a single audit window.

Applied to the 7% rule: a B2B site converting at 3% with £80,000/month in pipeline value, carrying 5 seconds of bloat above the 2.5s LCP threshold, was bleeding roughly £28,000 in pipeline per month. The page-speed engagement paid for itself before the second week.

Receipt #4: Rakuten, Core Web Vitals optimisation, +33% conversions, +53% revenue per visitor

Rakuten ran a Core Web Vitals engineering programme across the storefront and reported a 33% increase in conversions and a 53% increase in revenue per visitor in the measurement window after the work shipped. The case study sits on Google's web.dev under Core Web Vitals business-impact research (Google web.dev case study). The numbers are larger than the typical 7%-per-second prediction because Rakuten was failing all three Web Vitals before the engagement and recovered all three together. When LCP, INP, and CLS are all in the red, fixing one compounds against the other two and the revenue uplift runs well above the linear rule.

The same dynamic showed up at RedBus, where targeted Interaction to Next Paint (INP) optimisation alone delivered a 7% lift in sales (Google web.dev). INP replaced First Input Delay as a Core Web Vital in March 2024; it measures the responsiveness of every interaction during a page session, not just the first one. Add-to-cart taps, filter changes, size selectors, search autocomplete: each of those interactions has its own INP score, and on a slow mobile CPU each one is a separate friction point.

These two are public Google-hosted case studies. Either is acceptable as a CFO-grade source when arguing for a page-speed engineering budget.

The five page-speed fixes with the highest conversion ROI

Prioritised by revenue impact, not by developer effort. Run these in order.

1. Convert every above-the-fold image to WebP

WebP lossy images are roughly 26% smaller than equivalent JPEG, and 80-90% smaller than uncompressed PNG/SVG at master resolution. On Affordable Golf, single assets dropped 91% (626 KB → 55 KB). Modern browsers (Chrome, Edge, Firefox, Safari 14+) support WebP natively. Shopify's image pipeline serves JPEG fallback for the long-tail. There is no defensible reason for a 2026 store to serve a 600 KB PNG hero.

2. Hardcode dimensions on every layout-relevant image

CLS is the cheapest Core Web Vitals win. The fix: every image gets explicit `width` and `height` attributes (or an `aspect-ratio` CSS rule). The browser reserves the slot before the asset loads, the layout doesn't jump, CLS drops below 0.1. Affordable Golf went from 0.123 (failing) to 0.007 (passing) on this fix alone.

3. `fetchpriority="high"` and `preload` on the LCP element

The LCP element competes against every other asset in the browser's download queue. `fetchpriority="high"` tells the browser to prioritise it. `` tells the browser to start downloading before the CSS has finished parsing. On Affordable Golf's product page, this fix alone cut LCP by several seconds before any image-format work landed.

4. Defer third-party JavaScript until after `DOMContentLoaded`

Third-party scripts (analytics, heatmaps, chat widgets, label engines) load on the main thread by default and block the browser from doing anything else. Wrapping them in a `defer` attribute or a `DOMContentLoaded` listener moves them out of the critical render path. Affordable Golf's TBT fell from 8,520ms to 3,350ms (~60%) by deferring the BSS Product Label engine alone.

5. Audit your installed apps and kill the duplicates

The Affordable Golf audit found 47+ apps installed. Microsoft Clarity was installed twice (legacy app + GTM container). Zendesk widget was double-loaded. Shopify's own app performance documentation recommends 3-5 essential apps for high-performing stores. If you have more than 10, you have an app problem masquerading as a page-speed problem.

Where most stores get the 7% rule wrong

Three failures I see weekly.

Failure 1: measuring PageSpeed Insights instead of revenue per visitor. The score sits on a developer's screen. The per-visitor-value number sits on the CFO's screen. Connect those two numbers and the engineering budget pays for itself. Don't connect them and you'll spend a quarter arguing about LCP scores while the funnel keeps leaking.

Failure 2: running A/B tests on a 6-second page. Your tests are running on a corrupt sample. The visitors who bounced before the page rendered are not in your statistical population. Fix page speed first, then test copy, layout, and offer. Running tests on a slow site is the most common waste of CRO budget I see.

Failure 3: optimising desktop and ignoring mobile. Desktop CPUs absorb JavaScript bloat. Mobile CPUs do not. This is why Affordable Golf's desktop jumped 29 points while mobile barely moved 2. If your mobile traffic is over 50% of your sessions (it almost certainly is), mobile performance is the entire conversation. Desktop is the rounding error.

The GoGoChimp free page-speed audit

What we measure in the free audit:

Real Chrome User Experience data on your LCP, INP, and CLS across desktop and mobile. A bytes-level breakdown of your image weight, render-blocking JavaScript, and third-party app load. A per-visitor-value calculation that translates your seconds-of-load-time into pounds of monthly revenue. A prioritised three-fix shortlist with projected lift on your existing traffic. 48-hour turnaround.

The audit is free. The implementation is not. Pricing sits in the published Sprint / Growth / Scale tiers on gogochimp.com. The Sprint tier (£2,500 one-off) covers a two-week engagement with AI audit, speed fixes, and a revenue impact report. On a site with a 4-second LCP, that pays for itself in under a month.

FAQ

How much does a 1-second improvement in page load time actually increase conversions?

Akamai's 2017 retail research established roughly 7% per second as the industry baseline (Akamai, 2017). On pages with severe bloat, the real lift compounds well past 7%. BeeFRIENDLY's 2.24-second cut produced a ~30× revenue multiplier.

What is a good Largest Contentful Paint (LCP) for ecommerce?

Google's 2026 threshold for "Good" LCP is under 2.5 seconds. On ecommerce specifically, every second above 2.5 costs roughly 7% of conversions.

How do I calculate what page speed is costing my business?

Multiply your monthly revenue by 7% by the number of seconds your LCP sits above 2.5s. Example: £150,000/month revenue × 7% × 2 seconds = £21,000/month in lost revenue.

Is the 7% rule still valid in 2026?

Yes. Akamai's 2017 research has been replicated across multiple industry studies, and the 7%-per-second figure has held across nine years of subsequent measurement.

Should I fix page speed before running A/B tests?

Yes. If your homepage takes more than 4 seconds to render, your A/B tests are running on a corrupt sample. Fix LCP and CLS first.

How long does it take to fix page speed on a Shopify store?

Phase 1 ships in 1-2 weeks. Phase 2 ships in days. Phase 3 typically takes 2-4 weeks. Affordable Golf's Phases 1 and 2 shipped over nine days.

Why does mobile page speed matter more than desktop?

Mobile is over 60% of ecommerce traffic in 2026, and mobile CPUs cannot absorb JavaScript bloat the way desktop CPUs can.

What does GoGoChimp's free page-speed audit include?

A real Chrome UX Report pull on LCP, INP, CLS across desktop and mobile. A bytes-level breakdown of image weight, render-blocking JavaScript, and third-party app load. A per-visitor-value calculation. A prioritised three-fix shortlist. 48-hour turnaround.

If your site loads in more than 4 seconds and you spend over £10K/month on ads, run the audit

If you're running paid traffic against a site with an LCP over 4 seconds, the 7% rule is compounding against your P&L every day you don't measure it. Our free AI page-speed audit will show you what each second is costing you in 48 hours.

The audit is free. The cost of not running it is in the maths above.