What we mean by website speed

A PageSpeed score is a convenient snapshot, not the whole story. Lighthouse runs a fixed lab scenario: device, network, cache. In the field, people arrive on different phones, cellular networks, and third-party script stacks. Next to the score you need metrics that describe how the page feels.

TTFB is time to the first byte from the server. A high TTFB drags everything else: a perfect frontend cannot fix a slow API or cold PHP without cache. FCP marks the first meaningful paint. LCP is when the main viewport element becomes visible — often the hero product image. INP tracks interaction delay across the visit. CLS catches layout jumps that make people miss the Buy button.

JavaScript cost matters separately: parse time, hydration, and main-thread blocking. Heavy client code often kills INP on mobile even when lab LCP looks fine.

Lab versus field

Lighthouse and a clean WebPageTest run answer: “Did we break the critical path under controlled conditions?” Chrome UX Report and your own RUM answer: “What do real users get?” The gap between developer Wi‑Fi and budget Android on 3G can turn a “green” lab LCP into a “red” field one. If you only optimise the engineer’s laptop, you optimise a demo, not sales.

Why the average misleads

Suppose 90% of sessions have LCP under 2.5s and 10% wait more than 6s. The mean can look “almost fine”. That slow decile is often mobile visits from ads, weaker networks, or pages with heavy recommendation widgets. Those 10% can carry a disproportionate share of click cost. Watch percentiles (p75, p90) and segments, not only the site-wide average.

What users do on a slow site

Someone taps Buy or opens a product from search. Instead of the product they see a blank screen, a spinner, or a button that jumps. Waiting is unpleasant; on mobile it also competes with notifications and a competitor’s tab.

Abandonment rises: back to the SERP, close the tab, search again with another brand. Trust falls: a technically sluggish store feels less reliable and less modern — even when assortment and price are fine. Mobile traffic is especially sensitive to heavy JavaScript, oversized images, slow servers, and flaky networks: that is where people decide to wait or leave.

This is not UX mysticism. It is attention physics: every extra wait taxes the chance of reaching the next funnel step. The money link starts here, not in the Lighthouse PDF.

What major company research actually says

Third-party numbers are useful as an order of magnitude, not as your store’s calculator. Here is what is commonly cited, where it comes from, and transfer limits.

Google (Need for Mobile Speed, 2016). Aggregated Google Analytics data on mobile sites suggested about 53% of visits are likely abandoned when load takes longer than three seconds; many mobile pages on 3G then averaged tens of seconds. That is a large publisher/ad sample correlation, not your A/B test. Business takeaway: mobile wait is a mass abandonment driver, not a niche complaint from perfectionists.

Amazon (as recounted by Greg Linden). In controlled experiments before the early 2000s, pages were delayed in 100 ms steps and revenue dropped noticeably; talks often quote roughly ~1% of sales per +100 ms. Amazon did not publish a formal peer-reviewed paper; the figure comes from engineer talks and a blog. Do not treat “1% per 100 ms” as a 2026 law for every landing page — but “small latency is measurable in money at huge traffic” matches Amazon’s experimentation culture.

Walmart (RUM, ~2012–2013 decks). Conversion fell as average load time rose; converting visits were faster on average (about 3.2s vs ~6s for non-converting). Key slides: up to +2% conversion per second of improvement and up to +1% incremental revenue per 100 ms. Observation on their traffic and their “load time” definition — not universal elasticity.

Bing / Microsoft (slowdown experiments). Online-experiment papers report that a 100 ms server slowdown mapped to roughly ~0.6% revenue when reversed (linear approximation on their metrics). They changed response delay, not UI chrome — closer to causality than a raw “fast vs slow users” slice.

Pinterest. Rebuilding pages for performance cut Pinner Wait Time by about 40%, grew SEO traffic ~15%, and signup conversion ~15%; acquisition impact was multiplicative. A later mobile PWA cut time-to-interactive from tens of seconds to single digits and lifted engagement — again “faster critical path → product metrics”, not only a higher score.

Zalando and other retailers. Industry roundups sometimes cite about +0.7% revenue for −100 ms; primary sources are often weaker than Amazon/Walmart — verify before a board deck. AliExpress, Booking, and Netflix stories circulate in agency blogs; open the engineering primary source when stakes are high.

Shared pattern: large sites treat speed as a business metric and prove it with slowdown or speedup experiments. Your job is to repeat the method on your data, not copy someone else’s percentage.

Turning speed into money

Take a simplified store: 1,000,000 monthly visitors, 2% conversion, $50 average order value.

Orders: 1,000,000 × 0.02 = 20,000.
Revenue: 20,000 × 50 = $1,000,000.

Suppose a speed regression cuts conversion by 5% relative to the current rate (not five percentage points): new rate 2% × 0.95 = 1.9%. Orders fall to 19,000. Loss: 1,000 orders or $50,000 potential revenue per month.

That is not a claim that “the site got one second slower ⇒ −5%”. It prices your Δ-conversion hypothesis. That is how to talk to the business: “if speed eats 5% of conversion at our traffic and AOV, a month costs this much.”

Loss formula and why profit matters

Baseline revenue:

Revenue = Traffic × Conversion Rate × Average Order Value

Lost revenue when conversion changes:

Lost Revenue = Traffic × ΔConversion × Average Order Value

where ΔConversion is the absolute change in order rate (e.g. 0.020 → 0.019 → 0.001).

Profit:

Lost Profit = Lost Revenue × Gross Margin

The conversation shifts from “the site lost orders” to “a slow site may cut profit by X per month”. At 30% margin, $50k lost revenue is about $15k profit — the number you compare to a cache/CDN/bundle sprint.

Another lever is the price of a conversion tenth. At 500,000 visitors and $40 AOV, each 0.1 pp of conversion (0.001 as a fraction) is worth 500,000 × 0.001 × 40 = $20,000 revenue. Managers think faster in “this LCP fix on the slow segment might reclaim part of that twenty thousand” than in “LCP was 3.2s”.

SEO, ads, and return visits

Speed is not only instant conversion. Core Web Vitals feed Google’s page-experience signals; other engines also care about usability with opaque formulas. Bounce and short sessions can amplify the effect. Myth to drop: “we sped up the homepage — all rankings rose.” Proven floor: CWV and stable HTML help protect entry quality; the rest is content, links, and intent. For visibility layers see the SEO / AEO / GEO guide.

Ads are harsher. A click from Google Ads, Yandex Direct, or Meta is already paid. A slow landing means: money spent, sale missed. CAC rises not because “ads are bad”, but because the funnel leaks after the click. Fixing LCP on campaign landings often pays faster than another creative.

Return visits and loyalty also remember wait time: “this site always lags” sends people to a competitor next time. Speed is brand, like a clean checkout.

Ecommerce funnel: speed at every step

Typical path: home → category → product → cart → checkout → payment. Users do not “load the site once” — they take dozens of navigations and interactions. If each step loses a few percent of continuation probability, total order impact can exceed the effect on a single page.

Illustrative funnel (demo numbers):

If slow JS on the PDP cuts add-to-cart and a heavy checkout cuts payment, you are fixing breaks, not “the site”. Compare:

Fast path (LCP by step): 2.0 → 1.8 → 1.7 → 1.9 s.
Slow path: 5.5 → 6.2 → 7.1 → 8.0 s.

In the second case people pay with wait on every click. Rule: optimise funnel speed, not only the homepage for a pretty Lighthouse screenshot.

What usually slows modern sites

Backend. Slow SQL, N+1 queries, heavy PHP or Node without cache, cold APIs, missing or misconfigured CDN. TTFB over a second on key URLs is a red flag before any React debate.

Frontend. Huge JS bundles, expensive hydration, unused libraries, no code splitting, too many first-screen requests. Measurement and cuts: eight JavaScript performance fixes.

Images. JPEG where WebP/AVIF belongs; 3000px where 600px would do; no lazy loading or srcset. LCP is often the product image: until that is fixed, frontend micro-opts buy little.

Third parties. Analytics, chat, ad pixels, maps, widgets, experiment platforms, recommenders. Each “small” tag competes for the main thread. Without a third-party inventory you polish your code while someone else’s script owns INP.

How to measure speed’s impact on your site

Step 1. Baseline: traffic, conversion, AOV, revenue, bounce, field Core Web Vitals (not only Lighthouse).

Step 2. Split sessions by speed, e.g. LCP < 2.5s / 2.5–4s / > 4s. Compare conversion and revenue per visitor.

Step 3. Prefer field data: RUM, Analytics, Chrome UX Report, server TTFB logs. Lab is for CI regression debug.

Step 4. Treat correlation carefully. A table “slow LCP → lower conversion” is a useful signal, but correlation ≠ causation: slow sessions may be bots, weak devices, or catalogue pages with different demand.

Show that table to the business as a hypothesis, not a law. Proof is an experiment.

A/B testing speed and the single-metric trap

Strong design: variant A current site, variant B faster (or deliberately slowed to estimate elasticity). Same traffic mix, audience, period, prices, and campaigns; only the technical implementation changes. Measure conversion, add-to-cart, checkout rate, revenue per visitor, AOV, bounce — not only LCP.

Artificial slowdown (Amazon/Bing style) often estimates “what 100 ms is worth” cleaner than a big refactor that also changes UX. A speedup release is closer to day-to-day engineering work.

Single-metric trap: LCP improves 4.2 → 2.1s while conversion and revenue stay flat. Technical win, no business proof — maybe delivery, price, or the payment form is the bottleneck. Reverse case: LCP barely moves, but add-to-cart feels faster via INP and orders rise. Watch the path metric set, not one green circle.

Demo (not field) slide for stakeholder talks:

At 200,000 visits and $35 AOV, +0.25 pp conversion is 200,000 × 0.0025 × 35 = $17,500 revenue. Label which rows are RUM and which are illustration.

Economics of optimisation and a performance budget

Suppose optimisation costs $3,000 and then adds $3,000 incremental profit per month. Payback:

Payback = Investment / Monthly Incremental Profit = 1 month

First-month ROI:

ROI = (Incremental Profit − Investment) / Investment

Over a year the upside usually dwarfs a one-off cost if you do not ship regressions back. A performance budget protects that upside:

A budget is a product–engineering contract: a new chat widget does not land “quietly” if it breaks INP. That is how you stop tech noise from eating conversion.

“PageSpeed 100” is a poor goal by itself: a perfect score does not guarantee sales, good UX, or field match. The right goal is minimise time to the user’s needed action along the purchase path.

Usual priority: server and TTFB → critical rendering path (HTML/CSS/fonts) → LCP images → JavaScript → third parties → CDN and edge cache. UX-to-money talking points also appear in the UX ROI overview.

Checklist for site owners

• Field LCP is measured (not only Lighthouse)
• INP and CLS are measured
• TTFB is measured on key URLs
• RUM or at least CrUX + Analytics exists
• Conversion, AOV, and margin are known
• Conversion is viewed in speed segments
• Contested releases plan an A/B or slowdown test
• A performance budget and regression owner exist
• Paid traffic landings are checked for speed
• Funnel speed (PDP → cart → pay) beats “homepage score”

FAQ

Further reading

• JavaScript: 8 performance fixes — what to measure and cut in client code.
• 10 data-backed UX ROI facts — friction numbers for stakeholder talks.
• SEO, AEO, GEO in 2026 — where CWV sit among visibility layers.
• Why I left Next.js for Astro — JS weight on a marketing site.
• Evolution of web application architecture — why clients got heavy.

Conclusion

A slow site is not “a bad Lighthouse score”. It is fewer products viewed, fewer carts, fewer orders, higher cost per acquired click, and less profit. Judge performance in money: your funnel, your percentiles, your Δ-conversion hypothesis — with the calculator above and an honest test, not someone else’s “+1 second” meme.

Hang this chain above the team board:

Performance → UX → behaviour → conversion → orders → revenue → profit