Measure before you optimize

Why this rule exists

Intuition about performance is famously unreliable. The bottleneck is rarely where you expect, and optimizing the wrong spot adds complexity while the real problem stays untouched. Measuring first tells you where the time actually goes, so your effort lands where it matters and you can prove the change helped rather than hoping it did.

In practice

Reproduce the slow case, then profile it under realistic load before touching code. Find the dominant cost, fix that one thing, and measure again to confirm the win. Keep the benchmark so you can catch regressions later. Treat any optimization without a before-and-after number as unverified.

Example

// guessing the DB is slow,
// so we add a cache first
const cache = new Map();
// ...still slow. the cost was
// actually in JSON parsing

profile(() => handleRequest());
// -> 80% in parseBody()
// fix that, then measure again

When it doesn't apply

You need not profile to avoid an obviously quadratic loop over a large input or a query inside a tight loop; known pathologies are fair to fix on sight. And design-level performance choices sometimes must be made before there is anything to measure.