Most performance metrics measure the wrong moment. Here's the one that predicts whether users keep the app.
Mobile Engineering · 4 min read
Mobile teams track a lot of performance numbers — cold start time, frame rate, bundle size, memory usage. All of them matter, but they're proxies for one thing that actually predicts whether a user keeps an app: time to first meaningful interaction on a real device, on a real network, not a simulator on office wifi.
The gap between 'fast in development' and 'fast in the field' is almost always the network, not the code. An app that loads instantly against a local API can feel broken on a 3G connection in a moving vehicle if it wasn't designed with that condition in mind from the start.
This is why we test against throttled, unreliable networks early, not as a pre-launch checklist item. It changes real decisions — what gets cached locally, what renders optimistically before the network confirms it, what fails gracefully instead of spinning.
The second-order effect matters just as much: an app that handles bad networks well also handles server hiccups, background app suspension, and low battery mode well, because the same defensive patterns cover all of them. Performance work done properly is really reliability work wearing a stopwatch.
The budget we hold engineering to isn't a number in a dashboard. It's whether a real person, on a real train, with two bars of signal, can still get the thing done they opened the app to do.
