Every engineering team knows the site is slow. Very few can say what that costs, which is exactly why performance work loses budget arguments to features. The fix is arithmetic, not advocacy.

Build the number in four steps

1. Segment your real-user data by device and connection. Field data, not lab scores — your median mobile user is not your laptop.
2. Bucket sessions by load time and read conversion rate per bucket. The curve is almost always steep between one and four seconds.
3. Estimate how many sessions move up a bucket if you fix the top three bottlenecks.
4. Multiply by average order value or lead value. That is your budget request, with a source.

Most teams find the same shape: a large group of mobile sessions sitting just past the point where conversion falls off a cliff, and two or three technical causes responsible for nearly all of it.

Which metric to chase first

• Largest Contentful Paint is usually the one tied to revenue. It is what the user experiences as "the page arrived".
• Interaction to Next Paint matters most on interactive apps and long forms — it is where heavy JavaScript shows up as frustration.
• Cumulative Layout Shift rarely changes conversion directly, but it produces mis-clicks and support tickets, and it is cheap to fix.

The fixes that actually move the needle

In order of return per hour: cutting or deferring third-party scripts, serving correctly sized modern-format images, removing render-blocking resources, caching at the edge, and only then application-level optimisation. Teams routinely start at the last item and wonder why the numbers barely move — the marketing tag manager was the bottleneck all along.

You cannot optimise your way out of four hundred kilobytes of analytics tags. Audit what the browser downloads before you refactor what the server does.

Set a performance budget once the gains are in, and enforce it in CI. Without a gate, every improvement is temporary — the next quarter of feature work spends it.