Web performance isn't vanity: a fast site makes money

Performance gets treated as a technical nicety, something engineers care about and the business tolerates. That framing is wrong, and it costs money. Web performance is one of the few engineering investments with a direct, measurable line to revenue, and ignoring it means leaving customers (and search ranking) on the table every single day.

The business case is unusually concrete

Most engineering quality is hard to tie to a number. Performance isn't. The relationships are well-established across the industry:

• Slower pages convert worse. Every additional second of load time measurably reduces the share of visitors who complete a purchase or sign-up. The effect is strongest on mobile, which is where most traffic now lives.
• Slow pages lose visitors before they load. A meaningful fraction of users abandon a page that takes too long to become usable. You paid to acquire that visitor; a slow load throws them away at the door.
• Search engines rank fast pages higher. Performance is an explicit ranking signal. A slow site is harder to find in the first place, compounding the loss.

Put together, a slow site pays twice: fewer people find it, and more of the ones who do leave before converting. A fast site is quietly compounding in your favour on both.

What the metrics actually measure

The jargon, Core Web Vitals, Lighthouse scores, obscures what are really common-sense questions about user experience:

• Largest Contentful Paint (LCP): how long until the main content is visible? This is "did the page show up in time."
• Interaction to Next Paint (INP): when a user taps or clicks, how quickly does the page respond? This is "does it feel responsive or sluggish."
• Cumulative Layout Shift (CLS): does the page jump around as it loads, making you tap the wrong thing? This is "is it stable and trustworthy."

A Lighthouse score bundles these and more into one number. It's a useful proxy, but the goal isn't a score, it's the real experience the score stands in for. Optimising the number while the page still feels slow misses the point.

How fast sites get built

Performance is mostly the accumulation of sensible defaults rather than one heroic optimisation:

• Ship less to the browser. The biggest wins usually come from sending less JavaScript. Code-splitting, server rendering, and static generation (which modern frameworks like Next.js make straightforward) mean the browser does less work to show the page.
• Optimise images. Images are often the heaviest thing on a page. Right-sizing, modern formats, and lazy-loading off-screen images cut load dramatically.
• Render on the server or at build time where you can, so users get content immediately instead of waiting for the browser to assemble it.
• Measure real users, not just lab tests. A Lighthouse run on a fast machine can look great while real users on real devices and networks struggle. Field data tells the truth.

None of this requires sacrificing features. The common belief that a rich site must be a slow one is mostly false, slowness usually comes from how things are built, not from how much the site does.

Build it in, don't bolt it on

Like testing, performance is far cheaper designed in than retrofitted. A site built with performance as a default, lean payloads, server rendering, optimised assets, stays fast as it grows. A site built without it accumulates weight until someone's forced into a painful optimisation project under pressure, usually after the slow load has already cost conversions.

The honest way to hold yourself to this is to measure it, on real devices, with real field data, and treat regressions as bugs. Don't take a green Lighthouse score's word that your site is fast. Check what your actual users on actual phones experience. That number is the one tied to your revenue.