The cost of a slow page
Page speed is not a vanity metric. It is a tax on every product decision, every conversion, every retry. A short case for taking it seriously.
A slow page is a tax. You pay it on every user, every session, every retry. The bill arrives quietly — as a slightly lower conversion rate, a slightly higher bounce, a slightly less patient customer — and most teams never trace it back to the source.
What "slow" actually means
The number that matters is not your local lab score. It is the 75th-percentile Largest Contentful Paint on a mid-range Android over a flaky 4G connection. If you are building for the global web — and most of us are — that is your user. They are not on a MacBook Pro on fibre.
Aim for LCP under 2.5 seconds at the 75th percentile. Interaction-to-next-paint under 200 ms. Cumulative layout shift under 0.1. Anything worse and you are leaving money on the table.
Where the time actually goes
In ninety percent of real-world apps, the bottleneck is one of four things: too much JavaScript, render-blocking fonts, oversized images, or a slow server. Fix those four in order and you have already beaten most of the web.
The discipline part
Performance is not a one-time clean-up. It is a budget you defend on every pull request. Once a page is fast, the only way it stays fast is if someone owns the number. Track it like you track errors. Regress and revert.