WeChat Mini Program Package Size and Performance Optimization Strategies

Background

WeChat limits the main package of a mini program to 2 MB for experience and performance reasons. The Haro WeChat mini program has grown from a simple to a complex main package, with npm libraries lacking unified management and third‑party component libraries being inherently complex. As a result, the package size has been stuck at the 2 MB threshold, causing several pain points:

Blocking normal business schedule for WeChat mini program feature releases.

Iteration demands require manual searching for size growth points, leading to temporary fixes rather than root‑cause solutions.

Lack of a unified size‑management platform on the WeChat side to limit package growth.

Large package size leads to long loading times and poor user experience.

Therefore, the goal is to optimize the package size and establish a long‑term control mechanism to keep the package size balanced and sustainable.

Package Size Optimization

The issue of WeChat mini program package size is common for any business that reaches a certain scale. Official documentation and community articles provide many solutions. We categorize them into conventional optimization methods and business‑specific technical solutions.

Performance Categories

According to the official WeChat mini program guide, performance optimization is divided into startup performance and runtime performance :

Startup performance: from the moment a user opens the mini program to the moment the home page rendering completes (signaled by the first Page.onReady event).

Runtime performance: determines the user experience during normal usage; problems may cause scrolling jank, response delays, high memory usage, black screens, or crashes.

1. Startup Performance Optimization

The startup flow includes several stages:

1.1 Resource Preparation

a. Mini program metadata (avatar, nickname, version, config, permissions) is fetched and cached.

b. Environment pre‑loading (subject to scene, device resources, OS scheduling).

c. Code package preparation – download from CDN with verification. WeChat applies several built‑in optimizations:

Code package compression.

Incremental updates.

Efficient network protocols (QUIC, HTTP/2).

Pre‑established connections to reduce DNS and handshake latency.

Code reuse via MD5 signatures to avoid re‑downloading unchanged packages.

1.2 Mini Program Code Injection

During startup, the configuration and code are read from the package and injected into the V8 JavaScript engine. WXSS and WXML are compiled into JavaScript and injected into the view layer. V8’s Code Caching is used to cache compilation results for faster subsequent injections.

1.3 First‑Screen Rendering

Both view and logic layers initialize in parallel. After the view layer finishes, it notifies the logic layer, which then sends initial data back. The framework renders the home page and triggers Page.onReady .

1.4 Optimization Measures

Control package size : Reduce the code package size directly to shorten download time.

Split packages (sub‑packages) – the most effective way to cut startup time.

Clean unused code and resources promptly.

Independent sub‑packages.

Pre‑download sub‑packages – reduces delay when navigating to a sub‑package page.

Asynchronous sub‑packages – split sub‑packages down to component or file granularity.

Code Injection Optimization

On‑demand import – only inject code that is actually needed at startup.

Timed injection – defer injection of certain custom components until they are rendered.

First‑Screen Rendering Optimization

Enable initial render cache – display the view layer before the logic layer finishes.

Data pre‑fetch – fetch business data from the backend during cold start.

Periodic updates – pull data in advance even when the mini program is not opened.

Skeleton screens – show placeholder UI while asynchronous data loads.

2. Runtime Performance Optimization

2.1 Optimization Measures

Reasonable use of setData : data transmission time is proportional to payload size; minimize unnecessary updates.

Page transition optimization: parallelize data requests with page navigation.

Request pre‑positioning – start data requests while the page is navigating.

Control pre‑loading of the next page (especially on Android) to avoid blocking the current page’s rendering.

Business‑Specific Optimization Solutions

1. Asynchronous Sub‑Package of Third‑Party Component Libraries

Because the main package is limited to 2 MB, many npm libraries occupy over 1 MB. By moving selected third‑party libraries into sub‑packages (using require for async loading), the main package can stay lightweight.

Implementation notes for Taro‑based projects (Webpack compiled):

Custom Webpack plugin to replace require with a custom key that is later restored.

Use Webpack’s __non_webpack_require__ to bypass Webpack’s static analysis.

Key considerations:

Code that previously used synchronous import must be refactored; a cache queue can handle calls before the async module is loaded.

Network failures for sub‑packages are rare; a retry mechanism can mitigate them.

2. Cover (Splash) Solution

Move all business logic into sub‑packages, keep only base libraries and common files in the main package, and display a splash screen that immediately redirects to the business sub‑package. This keeps the main package around 1 MB, improving performance and user experience.

Long‑Term Package Size Control Mechanism

Without a standard control method, the main package will eventually exceed the limit again. Two pillars are required:

Business‑line management backend – handles temporary size requests, approvals, notifications, and displays current permanent and temporary size allocations.

Release system management – GitLab hook triggers Jenkins to compile, calculate each business line’s size contribution, compare with allocated size, and block release if the limit is exceeded (with DingTalk notifications).

These mechanisms together ensure sustainable package size management and consistent release quality.