Performance work in mobile development wastes more effort than almost any other kind of engineering. Teams burn sprints shaving milliseconds off benchmarks that no user will ever feel. Meanwhile the problems that actually make people uninstall, the freezes, the janky feeds, the phone that’s dead by 4pm, sit in the backlog because nobody put a number on them.

The gap between what’s easy to measure and what users care about is wide. Closing it starts with picking the right metrics.

An agent keeps a memory table, and two rows matter for today’s task: a supplier’s headquarters city, written eleven months ago, and a freight quote, written three hours ago. A SELECT returns both in the same shape. The headquarters is probably still right. The quote may already be wrong. Nothing in either row says so, and the agent repeats both in the same flat tone.

A row has no idea how old its truth is. It might carry a created_at, and a careful person can compute an age from it, but the decay rate belongs to the kind of fact, not to the table. A three-week-old headquarters address is fine. A three-week-old shipping rate is fiction. Server health goes bad in half a minute. No timestamp column holds that knowledge, and nothing forces a query to read it anyway.

A developer changes a login lookup to WHERE lower(email) = lower($1) so that sign-in stops being case-sensitive. Every test passes. The btree index on email can’t serve a query that wraps the column in a function, so Postgres reads the whole users table, and on a test database with forty rows that’s the cheapest plan anyway. The change ships. A week later someone notices login latency tracking the signup count. The fix is a one-line expression index that would have taken a minute if anything had objected during review.

A dashboard tile shows today’s US traffic, so every page load runs SELECT count(*) FROM events WHERE country = 'US' over a table that grew by a few hundred thousand rows since yesterday. SQLite answers correctly. It also walks every matching index entry to do it, because its b-trees don’t keep counts, and it does the same walk for the next viewer and the one after. Between two page loads the answer moves by a handful of rows, yet each load pays for all of them.

Take a day of production logs from one service, mask the numbers, IDs and quoted strings in every line, and sort the resulting patterns by how often they occur. The top of that list is short and dull: health checks, cache hits, a retry notice from a client library nobody owns. Each of those lines was serialized, shipped, parsed and indexed millions of times to say the same thing, and you paid for every copy. Run it on your own logs. The claim is easy to check, so don’t take it on faith.

A team spends three weeks rewriting a hot loop in Rust bindings, shaves forty milliseconds off a function that runs once per request, and ships it. The page still takes four seconds to load. Nobody profiled first. That’s the pattern behind most performance work that goes nowhere: real effort, wrong target.

Optimization only pays off when you know where the time actually goes, and that’s rarely where intuition points. Developers tend to suspect their own code, because that’s the part they wrote and the part they can picture running slowly. The database, the network, the third-party API call buried in a middleware layer — those stay invisible until you measure them.