Latency Is a UX Problem, Not a Backend Problem
Every engineering team I've ever worked with treats performance as infrastructure. It isn't. Every millisecond of delay is a design decision with measurable consequences on human cognition.
I'm going to make a claim that makes some engineers uncomfortable: latency is not a backend problem. It is a UX problem. The distinction matters enormously for how teams prioritize and fix it.
When latency is framed as infrastructure, it gets escalated to platform teams, tracked in p99 metrics, and addressed in quarterly sprints. When it's framed as UX, it becomes everyone's responsibility — front end, back end, design, product — because everyone recognizes that a half-second delay between a user's intention and the system's response is a direct degradation of the experience.
The cognitive science here is settled. Research on human-computer interaction consistently shows that delays above 100ms are detectably unnatural. The brain expects immediacy in response to its own actions. When that immediacy breaks, the experience becomes effortful. Attention shifts from the task to the interface. Trust erodes.
The engineering response I advocate for is what I call 'optimistic architecture': design the system so it assumes success and updates the UI immediately, reconciling with the server in the background. This doesn't mean being dishonest about errors — it means not making users stare at loading states for operations that succeed 99% of the time.
Skeleton states, progressive loading, instant feedback on interaction — these aren't nice-to-haves. They're compensating for the latency that your infrastructure hasn't eliminated yet. They're UX solutions to an engineering reality.
The teams that build truly fast-feeling products are the ones where the UX engineers and the platform engineers are telling the same story: that every millisecond matters, because every millisecond is a human moment we've chosen to waste.