How to Slash Taro Mini‑Program Hot‑Update Build Times by 3×

Background

As the business grew, the code size of the mini‑program exploded; the largest B‑end mini‑program now has more than 260 pages and the dist directory reaches nearly 35 MB in dev mode. On slower devices the whole process of code change → Taro hot‑update → mini‑program IDE build → page reload exceeds 13 seconds, which is repeated hundreds of times daily, severely hurting development efficiency.

Current Build Situation Analysis

Our B‑end mini‑program runs inside DingTalk, using the runtime Taro + React. The debug tool is the Alipay mini‑program IDE. Typically the framework builds once, compiling runtime code into a platform‑specific DSL and outputting a dist package, which is then fully built into an offline bundle. In watch mode the IDE watches the dist folder; any file change triggers the whole process again.

The current workflow is: Taro builds → IDE builds (shows “Compiling”) → IDE rebuild completes → simulator reloads the latest code.

Taro Build Works Fine

On a real project (pages sanitized) running on an M1 Pro, changing a single line of code and running the hot‑update three times yields a total time of over 10 seconds. On Windows devices it is even slower. The IDE build time grew from about 2 seconds to more than 9 seconds, while Taro’s own build time increased from 0.3 seconds to 1.6 seconds.

Upgrading Taro from 3.4.0 to 3.6.19 dramatically improved both build speed and package size: a 200‑page mini‑program now updates in under 2 seconds by default. Newer Taro versions (3.5+) also bring black‑tech features and support for Vite‑based ESM builds.

IDE Build Becomes Bottleneck

The main reason the IDE build slows down is the increase in code volume. A demo project’s dist is only 2.8 MB, while the real project’s dist in dev mode reaches around 35 MB, making the IDE rebuild inevitably slower.

Because the IDE rebuilds the entire dist each time, the large codebase directly leads to long build times.

Increase in Code Volume

Demo project dist size: 2.8 MB

Real project dist size in dev mode: ≈35 MB

IDE Version Easter Egg

Downgrading the Alipay mini‑program IDE to a version before 3.4.3 can improve build speed by more than 30 %. The author promises a free drink if the claim fails.

Possible Solutions

Solution 1: Split Mini‑Program into Multiple

Divide the monolithic mini‑program into separate projects by business domain (e.g., data dashboard, product management). This reduces the codebase per project, speeds up builds, and aligns with the “small, fast, lightweight” principle of mini‑programs. However, it introduces challenges such as shared component libraries, inter‑app communication, version management, and increased learning cost for users.

Solution 2: Compile to H5

Since Taro supports multi‑platform output, the code can be compiled to a web (H5) version for preview. This works for simple demos, but API differences and design fidelity issues make it unsuitable for full‑scale development.

API Differences

Browser and IDE simulate APIs differently; some APIs are unavailable in browsers, requiring fallback to the IDE for debugging.

Design Fidelity

Pixel‑perfect design restoration is harder on browsers because the build outputs differ from the mini‑program container.

Process Issues

Developers may code against the browser, but final testing and release must be done in the IDE, leading to hidden compatibility problems.

Solution 3: Dynamic Build

Implement a progressive build: initially build only a minimal set of pages, then dynamically analyze page dependencies and build on demand. This requires intercepting Taro’s configuration and routing.

The workflow:

Generate a temporary temp.app.config.js that only contains essential routes (tabbar, login, landing page).

Replace the original app.config.js reference in Taro with the temporary file.

Start a local Node service that exposes an HTTP endpoint (e.g., http://localhost:xxxx/update?target=/pages/xxx/a) to update the temporary config with new routes on demand.

When a navigation API (e.g., Taro.navigateTo) is called, check if the target route exists in the temporary config; if not, request the update endpoint, then let Taro rebuild the needed pages.

After the temporary config changes, Taro’s watch mode triggers a rebuild, and the mini‑program reloads to the newly built page.

The entire logic is packaged as a Taro plugin, which can be added to the project’s build configuration:

/**
 * Pseudo‑code for Taro build config (config/index.js)
 */
module.exports = {
  // ...
  plugins: ['taro-plugin-dynamic-build'],
  // ...
};

Visualization Extension

A VSCode extension was created to manage routes visually: developers can select the routes that need to be built, which updates temp.app.config.js automatically, reducing the number of rebuilds when debugging across multiple sub‑packages.

Issues

The local Node service cannot trigger dynamic builds on real devices; routes must be pre‑built before previewing on a device.

Hijacking app.config.js and modifying Taro’s internal APIs requires source code changes, which is intrusive.

Conclusion

The described solution has been applied to mini‑programs with over a hundred pages, combined with IDE version downgrade, achieving roughly a three‑fold improvement in hot‑update speed—most daily updates now finish within about 3 seconds.

During implementation, many interesting Taro internals were discovered, contributing back to the open‑source project. The long‑term maintenance of Taro is commendable.