Web performance: what actually moves the numbers

Performance work has a poor reputation because it is often a list of small optimisations with no measurable effect. In practice, a handful of causes account for most bad scores.

Measure on the right device first

Before changing anything: test on a mid-range Android phone over a throttled connection. Not your laptop.

A page that feels instant on a development machine can take eight seconds on the hardware a large share of your users actually own. Every decision below depends on knowing which numbers are real.

Use field data — real users — rather than lab scores alone. Lab tests tell you what is possible; field data tells you what is happening.

Largest Contentful Paint

LCP measures when the biggest visible element finishes rendering. Poor scores almost always come from one of three things.

The element is an unoptimised image

A hero image at 3000px wide served as a 2MB JPEG. Fix: serve modern formats, size to the actual display dimensions, and set explicit width and height.

The element waits on JavaScript

If the main content renders only after a bundle downloads, parses, executes and fetches data, LCP is bounded by that whole chain. Server rendering removes it entirely — this is the single largest lever available.

Render-blocking resources

Stylesheets and synchronous scripts in the head block rendering. Inline critical CSS, defer the rest, and load fonts with display: swap so text paints before the font arrives.

Cumulative Layout Shift

CLS measures content moving after it appears. It is the most fixable metric and the most annoying to users.

Causes, in order of frequency:

1. Images without dimensions. The browser cannot reserve space, so everything below jumps when the image loads. Always set width and height, or an aspect ratio.
2. Web fonts changing metrics. Text reflows when the custom font replaces the fallback. Use size-adjust or pick a fallback with similar metrics.
3. Content injected above existing content. Banners, notices and ads inserted after load push everything down. Reserve the space or render them server-side.
4. Animating layout properties. Animating height or top triggers layout. Animate transform and opacity, which the compositor handles.

Interaction to Next Paint

INP measures responsiveness to input. It is the metric most affected by how much JavaScript you ship.

The usual causes:

Too much JavaScript on the main thread. Every interaction queues behind whatever else is executing. The fix is shipping less, not optimising more.

Expensive re-renders. In React, a state change high in the tree re-renders everything beneath it. Profile before adding memoisation — guessing usually produces complexity without improvement.

Synchronous work in handlers. Filtering ten thousand rows in a click handler blocks the frame. Move it off the critical path or virtualise the list.

The fixes ranked by return

1. Server-render the content that matters. Largest single improvement for most sites.
2. Optimise images properly. Format, dimensions, lazy loading below the fold.
3. Reserve space for anything that loads late. Removes most CLS.
4. Cut the JavaScript bundle. Audit dependencies; a date library added casually can cost more than the feature.
5. Cache aggressively at the edge. Content that is the same for everyone should not be recomputed.

Keeping it from regressing

Performance is not a one-time project. Without enforcement, a fix lasts until the next feature.

Set budgets and check them in CI — bundle size limits and Lighthouse thresholds on every pull request, so a regression fails the build. Collect field data continuously, because real-world conditions differ from any lab test.

We treat performance targets as a delivery criterion on web development projects rather than as a phase at the end.