Hermes Bytecode and the Cold-Start Budget: Engineering Time-to-Interactive as a Product Requirement

In the mobile app development lifecycle, the milliseconds between a user tapping an icon and the first meaningful interaction are the most expensive. These milliseconds are often overlooked as a secondary performance metric. When the reporter joined Synapsis Medical Technologies, they were tasked with building a HealthTech AI platform where latency was a barrier to care. The reporter treated Time-to-Interactive (TTI) as a hard product requirement, the primary lever being the Hermes engine's AOT compilation.

Traditional JavaScript engines like JavaScriptCore (JSC) on mobile devices use a JIT compilation model, which involves fetching the JavaScript bundle, parsing it into an AST, and compiling it into bytecode during the user's launch. This process creates a massive spike in CPU usage and memory consumption during the critical user journey. Hermes changes this by shifting the compilation from the device to the build machine, transforming the JavaScript into optimized bytecode.

Hermes bytecode is memory-mapped, allowing only the required bytecode for the initial screen to be loaded into memory. This approach significantly improves the startup time, especially in large-scale applications. The reporter treated TTI as a product requirement, establishing a cold-start budget. To maintain this budget during scaling, the reporter focused on bytecode pre-compilation, string deduplication, and avoiding the require waterfall.

The reporter provided a worked example of optimizing a clinical AI dashboard. The non-optimized index.js file imported heavy SDKs and libraries, leading to substantial bundle sizes. By restructuring the imports and leveraging Hermes bytecode, the reporter was able to significantly reduce the bundle size and improve the startup time.