Our test devices lied to us for months

Most performance advice I read assumes a recent phone on good wifi. Our app runs in Cameroon, where plenty of users are on older Android devices and connections that stall for tens of seconds. Almost nothing I believed about making an app feel fast survived contact with that.

Three things moved the needle, and none of them were the things I expected.

Timeouts were the single biggest win. Our defaults were tuned for a network that answers in about two seconds. On a slow connection the request was still alive and would have succeeded, but the client had already given up and shown an error. The user saw a broken app. The server saw a completed request. Widening the startup and location timeouts fixed more perceived slowness than any amount of code optimisation.

Duplicate calls were second. Our splash screen and home screen were each independently fetching the same config and zone data. On fast wifi you genuinely cannot see it. On a slow connection every duplicate is a real multi second cost stacked in series. Deduplicating them beat every rendering change we tried.

App size was third. We were shipping every CPU architecture in one binary. Dropping to ARM only brought it to about 38 MB. That reads like a vanity metric until you picture someone on metered mobile data deciding whether your app is worth the download.

The pattern across all three: the fix was never in the code that runs. It was in the code that waits, the code that repeats, and the code that ships. A profiler on a fast connection will not show you any of it, because on a fast connection none of it is a problem.

The uncomfortable part is that our test devices were lying to us for months, and every metric we had looked fine.

If you have shipped to users on slow networks or old hardware, what surprised you? I am most interested in what you had to stop doing rather than what you optimised.