Improving React Native startup time

WHAT THIS TESTS This probes whether you can profile and prioritize, not just recite buzzwords. Startup is a system; a senior answer measures first and targets the dominant cost.

A GOOD ANSWER COVERS Area one is the JavaScript engine. Enabling Hermes precompiles JS to bytecode at build time, so the device skips parsing and runs a smaller memory footprint, usually the single biggest startup win. Area two is the JS bundle and module loading. Inline requires defer the evaluation of a module until it is first used, and lazy imports plus tools like RAM bundles ensure the first interactive screen only evaluates the code it needs rather than the whole app graph. Audit bundle size and remove heavy synchronous imports at the top level. Area three is native startup and main thread work: profile native module initialization, image and font preloading, the splash screen handoff, and any blocking synchronous calls during app launch, then defer non-critical work until after first paint.

COMMON WRONG ANSWERS Jumping straight to micro-optimizations without measuring. Assuming Hermes alone fixes everything. Blaming the bridge generically without naming inline requires, lazy loading, or native init deferral.

LIKELY FOLLOW-UPS How do inline requires actually change evaluation timing? How would you measure TTI reliably across cold and warm starts? What regressions can Hermes introduce?

ONE CONCRETE EXAMPLE You enable Hermes and capture a Hermes startup profile, finding a top-level import of a heavy charting library evaluated on launch though it is only used on a settings screen. You convert it to a lazy import behind navigation and turn on inline requires in the Metro config. Cold start TTI drops measurably, and you confirm with repeated cold-start timing markers rather than a single run.