A client asked us to audit a system they had been building with another vendor for 18 months. It had every feature on the requirements list. Every single one. The users refused to use it. Not because it was ugly or missing functionality. Because it was slow. Pages took four to six seconds to load. Search results came back in eight. Every click felt like the system was deciding whether to cooperate.
The users had gone back to their spreadsheets. Eighteen months of development, every box ticked on the spec, and the users opened Excel instead.
Speed Is a Feature
Performance isn't a nice-to-have that you optimise at the end. It's the feature that determines whether all your other features get used.
53%
of mobile users abandon sites that take longer than 3 seconds to load
Source: Google, Mobile Page Speed Study 2018
That's consumer data, but enterprise is no different. Enterprise users are more tolerant of complexity. They're not more tolerant of waiting. When someone uses a system eight hours a day, every second of latency compounds into frustration. A half-second delay on a page that's accessed 200 times a day costs the user nearly two minutes of pure waiting. Across a team of 50 people, that's over an hour and a half of collective time, every day, spent staring at a loading spinner.
Why Enterprise Gets This Wrong
Performance isn't in the spec. Requirements documents list features, integrations, and compliance needs. They rarely specify performance targets. "The system shall process claims" gets a line item. "The system shall return search results in under 500 milliseconds" almost never does.
It's tested last. Performance testing happens at the end, if it happens at all. By then, the architecture is set, the database schema is locked, and the integration patterns are established. The performance problems are structural, not superficial, and fixing them means rebuilding, not tuning.
Features are visible. Performance isn't. A new feature gets a demo. It gets applause from the steering committee. Performance improvements are invisible. Nobody screenshots a faster page load. This creates a natural bias toward feature development at the expense of performance.
What to Do About It
Set performance budgets at the start. Define targets before you write code. Page load under 2 seconds. API response under 500ms. Search results under 1 second. Make these part of the requirements, not an afterthought.
Test performance continuously. Don't wait until the end. Run performance tests every sprint. Catch regressions early, when they're cheap to fix. A performance regression that's caught the same week it was introduced takes an hour to fix. One that's caught six months later can take weeks.
Measure what users experience. Server response time isn't the whole picture. The user experiences everything: DNS lookup, server processing, network transfer, rendering, JavaScript execution. Measure end-to-end. Use real user monitoring, not just synthetic tests.
Trade features for speed. This is the hard one. When the choice is between adding a feature and making the existing features faster, choose speed. A system that does ten things quickly will be used more than a system that does twenty things slowly.
Nobody has ever told us "the system has too few features but it is too fast." We have heard the opposite more times than I can count.
John Li
Chief Technology Officer
The Uncomfortable Truth
Performance problems are usually architecture problems. And architecture problems are usually early decisions that seemed fine at the time but don't scale. The database query that was fast with 1,000 records and collapses with 100,000. The API that makes six round trips when it could make one. The frontend that downloads 4MB of JavaScript before it renders a single pixel.
These aren't bugs. They're design decisions with deferred consequences. And the only way to prevent them is to treat performance as a first-class concern from day one, not a polish step at the end.
Build less. Build it fast.