Web Performance: Why Speed Is a Product Feature

Web performance decides how quickly someone can actually use a site. It is not a technical tidying exercise to do after launch — it is part of the experience, and on a slow connection it is most of the experience.

Where do performance problems come from?

The usual sources, roughly in order of how often they are the culprit:

• Large images
• More JavaScript than the page needs
• Slow interface calls to other systems
• Inefficient rendering
• Third-party scripts nobody owns any more
• Caching that is absent or wrong
• Slow server responses
• Inefficient database queries behind those responses

Few of these are exotic. Most are the accumulated result of nobody being responsible for the total.

What is the browser actually doing?

A request goes out, a response comes back, and only then does the real work start: parse the markup, fetch and apply styles, fetch and execute scripts, render, and finally become interactive.

Every additional resource adds work to that sequence, and some of it is blocking — the page cannot continue until it finishes. This is why the order and priority of resources matters as much as their size.

Why do images matter so much?

Images are usually the largest thing on a page by a wide margin, and they are the easiest to get wrong, because an image that looks fine on a desktop monitor may be many times the size the layout actually uses.

The practices that help: serve dimensions matched to the rendered size, use modern formats, provide responsive variants so a phone does not download a desktop asset, compress deliberately, and defer anything below the fold.

What about JavaScript?

Client-side code enables real interaction, and it is also the most expensive thing on the page per byte. An image is decoded; a script has to be downloaded, parsed, compiled and executed, and it competes with the user's attempts to interact.

The discipline is to use client-side code where it earns its cost. A page that only presents information rarely needs a large framework to do it.

What else affects it?

Performance is not only what you ship. Server response time, network conditions, geographic distance from your infrastructure, caching policy and resource prioritisation all shape what a person experiences.

A fast local development environment represents almost nobody. Test on a throttled connection and a mid-range device, because that is closer to the median visitor than the machine the site was built on.

Why measure before optimising?

Because intuition about performance is unreliable, and optimisation without measurement reliably improves the wrong thing.

Establish what is slow first, then why, and only then choose a change. Measure on real conditions rather than ideal ones, and measure again afterwards to confirm the change helped — some do not, and a few make things worse.

What should an engineer consider?

• A budget. A limit on page weight or load time that a change has to respect turns performance from an aspiration into a constraint.
• Regression. Performance decays by accumulation. Without a check in the pipeline it will quietly return to where it was.
• Third parties. Each one is code you did not write, running on your page, changing without notice.
• Caching strategy. What may be cached, for how long, and how it is invalidated.
• Perceived performance. What a person sees while waiting often matters more than the total time.
• The slowest realistic case, not the average.

The practical conclusion

Fast sites are not the product of one optimisation. They are the result of deliberate decisions across design, code, assets, infrastructure and content — and of someone being responsible for the total.

---

Related reading: websites versus web applications, and the website project discovery checklist.