Cold starts, ANRs and jank: the unglamorous metrics that decide if users stay

Users rarely complain about performance in words — they complain by leaving. Here are the three metrics that most often explain why, and what we actually do about each.

Cold start time

A cold start is opening an app that isn't already running in memory — no cached process, no warm state, starting completely from scratch. This is the slowest possible launch path, and it's also the one new users hit on their very first impression of the app, right after installing it. We treat cold start time as a hard budget, not a "nice to have": every screen and dependency loaded before the first frame renders gets questioned, because each one delays that first impression.

ANRs (Application Not Responding)

An ANR happens when the main thread is blocked long enough that Android itself decides the app has frozen — typically around 5 seconds for input events. The causes are almost always the same: doing real work (network calls, heavy parsing, disk I/O) on the main thread instead of a background one. We treat any ANR report in our crash dashboards as a same-priority issue as a crash, not a lesser one — to the person experiencing it, a frozen app and a crashed app feel identical.

Jank (dropped frames)

Smooth motion requires rendering a new frame roughly every 16 milliseconds. "Jank" is what happens when a frame takes longer than that — a stutter during scrolling, a list that doesn't keep up with a fast swipe. It's rarely one big bug; it's usually death by a thousand cuts — too much work happening during layout, images decoded at the wrong size, animations not using the GPU efficiently. We profile scroll-heavy screens specifically because that's where jank is most visible and most damaging to perceived quality.

Why these specifically, and not just "make it fast"

These three map directly to the moments users actually notice: opening the app (cold start), tapping something (ANR risk), and scrolling or animating (jank). Optimizing in the abstract is hard to prioritize; optimizing against these three concrete, measurable moments gives us a clear target and a way to verify whether a fix actually worked, rather than guessing.

The real cost of ignoring them

None of these show up as a single dramatic failure. They show up as a slowly climbing uninstall rate and reviews that just say "laggy" without much detail — the kind of slow-burn problem that's much more expensive to diagnose after the fact than to budget for from the start. Performance work that never produces a flashy feature is still some of the highest-leverage engineering time we spend.