Speed Is a Feature and Most Teams Treat It as a Bug Report
Performance work sits in a strange place. Everyone agrees it matters. Nobody puts it on the roadmap. It lives in a backlog labelled technical debt and gets picked up when something becomes embarrassing.
Meanwhile it is doing more for how your product feels than most of the features you are shipping.
Speed is not a technical property, it is an emotional one
Users do not experience milliseconds. They experience confidence.
A fast interface feels like it is working. A slow one feels uncertain, and uncertainty makes people click again, back out, or quietly conclude the product is flimsy. That conclusion never appears in a survey. It appears in a retention curve nobody can explain.
There is a rough hierarchy that has held up for decades. Under about a tenth of a second feels instant, like you did it yourself. Up to about a second keeps your train of thought. Past a few seconds you have lost the person's attention and you are now borrowing it back.
Most of the difference between products that feel premium and products that feel cheap lives inside that first second.
Perceived speed is a design problem, not just an engineering one
This is the part designers can own immediately, without waiting for anyone's backlog.
Respond instantly even when you cannot finish instantly. The moment the user acts, something must change. Optimistic updates, where you show the result and reconcile later, are the single biggest perceived speed win available and they are a design decision more than a technical one.
Show the shape of what is coming. A skeleton that matches the layout is calmer than a spinner, because a spinner says "unknown" and a skeleton says "nearly".
Do not animate the wait. Transitions that look elegant in a demo become a tax when you hit them forty times a day. Three hundred milliseconds of easing on a screen change is lovely once and irritating on the fortieth use. Keep interface motion short and keep it interruptible.
Load what is on screen. A page that renders in two seconds but takes eight to finish loading things nobody can see is a page that feels slow for six seconds for no reason at all.
Where the time actually goes
When I audit a slow site the cause is almost never the code the team wrote. It is:
- Fonts that block text from appearing
- Images at three times the size they are displayed at
- Third party scripts, analytics, chat widgets, tag managers, each modest and collectively fatal
- A framework doing work that a hundred lines of plain code would have done
The last one is unpopular to say and it is consistently true. A surprising number of sites would be faster, cheaper, and easier to maintain as static pages, and they are not, because the stack was chosen before the problem was understood.
How to get it prioritised
Stop describing it as performance. Describe it as the thing it costs.
Nobody funds "reduce bundle size". People fund "the checkout takes four seconds on the phones our customers actually use and we can see them leaving". Same work, one of them has a person in it.
And test on real hardware. Your development machine on office wifi is the best case that will ever exist. Load your product on a three year old mid range Android on a train. That is the product. Everything you have been looking at is a preview.