All writing

Engineering

6 min read

Latency is a product decision, not a metric

Latency is a product decision, not a metric

Every millisecond you cut is a feature you did not have to build. A short argument for treating speed as scope.

Every millisecond you cut is a feature you did not have to build. A short argument for treating speed as scope.

Written by Sana Okafor

Teams treat latency as an engineering metric to be defended in a quarterly review. We have come to think of it as scope, in the same budget as features, and it changed how we prioritise.

Speed removes work

When a query returns in under a hundred milliseconds, you do not need a loading state, a skeleton screen, an optimistic update, or a cancellation flow. All four of those are real features with real bugs, and fast queries delete them from the roadmap.

That is the argument in full. Every millisecond you cut is a feature you no longer have to build, test, document and support.

Where we spend

We hold two budgets. Interaction work must respond within fifty milliseconds. Anything that blocks a page must resolve within two hundred. Work that breaches either budget does not ship, regardless of who asked for it.

The uncomfortable part

This means we occasionally delay a requested feature to pay down a latency regression nobody complained about. We have never regretted it, though explaining it to a customer mid-quarter is not fun.

Create a free website with Framer, the website builder loved by startups, designers and agencies.