App load time is a retention problem

Load time usually lives in the engineering backlog, filed under performance, attended to when there is slack. That is the wrong filing. Load time is a retention and conversion variable, because the seconds it governs are the seconds in which a new user decides whether the product works at all.

The argument does not need statistics. A first session is a trust decision made in seconds, a slow first paint on a phone on mobile data is indistinguishable from a broken app, and every retry is another chance to leave. What follows is those mechanisms in order, plus the difference between feeling fast and being fast, which are related but separate projects.

The first session is a trust decision

A returning user waits because the product has already earned something: their data is in it, their habits route through it, they know the wait ends. A first-time user has none of that. The app has made them exactly one promise, implicitly, by existing in a store listing: open me and something useful happens. The load screen is where that promise is kept or not.

Conditions matter here. On office Wi-Fi, on the developer's flagship phone, everything loads instantly and the problem is invisible. First sessions do not happen there. They happen on mid-range hardware, on mobile data, in a lift, on the walk between two buildings. In those conditions a blank screen carries no information. The user cannot tell slow from broken, because a broken app looks exactly like this. Some of them will retry, and each retry is a fresh decision point with less goodwill than the last. Most will not file a bug report. They close the app, and often that is the whole relationship.

The users who stay and are irritated leave a different kind of evidence. App store reviews anchor on the most repeatable complaint, and "slow" is the most repeatable complaint there is: every user experiences it, every session, and it needs no technical vocabulary to describe. Those reviews then sit at the top of the listing, setting expectations for the next installer before their first open.

Slowness compounds, which is why it is nobody's bug

No single commit makes an app slow. Each feature adds a query, a few fields to a payload, an image, one more request before the first screen is usable. Every addition is individually reasonable, which is exactly why it gets through review. The sum sets a floor under every screen in the product.

That is also why the fix rarely lives in one function. Profiling for a hot spot finds nothing to indict, because the time is spread across the data layer and the rendering path: an endpoint returning the whole object when the screen renders three fields, a list making one request per row, requests running in series that share no dependency, images shipped at upload resolution. The work is architectural subtraction, not a clever optimisation in one place.

Perceived speed and actual speed are separate projects

Perceived speed is what the app does while the user waits. Skeleton screens tell the user the layout exists and content is coming, which is real information a spinner does not carry. Caching the last known state and showing it, labelled as refreshing, beats a blank screen, because the old data is usually still the best available answer. Optimistic rendering belongs here too, with a boundary: it is honest for a like or a draft, and dishonest wherever the render claims something the system cannot yet support, a payment, a booking, anything with a consequence. And perceived speed has a ceiling. It buys a few seconds of patience, not tens.

Actual speed is what the network and the device are asked to do: payload size, over-fetching, the count of round trips on the critical path, image weight. Fixing it is mostly removal. Fetch the fields the screen renders. Collapse the N+1 into one request. Parallelise what has no dependency. Resize images and defer the ones below the fold.

What to measure first

Cold start to first useful content, on a mid-range phone, on cellular. Then the critical path: how many requests run before the first screen is usable, how large their payloads are against what the screen actually renders, whether any query repeats per item, and what the heaviest images weigh.

Measurement fixes nothing by itself. What it does is turn "the app feels slow" into a list with an order, and the top of that list is usually cheaper to fix than anyone expects.

---

If your app feels slow and nobody can say exactly why, that is the kind of question a free audit is for.