Despite scrolling at approximately 5 frames per second in a crowded inbox, billions of people use Gmail every single day without mass-migrating to a “faster” email client.
This should indicate something uncomfortable about how we spend our time as engineers.
The Inconvenient Truth About Speed
We treat performance like a moral virtue. A slow app is a bad app, built by lazy developers. A fast app is a good app, built by craftspeople.
However, the reality is different. Gmail performs slowly. Slack consumes so much RAM that it seems to be teaching a language model. And whenever you access a board in Jira, you feel like the universe is on the verge of heat death. These products are leading solutions that are being used by hundreds of millions of users.
Fast Alternatives Keep Losing
Here's the recurring sequence I observe:
→ A popular app is visibly slow
→ Someone builds a "blazing fast" alternative
→ Developers celebrate on forums and share benchmark screenshots
→ The alternative tops out at a few thousand users and stalls
Speed-focused alternatives to mainstream apps consistently fail in the market. Not because speed doesn't matter at all. But because it matters way less than we think relative to distribution, integrations, habit, and trust.
Performance isn't the reason the quick email client or the rapid project tracker loses to the alternatives mentioned by the author. It's because their respective companies are already using Google Workspace and have three years of Jira history. Performance might be a tiebreaker, but it's hardly ever the cause for an actual tie.
Lighthouse Scores Are Developer Vanity Metrics
I have witnessed teams that burned entire sprints just to improve their Lighthouse scores, even though their product had almost no users. I have been that team. It's a comfortable process to focus on, the numbers increase, the graphs turn green.
Optimizing rendering performance for an application used by twelve people is not engineering craft. It’s engineering narcissism. You are literally polishing a trophy case in an empty building.
A recurring debate in developer circles is whether successful apps are essentially “tolerated garbage”. That’s the wrong way to think about it. They’re not garbage. They’re good enough at performance, while excelling at the things that actually drive adoption.
Users don't interact with your application through a Lighthouse audit. They interact with it while trying to get something done. If your workflow solves their problem, they're going to put up with a less than optimal scroll. They'll sit through a 200ms-longer load time. They'll complain and use it.
When Performance Actually Matters
I'm not saying performance is irrelevant. There are real thresholds where slowness kills products:
→ E-commerce checkout flows where every 100ms correlates with conversion drops
→ Real-time tools like video editors or trading platforms where latency is the product
→ Mobile web in emerging markets on 3G connections
These are real-world performance-critical situations. However, the majority of us are not developing those types of applications. We are developing CRUD apps, dashboards, and internal tools where the real bottleneck is if anyone would even want to use the application.
Working tirelessly for a week to reduce load time by 40ms on a bundle, before you’ve gotten any validation that people actually want what you’re building is not “disciplined”, it’s procrastination. It’s easier to prematurely optimize a Webpack config than to talk to users.
The Real Cope
A culture of performance doesn’t do much, if anything, for the user. Realistically, it’s mostly for us. It gives us something tangible and measurable to point to and feel like we’re competent or talented. Green scores. Fast builds. Small bundles. These things feel good because they’re simple and easy to understand. They’re also usually easy to control. Which is nice because most of the important, real answers are scary or hard — terrifyingly ambiguous, or just difficult and take time to reveal themselves.
Performance is still important to me but I think I just try to care about it in proportion to where my product actually is. Pre-product-market-fit, I ship fast and ugly. Post-traction, I optimize what users actually complain about. Not what my dev tools highlight in red.
Ship the slow thing. Find out if anyone wants it. Then make it fast. 🔥
How side projects die is in reverse order.
What's the most time you've spent optimizing something that turned out not to matter?
Top comments (0)