Performance Is Design

A designer once told me that performance was an engineering concern and that her job was to make things beautiful. I disagreed then and I disagree now. Response time is a design decision. Bundle size is a design decision. Whether an interface feels immediate or sluggish is as much a part of the user's experience as the colour palette or the type scale.

There is research on this that goes back decades. Jakob Nielsen wrote about response time thresholds in 1993. A hundred milliseconds feels instant. One second feels like a brief pause but keeps the user's flow of thought uninterrupted. Ten seconds is the limit for keeping attention on the task. Beyond that, the user switches contexts and may never come back.

These numbers are not suggestions. They are descriptions of how human perception works. If your product takes longer to respond than these thresholds, you have made a design choice that prioritises something else over the user's experience.

The Design of Nothing

One of the most impactful design exercises I know is to spend an afternoon removing things from a page and measuring the performance impact. Remove the hero animation. Remove the third-party chat widget. Remove the analytics script that fires on every page view but nobody reads the reports. Each removal makes the page faster. Each speed improvement makes the page feel better designed.

The Perception of Speed

Perceived performance matters as much as actual performance. A progress bar that moves steadily feels faster than a blank screen for the same duration. A skeleton screen that shows the layout before the content arrives makes the wait feel shorter. A button that responds instantly with a loading state feels more responsive. Good performance is not about hitting a Lighthouse score. It is about respecting the user's time with every decision you make, from the architecture to the animation curve.