Measure twice, optimize once.

Or why premature optimization is the root of all evil.

Donald Knuth once said:
"Programmers waste enormous amounts of time thinking about, or worrying about, the speed of noncritical parts of their programs... premature optimization is the root of all evil."

Computers have become faster and faster in recent years, with the average phone having more computing power than the machines that landed humans on the moon. Yet the argument about optimization rages on.

This may be a controversial take, but most optimizations developers do on web applications are premature and unnecessary. In our experience, solid architecture and best practices beat micro tweaks almost every time.

Are we saying never optimize?

No, but it shouldn't be an all-consuming obsession. Optimization has its place, just not as often as you think.

When should you optimize?
Only when:
✅ You’ve measured where the problem really is, through profiling or benchmarks.
✅ The program is actually too slow. (You’d be surprised how many people skip this part.)
✅ You’ve measured performance.
✅ The potential benefit is big enough to justify the time you’ll spend exploring, implementing, and testing the optimization, as well as the added complexity.
✅ You’ve measured performance!!!

⚡ Speed is subjective.
Most web application users won't notice the difference between 90ms and 100ms. If you’re optimizing just to shave off those few milliseconds, you’re probably wasting your time.
Make sure the juice is worth the squeeze.

🧠 Don’t guess. Measure.
We once had a web application that slowed to a crawl under real data. Everyone assumed that the heavy calculations were the cause, until a quick profile showed that the culprit was DOM manipulation.

Another time, a legacy application we inherited had severe performance issues that frustrated users. After profiling, we discovered it was because a location service updated every few seconds, triggering component rerenders. These constant refreshes caused data loss and slowed down the app. We realized that the location was only needed at submission, not during data entry. By adjusting the architecture to fetch the location only on submission, we eliminated the rerenders and significantly improved performance.

The point?
Measure first! Don't guess! Don't dive straight into code. Before looking at optimization hacks, check if the problem is architectural.

Modern languages and frameworks are already plenty fast and well optimized.
If you get the architecture right and follow best practices, you’re 90% there.

Optimize only when it truly matters, when the gain is an order of magnitude, not a rounding error. When you do, focus on one thing at a time. Start with the biggest bottleneck, measure the impact, and if performance is good enough, stop there. Otherwise, move on to the next.