Which startup tasks should move before first frame, after first frame, or off the critical path entirely?

Keep only tasks that are required to render the correct initial screen before first frame. Run readiness work that improves the next few seconds immediately after first frame. Defer feature-specific setup until the feature is actually used. That split lines up with Android’s distinction between time to initial display and time to full display, and it prevents startup from becoming a dumping ground for every SDK and singleton (App startup time, App startup analysis and optimization).

What should block first frame?

Only work that changes what the user must see immediately. Examples: selecting the initial route, applying persisted theme or locale, parsing a deep link, and restoring the minimum local session state needed to decide between signed-in and signed-out UI.

The key is the ordering boundary, not just an early preflight check. If a deep link can override the default destination, the blocking chain is parse link -> resolve launch destination -> render first screen. If you render first and correct later, you traded startup time for visible misrouting.

What belongs right after first frame?

Put tasks here when the first screen can render correctly without them, but early completion still helps. Good candidates are analytics sender startup, remote-config refresh from network, token refresh that is not required for initial routing, image pipeline warmup, and optional service connections.

Android’s guidance is explicit: confirm whether a costly operation is truly critical, and if it can wait until the app is fully drawn, move it out of startup (App startup analysis and optimization). Also optimize for both first frame and fully usable state, because a fast first paint with a long usability delay is still a bad launch (App startup time).

What should move off the startup path entirely?

Anything whose first user-visible need happens later. Typical examples are support SDKs, recommendation engines, rarely used databases, admin-only modules, and building a full dependency graph for screens the user has not opened.

A useful inventory table has seven columns: task, trigger, thread, what depends on it, first user-visible need, failure if delayed, and safe fallback. If the first user-visible need is not the launch screen or the first interaction, it should not be on the startup path.

How do you classify real startup offenders?

Worked example for a retail app:

• Before first frame: read persisted theme, parse notification deep link, read local auth marker, build only the dependencies needed for the launch destination.
• After first frame: start analytics queue, refresh remote config, warm the image loader for the home feed.
• Off critical path: initialize chat, reviews database, recommendations, and profile-editing dependencies.

Two checks prevent regressions. First, buffer events before deferred senders come online so startup taps are not lost. Second, make deferred initialization idempotent so a background warmup and first user action cannot double-initialize the same component.

How should you validate the redesign?

Measure cold and warm starts separately; Android recommends optimizing with cold start as the baseline because it exercises the longest path (App startup time). Capture traces and inspect main-thread stalls, blocking waits, and expensive work with Perfetto or Android Studio profiling tools (App startup analysis and optimization). For repeatable startup tests, use Macrobenchmark, which Android documents for app startup measurement (Macrobenchmark overview).

Q: Should remote config ever block launch?
Only when the initial screen cannot be rendered correctly from persisted values. The network fetch itself usually belongs after first frame.

Q: Should database migration block startup?
Only if the first screen cannot safely read without it. Otherwise, gate the dependent feature instead of the whole app.

Next step: trace one cold start, list every startup task in an inventory table, and force each one to justify why it blocks first frame.

Reviewed: 2026-09-05