Your app is fast on your phone. That is the problem.
Development happens on the fastest hardware in the building, on office wifi, with a fresh install and no data. Almost none of your users are in that situation.
Every performance problem we have been called in to fix was invisible to the team that shipped it. Not ignored - invisible. The app was fast on the machines it was built on.
Four ways the development environment lies
- The device is the newest one the company bought. Your median user's phone is two to four years old.
- The network is office wifi. Your user is on mobile data, often congested, sometimes on a train.
- The account is fresh. Your user has three years of data and a list with 4,000 rows.
- The install is warm. You have not seen a cold start since onboarding was written.
Each of those alone is a modest distortion. Together they are the difference between a product that feels instant and one that feels broken.
Set a target device and treat it as the truth
The single most effective change we make on a struggling project is naming one modest device - usually a mid-range Android handset a few years old - and declaring that performance on that device is the performance of the product.
It sits on a desk. It is used for the demo. If a scroll janks on it, that is a bug with a ticket, not an observation about old hardware.
A performance budget nobody can fail is not a budget.
Seed data that resembles a real account
The second change is a seeded account with realistic volume: the number of records a two-year user actually has, with realistic text lengths and a fair share of edge cases. Long names, missing avatars, entries from before a schema change.
Most list performance problems are invisible below about a hundred rows and obvious above a thousand. If the test account has eleven items, you are testing nothing.
Measure the three that matter
Ignore aggregate scores. Three numbers predict how an app feels:
- Cold start to usable content, on the target device.
- Frame timing during the longest scroll in the app, with real data.
- Time to first meaningful content on a throttled connection.
Put them in CI if you can. A number that regresses silently is a number nobody will look at until a user complains.
The commercial argument
Clients rarely fund performance work as a line item, and they should not have to. It is cheaper to hold a standard continuously than to run a performance project later, and the conversation is easier before the reviews arrive than after.
