How We Cut Mini‑Program Startup Time by 45%: Real‑World Performance Tactics

1. Origin

Users complained that the Mini Program opened extremely slowly, loading screens lingered, and scrolling caused frequent errors. Three main pain points were identified: slow startup, slow requests, and sluggish interaction.

2. Diagnosis

2.1 Startup Slow

Network impact was modest (average startup 3.7 s across Wi‑Fi, 4G, 2G/3G). Device performance showed a larger gap: high‑end phones started in ~2.9 s, while low‑end phones took up to 7.9 s, indicating that hardware is a key factor.

The official cold‑start flow was illustrated, showing that the client‑side initialization (information preparation, environment preparation) is handled by the WeChat client and cannot be altered; optimization must focus on code‑package download, injection, and first render.

2.2 Request Slow

Log analysis showed normal request volume, so backend overload was ruled out. The main cause was network latency and the 10‑request concurrency limit of wx.request. Pre‑fetching data during cold start could hide this latency.

2.3 Interaction Slow

After the first screen rendered, subsequent scroll loading and button clicks were slow and often timed out. The root cause was hitting the wx.request concurrency limit during rapid user actions, leading to request timeouts.

3. Optimizations

3.1 Startup Optimizations

3.1.1 Independent Sub‑Packages

WebView‑based activity pages were moved to independent sub‑packages, eliminating the need to download the main package for those pages and improving startup speed by ~30%.

3.1.2 Static Resources on CDN

Static assets were extracted, hashed with gulp‑rev, uploaded to a CDN, and references in CSS/JS/JSON/WXML were replaced with CDN URLs, reducing the main package size dramatically.

3.1.3 Unused Component Filtering

A custom CLI ( imweb‑miniprogram‑cli) analyzed component usage from app.json, recursively detecting unused custom components and excluding them from the final bundle.

3.2 Request Optimizations

3.2.1 Data Pre‑Fetch

Enabled in the Mini Program console, a cloud function fetches required data during cold start. The function maps page paths to fetch handlers and returns data that can be accessed via wx.getBackgroundFetchData. If the pre‑fetched data matches the page’s needs, it is rendered immediately; otherwise a fallback request is made.

const preFetchMap = {
  'pages/index/index': fetchIndex,
  'pages/course/course': fetchCourse,
}
exports.main = async (event) => {
  const { path, query = '' } = event;
  const fetchFn = preFetchMap[path];
  if (fetchFn) {
    const res = await fetchFn(query);
    return res;
  }
  return { error: { event, retcode: -1002, msg: `${path}页面未设置预拉取逻辑` } };
};

During runtime, wx.onBackgroundFetchData listens for the pre‑fetch result and renders the first screen as soon as data arrives.

3.2.2 Early Pull & Caching

When navigating between pages, a promise for the next page’s data is attached to the global App object. On page entry, the promise is awaited first, providing data before the UI updates. Successful responses are cached with wx.setStorage for instant rendering on subsequent visits.

3.3 Interaction Optimizations

3.3.1 Prioritized Request Queue

A wrapper around wx.request assigns priorities to business‑critical requests. Low‑priority requests are placed in a WaitingQueue once the concurrency limit is reached, ensuring high‑priority calls are processed promptly.

3.3.2 Stepwise Rendering

First‑screen data is rendered immediately via setData. Remaining data is rendered later using a promise‑based setTimeout helper, avoiding callback hell while preserving UI responsiveness.

4. Results

4.1 Package Size

Total bundle reduced from 9132.94 KB to 6736.42 KB (‑27%).

Main package reduced from 1949.71 KB to 985.96 KB (‑49.5%).

4.2 Startup & Request Latency

Download and JS injection times dropped noticeably. Users opening within 3 s increased from 56.26 % to 64.25 %.

Home page request time fell from an average of 400 ms to 50 ms (‑87.5%). Course detail page request time fell from 800 ms to 90 ms (‑88.75%).

Queue‑based request handling yielded an additional 15 % reduction (≈50‑100 ms) under weak‑network conditions.

4.3 Rendering

Stepwise rendering shaved 100‑150 ms off first‑screen paint, and cached second‑visit pages rendered instantly.

5. Conclusion

The comprehensive performance tuning—targeting startup, network, and interaction layers—delivered substantial improvements without requiring a higher base library version. Future work includes on‑demand component injection, initial‑render caching (available from 2.11.1), and experimental asynchronous sub‑package loading.