Performance work gets deferred because it has no visible artefact. Nobody demonstrates a page that loads in 800 milliseconds instead of 2.5 seconds; there is nothing to point at. The effect is real anyway, and it shows up in behaviour rather than in feedback.
Users do not report it, they leave
Almost nobody files a complaint about slowness. They abandon the checkout, they stop using the report, they do the task in a spreadsheet instead. The signal arrives as reduced usage, which is usually attributed to something else entirely.
This is why performance is under-prioritised relative to its actual impact: the cost is invisible in every channel a team normally listens to.
Measure where the users are
A developer's machine on office fibre is not the deployment environment. Real users are on mid-range phones and variable networks, and the gap between those two conditions is frequently a factor of ten.
Field measurement from real sessions, segmented by device class, tells you something a local profile never will.
The early decisions dominate
Most serious performance problems are architectural: a query pattern that scales badly, a payload shape that forces over-fetching, a rendering approach that blocks. These are cheap to choose well at the start and expensive to unwind after everything depends on them.
Late-stage optimisation mostly redistributes cost. Early structural choices remove it.
Budgets make it a constraint rather than a hope
Set explicit limits — payload size, time to interactive, query duration — and fail the build when they are exceeded. Without a threshold, performance degrades by small, individually reasonable amounts until it is a project to recover.
A budget converts an ongoing negotiation into a binary check, which is the only form of quality gate that reliably survives a deadline.
Fast software feels well made, and that impression transfers to everything else in the product. It is one of the few qualities users notice without being able to name.