Boost WeChat Mini Program Performance: Startup, First-Render, and Rendering Optimizations

Startup Performance Loading

This section describes the startup loading process: public library injection, resource preparation (basic UI creation and code package download), business code injection and rendering, first‑screen rendering, and asynchronous requests.

Optimization solutions

Control code package size

Enable "auto compress on upload" in developer tools.

Regularly clean unused code and resource files.

Reduce the size and number of images and other resources.

Host images and static assets on a CDN.

Extract common styles and components for reuse.

Compress code and use external linking where appropriate.

Subpackage loading Mini programs can contain a main package and one or more subpackages. The main package includes the startup page or tabBar pages and shared resources. When a subpackage page is opened, the client downloads that subpackage before displaying it. Advantages:

Allows larger overall code size and more features.

Users experience faster app opening without affecting startup speed.

Limitations:

Total size of all subpackages must not exceed 8 MB.

Each main package or subpackage must not exceed 2 MB.

Runtime mechanism optimization

Reduce the number of immediately‑executed code blocks.

Avoid high‑cost, long‑blocking operations.

Place business logic within page lifecycle methods.

Implement effective caching strategies.

Data management optimization

Keep first‑screen request count ≤ 5; merge APIs when possible.

Combine multiple data submissions into a single request.

First‑Screen Loading Experience Recommendations

Pre‑request Asynchronously request data without waiting for page rendering to finish.

Utilize cache Use the storage API to cache asynchronous request data, render the page from cache first, then update in the background.

Avoid white screen Display a skeleton screen and basic content before the full UI loads.

Rendering Performance Optimization

Each setData call triggers inter‑process communication; the cost is proportional to the data volume and blocks user interaction. setData is the most frequent source of performance issues.

Use lazy loading for list data and dynamically remove off‑screen DOM nodes to keep the DOM lightweight.

Offload long‑running JavaScript to asynchronous tasks to avoid blocking the single‑threaded JS engine.

Avoid the scroll-view component when possible; use plain view with CSS scrolling instead.

Combine scroll callbacks with debounce or throttle functions to prevent jank.

Lazy‑load images by adding the lazy-load attribute (effective for images inside page and scroll-view).

Limit rapid page navigation to prevent multiple simultaneous transitions.

Avoid improper use of setData

Share data via the page data object only when needed for rendering.

Transmit only the data required for UI updates; use special keys for partial updates.

Merge frequent setData calls to reduce communication overhead.

Stop sending setData when the app moves to the background (e.g., pause timers).

Avoid improper use of onPageScroll

Listen to pageScroll events only when necessary.

Do not execute heavy logic inside onPageScroll.

Avoid frequent setData calls inside onPageScroll.

Reduce frequent node queries; consider using IntersectionObserver as a replacement.

Use custom components to isolate frequent updates, ensuring that only the component re‑renders rather than the whole page.

Enable the experience rating feature during development to identify performance bottlenecks and guide further optimizations.