Speed Is a Pricing Decision

Every finance director understands a 5% discount. It appears on the invoice, it shows up in gross margin, someone has to approve it.

Nobody approves the discount your website gives away. It does not appear anywhere. It is the difference between the revenue you have and the revenue you would have had if the page had responded when people tapped it.

That framing is not a metaphor. It is arithmetic, and the case studies are unusually clean because the companies ran real experiments.

• Vodafone A/B tested two versions of a landing page. The version with a 31% better LCP produced 8% more sales, plus a 15% better lead-to-visit rate and an 11% better cart-to-visit rate — published by Vodafone on web.dev.
• redBus improved how its input components handled state, cutting INP by 72%, and recorded a 7% increase in overall sales — their own write-up, also on web.dev.

Now hold those numbers against your own P&L. If a supplier offered you an 8% revenue increase for a fortnight of engineering, you would take it without a meeting. If someone proposed an across-the-board 8% price cut, you would demand a business case.

A slow site is the second thing, disguised as the first. You are already paying it. The only decision in front of you is whether to keep paying.

Put a number on it

You do not need a consultant for this. You need four figures you already have.

1. Monthly sessions
2. Current conversion rate
3. Average order value or average deal value
4. Your current LCP and INP at the 75th percentile, from real-user data

Then the estimate:

Annual latency tax ≈ sessions × 12 × current CVR × AOV × expected conversion uplift

Use a conservative uplift. The published results cluster between 5% and 15% relative improvement for a meaningful performance change; take 6% unless you have your own data.

A worked example. A business with 40,000 sessions a month, a 1.8% conversion rate and a $120 average order does $1,036,800 a year. A 6% relative conversion uplift is $62,208 a year. If the engineering work is three weeks, you are looking at a payback measured in weeks, and every subsequent year is free.

Run it for your own numbers before reading further. The point of this article is that the result usually changes what you do next.

The metric that actually costs you money now

Most performance conversations are still about load time. That is last decade's problem, and for most sites it is broadly solved by decent hosting and a CDN.

The expensive metric in 2026 is INP — Interaction to Next Paint. It measures the delay between a user doing something and the screen changing in response, across the whole session, not just the first moment. Every tap on a filter, every open of a variant selector, every keystroke in a form.

This matters commercially for a specific reason: load happens before the visitor has invested anything, and interaction happens after. A slow load loses browsers. A slow interaction loses buyers — people who had already chosen, already typed, already decided. Those are your most expensive visitors to acquire and the easiest to lose.

It is also the metric most likely to be bad on a site that scores well. A page can load in 1.1 seconds and still take 400 milliseconds to respond to a tap, because the JavaScript that makes it interactive is blocking the main thread. Third-party tags are the usual culprit: chat widgets, heat-map recorders, tag managers loading tag managers, four analytics platforms because nobody ever removes one.

Why most performance work optimises the wrong thing

Here is the uncomfortable part, and it applies to a lot of what is sold as performance optimisation.

A PageSpeed score is a proxy, and proxies get gamed. It is entirely possible to raise a lab score without any real user feeling a difference: defer the things the test measures, lazy-load what is below the fold, move heavy work to after the metric is captured. The score goes green. The tap still lags.

Two rules keep the work honest:

Measure in the field, not in the lab. Lab tools run on a simulated device on a good connection. Your actual 75th-percentile user is on a mid-range Android on a congested network. Only real-user data tells you what is happening to them, and the gap between the two is routinely a factor of three.

Optimise the interaction that precedes money, not the homepage. Nobody buys on your homepage. The path that matters is search → filter → detail → cart → checkout, or list → form → submit. Fixing INP on the step immediately before payment is worth more than fixing LCP on a page most visitors never see.

What actually moves the number

Four categories, in descending order of return for most sites.

1. Remove third-party JavaScript. This is almost always the biggest win and it is a business decision, not a technical one, because every tag has a stakeholder. Audit what each one is for, who reads its output, and whether that person would notice if it vanished. Usually several would not.

2. Ship less of your own JavaScript. Server-render what can be server-rendered. A page that arrives as HTML is fast on a bad phone for free. This is why everything we build is server-rendered by default rather than as an optimisation phase.

3. Fix the heavy assets. Modern image formats, correct dimensions, and fonts that do not block. A concrete one from our own work: on Finkonkurs we inlined Material Symbols icons as SVG rather than loading a 3.8 MB icon webfont. That is one decision, taken once, worth more than a month of micro-tuning.

4. Stop doing work the user did not ask for. Also from Finkonkurs: we turned link prefetching off. A coin page links to dozens of exchanges, each page payload fans out to around 13 backend calls, and viewport-based prefetching was enough to trip the API's own per-IP rate limiter. The "optimisation" was making the site slower and less reliable. Cached page payloads now carry an explicit browser lifetime so repeat navigation stops re-downloading them, and server renders reach the API over an internal hop instead of looping out through the CDN.

That last example is the one worth internalising. Performance work is not a checklist of best practices. Half of it is removing clever things somebody added for performance reasons that turned out to be wrong under real traffic.

The thirty-minute version you can run yourself

You do not need a developer to find out whether this is worth a project.

1. Open your own site on your own phone, on mobile data, somewhere with two bars. Not office WiFi. Not the desktop you tested it on. This single step tells you more than any tool, because it is the condition most of your traffic is actually in.

2. Time the money path, not the homepage. Start a stopwatch, go from a category page to a product, add to cart, reach the payment screen. Anything that made you wait is a candidate, and you now have it ranked by where it hurt.

3. Tap things quickly and watch for lag. Open a filter. Change a variant. Type in a form field. If the screen does not respond within a beat, that is INP, and it is happening to every customer on a mid-range phone.

4. Count the third parties. Ask whoever runs your marketing for the list of scripts on the site: analytics, tag manager, chat widget, heat maps, pixels, review widget, consent banner. Then ask who reads each one's output. The ones with no named reader are free performance.

5. Look at the biggest image on your busiest page. If it is larger than the space it is displayed in, you are paying to send pixels nobody sees. This is still, in 2026, one of the most common findings.

Write down what you found. If the answer is "nothing much", you have saved yourself a project on evidence — which is the whole point of running it before you buy anything.

Where a typical performance budget actually goes

For a normal marketing site or storefront, the work splits roughly like this — and the surprise for most owners is how little of it is code:

The top row is a negotiation. Every tag has someone who asked for it, and removing it is a conversation about whether that person still uses the output. This is why performance projects stall inside companies and why an outside party often moves faster — not because of technical skill, but because they will ask the question nobody internal wants to.

The architecture decisions that make speed free

The cheapest fast site is the one that was never slow.

On Bronjoy the API runs on Laravel Octane with Swoole, with Meilisearch behind search and Redis behind the hot paths — not because those are fashionable, but because a map-first marketplace with 23,727 venues has a search box that has to answer instantly or the product does not work. On Knigopoisk the Open Graph share images are rendered server-side with Satori and resvg, avoiding a headless browser entirely — a whole category of slow, fragile infrastructure that simply does not exist in that system.

Those are architecture decisions, taken before any interface was drawn. They are also why we quote performance as part of the build rather than as a later engagement: every website we deliver ships with a 90+ PageSpeed score and analytics wired in before launch, from $99 with a 3–5 day delivery on a landing page.

If you already have a site and want to know what it is costing you, that is what a performance audit is for — from $90, and you get the finding whether or not you hire us to fix it.

Tell us what you need. You get a fixed price and a delivery date back — free, and with no obligation to proceed.

Frequently asked questions

Does site speed still affect Google rankings?

Yes, but that is the least interesting reason to care. Core Web Vitals are a modest ranking input and a large conversion input. Optimise for the revenue effect and the ranking effect arrives as a side benefit; do it the other way round and you will chase a score instead of money.

What is a good INP target?

Under 200 milliseconds at the 75th percentile is the "good" threshold. The number that matters more is the gap between your median and your 75th percentile — a wide gap means a segment of your users is having a much worse time than your team is, usually on cheaper phones.

Our site is on a page builder. Can it be made fast?

Somewhat, and there is a ceiling. Builders ship a general-purpose runtime plus whatever every installed plugin adds, and you do not control the composition. You can usually reach acceptable; reaching excellent typically means leaving. We cover the wider trade-off in the case against your page builder.

How long does performance work take?

For a typical marketing site, one to three weeks covers the large wins: third-party audit, asset work, render strategy, and fixing the two or three interactions that matter. Deeper work on an application depends entirely on the architecture underneath.

Is it worth it for a low-traffic site?

Run the arithmetic above. At 2,000 sessions a month the annual figure may be small — in which case, correctly, do something else. The calculation exists so you can decline it on evidence rather than on instinct.