What actually moves the needle on page speed

Performance work attracts a particular kind of procrastination. It is satisfying to shave four kilobytes off a bundle, and it feels like progress. But if the page is still waiting two seconds on an unoptimised hero image, those four kilobytes changed nothing a user could perceive.

Measure on the hardware people actually have

The single most common mistake is profiling on a developer machine over office wifi. Your users are on mid-range phones on patchy mobile networks. Throttle the CPU, throttle the network, and look at the numbers again. They will be worse, and they will be true.

The short list

In practice, most sites get the overwhelming majority of their gains from a handful of things:

• Images. Correct dimensions, modern formats, lazy loading below the fold. This is usually the biggest single win and it is almost always available.
• Fonts. Subset them, preload the critical ones, and set a sane fallback so text renders immediately.
• Render-blocking resources. Anything in the critical path that is not needed for first paint should not be there.
• Third-party scripts. Frequently the worst offenders, and frequently the ones nobody has audited in two years.

Layout stability matters more than the score

A page that loads in one second but shifts three times while loading feels worse than a page that takes a little longer and stays still. Reserve space for images and embeds. Users read stability as speed even when the metrics disagree.

Then stop

There is a point of diminishing returns, and it arrives earlier than most engineers want to admit. Once the critical path is clean and the images are sensible, further optimisation is usually better spent elsewhere. Ship the feature instead.