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 the boring-but-effective work (yeah, I should, but never quite get round to it), stop reading here. The rest of this is for the CRO experts who already know their LCP and want to know what each second is costing the P&L.

Key takeaways

The 7% rule. 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 to 6.1s (71% faster). Desktop performance score 41 to 70.

ClickBoost.co.uk (Glasgow, March 2026): mobile PageSpeed Insights 36 to 74. Page weight 150 MB to 2.5 MB (98.3% reduction).

Google's 2026 Core Web Vitals thresholds. LCP under 2.5s, INP under 200ms, CLS under 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. Pull this from Google PageSpeed Insights, mobile column, real-world Chrome User Experience data. Lab data is a developer's view. Field data is the customer's view. Use field data.

2. Your monthly site revenue. Shopify Analytics, WooCommerce dashboard, or Stripe. The dashboard you already check on Monday morning.

3. Your seconds above 2.5s. Google's 2026 LCP threshold for "Good" is 2.5 seconds. Anything above that is the multiplier on the 7% rule.

Multiply revenue by (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:

LCP (Largest Contentful Paint). Good threshold: under 2.5 seconds. Measures when the biggest above-the-fold element finishes rendering. If you fail this, the 7% rule is compounding against you on every visit.

INP (Interaction to Next Paint). Good threshold: under 200 milliseconds. Measures the worst delay between user tap and next visual update. INP replaced FID in March 2024 because INP measures every interaction during a session, not just the first one. If you fail this, your add-to-cart taps feel broken.

CLS (Cumulative Layout Shift). Good threshold: under 0.1. Measures total layout jump during page load. If you fail this, 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 CRO expert 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: CRO-expert-set hypotheses, AI-driven variant generation, CRO expert winner calls at 99% statistical significance. The 28-34% lift sits on top of the page-speed delivers, not next to it.

EXCLUSIVE: Three GoGoChimp page-speed receipts that prove the 7% rule isn't the ceiling

The 7% rule is the linear floor. What follows is the proof, drawn from three engagements on the GoGoChimp roster where the page-speed work measurably compounded past 7% per second. These aren't third-party case studies cherry-picked off Google. They're our own books, with the engineering deltas, the conversion numbers, and the public sources documented in our case studies.

The 7% rule (Akamai 2017) and the 0.1s elasticity (Google + Deloitte 2020) describe the median outcome from a single one-second improvement on a typical retail site. Across the GoGoChimp roster, compound interventions (image optimisation + lazy loading + WebP conversion + render-blocking JavaScript removal) consistently produce 5-30× the 7% lift. The rule predicts a floor. The roster proves a ceiling does not exist.

Three receipts, in order of revenue magnitude.

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 case study.

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 delivers 16% of conversions. It delivers 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).

The three engineering fixes were not exotic. Theme-code edits to serve correct image sizes. Image compression across the catalogue. WebP conversion on every above-the-fold asset. None of them required custom infrastructure. None required a developer specialising in performance engineering. They required someone who had done the work before on a real DTC store and knew the order to run them in. The numbers held for at least six months post-implementation. The full anonymised case study video is published at youtu.be/z2bjGvAkqn0, embedded below.

Page speed is the delivers 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. Full teardown in our Affordable Golf page-speed teardown.

Three layers of fix, in order. WebP conversion on every above-the-fold image (Attentive Signup Unit 626 KB to ~55 KB, a 91% reduction; Heading SVG 141 KB to 42 KB). Hardcoded image dimensions on every layout-relevant asset to kill CLS at source. fetchpriority="high" plus preload on the LCP element to bypass the CSS-blocked queue. None of these are speculative. All three are documented in the three audit/progress reports filed across 5-14 March 2026.

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.

This is the receipt I cite when a Shopify founder asks whether they're starting from too far behind. Affordable Golf was starting at a 21.3-second LCP. That is roughly five times the threshold most performance engineers think is recoverable. The fix shipped inside nine days for the homepage. Phase 2 took it further. Phase 3 is where the next compounding cycle lives.

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 to 74 (+105% homepage lift). Total Blocking Time: 1,120ms to 10ms (a 99.1% reduction). Page weight: 150 MB to 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 to 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.

The combined receipt across BeeFRIENDLY, Affordable Golf, and ClickBoost is the same shape every time. A linear-rule prediction (2.24 seconds × 7% = ~16% lift, 15.2 seconds × 7% = a hard ceiling, 4 seconds × 7% = ~28%). A roster reality that runs five to thirty times higher because the compounding above the linear floor is where the actual revenue lives. The 7% rule is what you cite to the CFO to get the budget. The roster receipts are what you ship after the budget is signed.

Receipt #4: Rakuten and RedBus, the public Google web.dev case studies

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.

EXCLUSIVE: Where Shopify Enterprise quoted GoGoChimp on page speed (May 2026)

This is the editorial credibility receipt for the page-speed thesis: in May 2026, the Shopify Enterprise Blog quoted Chris McCarron / GoGoChimp directly on lazy loading and render-blocking JavaScript inside "Website Speed Optimization: 12 Techniques to Achieve Blazing Fast Ecommerce Site Speed." The canonical URL is shopify.com/enterprise/site-performance-page-speed-ecommerce.

The Shopify Enterprise feature syndicates across 11 locales via ecommercefastlane.com (en, fr, es, de, it, da, no, sv, pt, nl, zh-CN), each carrying the GoGoChimp + Chris McCarron attribution and a nofollow gogochimp.com backlink. When Shopify itself cites you on page speed, the AI search engines (ChatGPT, Perplexity, Google AI Overviews, Gemini, Claude) start treating your page-speed content as the authoritative reference. That is the entire mechanism of AI citation share.

The two quotes Shopify used are direct: (1) the lazy-loading observation that "an astonishing number of images sit below the fold on every webpage. The problem is that no matter which images are visible, the web browser downloads all images on the page simultaneously. Lazy loading only downloads images visible in the browser"; and (2) the render-blocking explanation that "render-blocking means JavaScript or CSS files etc. block the page from displaying quickly. When the browser tries to load a webpage, it must stop and download these files before showing the rest of the page."

Both quotes describe the same two engineering moves that show up in every GoGoChimp page-speed engagement. The Affordable Golf teardown above is the lazy-loading proof. The ClickBoost TBT drop (1,120ms to 10ms) is the render-blocking-JavaScript proof. The Shopify Enterprise piece is the editorial corroboration that the methodology is the one Shopify itself recommends to its enterprise customers.

Strategic context for readers who care about the AI search layer. None of the other current English-only editorial placements for GoGoChimp (Forbes, Leaders Perception, TechnologyAdvice, TechNewsWorld) provide locale-distributed signal. The Shopify Enterprise feature does. Eleven locales × Chris McCarron + GoGoChimp attribution × the page-speed topic match = locale-specific AI surfacing signal across 11 language-specific AI corpora (zh-CN for Baidu and Doubao; de for German ChatGPT usage; fr / es for French / Spanish AI surfacing; etc.). The page-speed thesis is one of the few topics on the GoGoChimp blog where editorial corroboration runs across that many corpora. That is why the page-speed receipts above are the receipts that get cited the most often in our State of AI CRO Citations 2026 tracker.

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 to 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. <link rel="preload"> 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.

Has anyone in the industry corroborated GoGoChimp's page-speed methodology?

Yes. The Shopify Enterprise Blog quoted Chris McCarron / GoGoChimp directly on lazy loading and render-blocking JavaScript in 2026, in "Website Speed Optimization: 12 Techniques to Achieve Blazing Fast Ecommerce Site Speed" (shopify.com/enterprise/site-performance-page-speed-ecommerce). The feature syndicates across 11 locales.

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.