Kuaishou Mini‑Program Simulator: 3× Faster After Performance Optimizations

Problem Background

Mini‑programs are lightweight apps that run inside the Kuaishou ecosystem without installation. The simulator, a core component of the Kuaishou developer tool, emulates the behavior of mini‑programs on the client. Developers complained that the simulator’s startup was slow, with an instant‑open rate of only 18% and a first‑contentful‑paint (FCP) P90 of 4.4 seconds.

Analysis and Solution

1. Measuring Startup Stages

Because the simulator runs in two separate Electron processes (Webview for the render layer and BrowserView for the logic layer), traditional performance recording cannot capture both processes. The team introduced manual instrumentation to log timestamps for each stage, revealing that the container‑preparation phase consumed the most time.

2. Reducing Container‑Preparation Time

The original design destroyed and recreated the logic‑layer container on every refresh, re‑loading framework files and the base library each time. Three alternatives were evaluated:

BrowserView + IFrame

WebWorker

IFrame only

The IFrame solution was chosen because it minimized process creation, allowed resource sharing via the parent window, and offered the best refresh speed.

3. Module Cache Reuse

With the logic and render layers now in the same process, shared modules can be cached in the parent window, reducing the size of framework bundles and speeding up loading.

4. On‑Demand Compilation

Previously the simulator loaded compiled assets for all pages at startup, which wasted time. The team switched to on‑demand loading using readFileSync + eval , loading a page’s compiled code only when needed.

5. Fixing Breakpoint Loss with #sourceURL

Switching to eval broke the debugger’s ability to map code to source files, causing breakpoints to fail. Adding a #sourceURL comment to the evaluated code restored the mapping without waiting for sourcemap parsing.

<code>// example sourceURL comment
//# sourceURL=example.js</code>

6. Understanding Performance Recording Impact

Enabling the Chrome DevTools Protocol (CDP) performance recorder unexpectedly improved simulator startup speed. Investigation showed that many CDP messages sent by the debugger (mostly disabling unused features) reduced overhead. By caching and delaying these messages until they are needed, the startup time was further reduced.

Results

After the optimizations, the simulator’s instant‑open rate rose from 18% to 64% and FCP P90 dropped from 4.4 seconds to 1.9 seconds. Developer satisfaction increased, and the team added a toggle to enable or disable the new logic for stability.

Conclusion

The performance project demonstrated that consolidating the simulator into a single process, reusing module caches, loading compiled assets on demand, and refining debugger interactions can dramatically improve developer experience for Kuaishou mini‑programs.