Optimizing Hippy Startup Performance by Switching JavaScript Engines in QQ Browser

Hippy renders UI asynchronously using a JavaScript engine, which introduces noticeable latency from the moment a user taps a link until the first screen becomes interactive (TTI). QQ Browser (QB) relies on Hippy for more than 100 business pages, and the startup delay negatively impacts user experience.

Performance analysis shows that the total TTI is about 1488 ms, with 87 % (≈1303 ms) spent on module initialization and execution of the business JavaScript bundle. The remaining time is consumed by bootstrap code and native bridge setup.

On iOS, Hippy uses the system‑provided JavaScriptCore (JSC) engine, which does not support direct bytecode loading, making it impossible to cache the compiled code. To reduce the load time, alternative engines that support bytecode were evaluated.

The comparison of four engines—JavaScriptCore, V8, QuickJS, and Hermes—covers four dimensions: bytecode support, SDK size, open‑source status, and author. JSC and V8 lack bytecode output, QuickJS supports bytecode but has limited performance, while Hermes supports bytecode, has a moderate SDK size, is open source, and is maintained by Facebook.

Benchmark results (Linux) show:

Package load time (lower is better): QuickJS fastest , Hermes close , JSC slower , V8 slowest .

Execution efficiency (higher is better): JSC and V8 best , Hermes second , QuickJS worst .

Memory increase (lower is better): JSC best , Hermes and V8 next , JIT‑enabled versions consume the most memory.

Compiled file size (lower is better for OTA updates): JSC and V8 produce larger compressed packages; Hermes and QuickJS produce smaller bytecode files.

Conclusion: JIT‑enabled JSC and V8 deliver the highest raw execution speed but suffer from long load times, high memory usage, and larger packages. Engines that allow pre‑compilation (Hermes, QuickJS) dramatically reduce load latency and memory overhead. Hermes is preferred because it also benefits from a mature React‑Native ecosystem.

Integration of Hermes involves compiling the engine and using its command‑line tools:

# Execute raw JS
hermes test.js
# Compile to bytecode and execute
hermes -emit-binary -out test.hbc test.js && hermes test.hbc

In C++ the runtime is created with:

std::unique_ptr<HermesRuntime> makeHermesRuntime(const ::hermes::vm::RuntimeConfig &runtimeConfig = ::hermes::vm::RuntimeConfig());

Key APIs for evaluating scripts are:

// Execute JS or bytecode
Value evaluateJavaScript(const std::shared_ptr<const Buffer>& buffer, const std::string& sourceURL);
// Pre‑compile JS
std::shared_ptr<const PreparedJavaScript> prepareJavaScript(const std::shared_ptr<const Buffer>& buffer, std::string sourceURL);
// Execute pre‑compiled JS
Value evaluatePreparedJavaScript(const std::shared_ptr<const PreparedJavaScript>& js);

Hermes also provides Value , Object , and Function abstractions similar to JSC, enabling type checks ( value.isString() ) and property access ( object.getProperty(runtime, "name") ).

The Hippy architecture consists of three layers: platform‑specific bridge (Objective‑C/Java), the cross‑platform HippyCore (C++ with a napi abstraction), and the front‑end JS SDK. Replacing JSC with Hermes only requires implementing the napi interfaces for Hermes in HippyCore, without changing the upper layers.

After integrating Hermes, QQ Browser observed a 70‑80 % reduction in package load time, a corresponding drop in first‑frame latency, and a 50 % decrease in crash rate compared with JSC. Memory growth remained comparable to JSC, confirming Hermes’ efficiency.

Future work includes extending Hermes to Android, improving debugging support (Chrome‑based debugging, memory diagnostics), and further performance tuning. The integration demonstrates that moving heavy JS work to a pre‑compiled engine can shift the performance bottleneck away from the JS runtime, allowing developers to focus on business logic.