What this prompt does
This prompt makes the AI a senior mobile performance engineer that gives measured, specific optimisations tied to a profile, not generic speed tips. You supply the [framework], the [current_start] time, the [target_start], and the profiling [tool], and it returns a ranked checklist (fix, expected saving, effort) plus the exact measurement commands.
The five deliverables enforce a measure-first discipline: how to measure cold start reliably with your [tool] and capture a before number to beat; engine and bundle wins like Hermes or JIT settings, bundle splitting, and lazy-loading heavy modules off the startup path; deferred initialisers that move SDKs and services off the critical path safely; perceived-speed tricks such as splash-screen handoff, font preloading, and image hydration without layout jank; and a re-measure step proving the change beat the before number toward your [target_start]. The structure works because the alternative - optimising blind - usually tunes the wrong thing; the before number anchors every later claim.
When to use it
- Your app's cold start feels slow and you need to find what actually runs before first paint.
- Analytics or other SDKs initialise eagerly and you suspect they delay startup.
- You have a concrete target time and need a ranked plan to reach it.
- You want measurement commands and a before number, not vague advice.
- You need perceived-speed wins like splash handoff and font preloading without jank.
Example output
You get a ranked checklist where each row lists a fix, its expected saving, and the effort to do it - covering engine and bundle wins, deferred SDK initialisers, and perceived-speed tricks - plus the exact commands to measure cold start with your [tool], capturing the before number and the re-measure step that proves you beat it toward [target_start].
Pro tips
- Capture the
[current_start]number with your[tool]before changing anything; without a baseline you cannot prove a win. - Move every non-essential SDK off the startup path and re-measure - eagerly initialising analytics SDKs are the usual culprit before first paint.
- Set
[target_start]realistically; perceived speed is mostly what loads before the first frame, so a splash handoff can matter as much as raw time. - Match
[framework]so engine wins like Hermes settings apply to your runtime. - Work the ranked checklist top-down by saving-per-effort, not by what is easiest.
- Re-measure after each change, not in a batch, so you know which fix produced which saving.
- Run cold-start measurements on a release build, not a debug build, because debug tooling and unminified bundles inflate the number and mislead your priorities.
- Average several cold-start runs rather than trusting one; first-launch and warm caches vary enough that a single sample can hide or fake a regression.
