Performance is a feature: a practical guide to fast web apps

Every second of page load delay costs 7% in conversions. For a site generating $100,000 per day, one extra second of load time translates to roughly $2.5 million in lost revenue per year. Users do not file support tickets saying the page was slow. They close it, usually never to return.

Measure what users feel, not what's convenient to measure

Server response times and uptime percentages tell you whether your infrastructure is functioning. They say nothing about what users actually experience. Core Web Vitals exist precisely because traditional metrics lie. Currently 54.2% of websites still fail to meet the "good" threshold across all three metrics simultaneously. Three numbers that actually matter:

• LCP (Largest Contentful Paint): when the main content appears. Target: under 2.5 seconds.
• INP (Interaction to Next Paint): how quickly the page responds to a tap or click. Target: under 200ms.
• CLS (Cumulative Layout Shift): how much the page layout shifts during loading. Target: under 0.1.

The value of these metrics is that they are rooted in perception. A page that loads in two seconds but shows a spinner for 1.8 of those seconds feels slower than one that progressively renders useful content throughout. Measuring what users see and interact with forces you to optimise for the actual experience.

The render-blocking trap

Most slow pages are not slow because of a slow server. The browser is blocked from rendering. A third-party script loaded in the document head, a stylesheet imported before the first paint, a font that hides text until it arrives: each is invisible in infrastructure reports and immediately visible to every visitor.

The fixes are rarely dramatic. Defer scripts that do not need to run before the page is visible. Load fonts with font-display: swap so text remains readable while the typeface downloads. Inline the critical CSS that controls above-the-fold layout and load the rest asynchronously. These are not advanced techniques. They are the difference between a page that feels fast and one with good server response times that frustrates every visitor.

Set a performance budget, then defend it

A performance budget turns speed from a vague aspiration into a number a release either passes or fails. Cap total JavaScript shipped to the browser. Cap the size of the largest image. Cap the time to first meaningful interaction. Wire those caps into CI so a pull request adding a heavy dependency does not silently slow the product for everyone.

Budgets also change team conversations. When a designer wants to add an animation library and a marketer wants to embed a full analytics suite, the budget gives engineers a concrete and neutral basis for the discussion. It is not a matter of preference but of a commitment the product has already made.

How performance translates to business results

After optimising Core Web Vitals, Vodafone saw an 8% increase in sales and a 15% improvement in cart-to-visit conversion rate. Pinterest achieved 15% more organic traffic and a 15% higher sign-up rate. Sites meeting the "good" threshold across all three CWV metrics see an 8 to 15% improvement in Google search visibility. A one-second improvement in LCP drives 7% more conversions: that is not a technical milestone but a financial result.

Performance as a habit, not a project

Performance degrades in small increments spread across many decisions. An uncompressed image. A script added to every page when only one needed it. A font loaded eagerly that only appears in the footer. No single decision is catastrophic. Their accumulation is. The solution is not a periodic performance sprint. It is making speed visible in everyday workflow: Lighthouse scores in pull request comments, bundle size tracked alongside test coverage, Core Web Vitals monitored with the same rigour as error rates. Treat speed as a feature with an owner and a budget, and it stops being the thing you apologise for after launch.