微信小程序性能优化指南

Why Care About Mini Program Performance?

Many developers think mini programs are simple features, so a bit of poor performance doesn’t matter. But in reality, mini program performance directly affects user experience and business metrics:

• Slow startup: Users tap in, wait forever with a white screen, and leave directly — conversion rate drops significantly.
• Laggy lists: Stuttering while scrolling, poor user experience, people don’t want to scroll down.
• Large package size: Main package exceeding 2MB — users can’t even download it, no entry point.
• High memory: Crashes after using for a while, especially noticeable on low-end phones.

We’ve calculated that reducing a mini program’s startup time from 3 seconds to 1 second can increase conversion rate by over 20%. Performance isn’t “icing on the cake” — it’s a basic requirement.

Over the years, we’ve built dozens of mini program projects and accumulated a lot of performance optimization experience. Today let’s systematically talk about how to optimize mini program performance across several dimensions.

1. Startup Performance: Let Users See Content Fast

Startup performance is users’ first impression of your mini program, and the most important optimization point.

1. Subpackage Loading: The Most Effective Optimization

Subpackage loading is the #1 tool for mini program performance optimization, bar none.

The main package only contains the home page and common resources. Other pages go into subpackages. When users open the mini program, they only download the main package. When they navigate to a subpackage page, the subpackage downloads then.

The optimization effect is dramatic:

• Reducing main package size from 2MB to 500KB can cut startup time by more than half.
• Package size limit also increases — total mini program can be up to 20MB (2MB main + multiple subpackages).

Subpackage principles:

• Keep main package small: Only TabBar pages and shared resources.
• Subpackage by feature: One feature module per subpackage.
• Load on demand: Uncommon features all go into subpackages.

2. Subpackage Pre-Download: Make Users Feel No Loading

Just having subpackages isn’t enough. If users only start downloading when they tap into a subpackage page, they still have to wait.

This is where subpackage pre-download comes in: when entering a page, pre-download subpackages that users are likely to need. By the time users actually tap in, the subpackage is already downloaded — opens instantly.

For example, the home page has a “My Orders” button that navigates to the orders subpackage. We can configure: when entering the home page, pre-download the orders subpackage. Then when users tap it, it’s already downloaded — instant open.

Choose pre-download timing carefully — don’t pre-download a bunch of subpackages right when the home page loads, that would actually slow down home page loading. Do it after the home page finishes rendering, during idle time.

3. First Screen Rendering Optimization: See Content First

First screen content should appear as soon as possible. Don’t wait for all data to load before rendering — render skeleton screen or static content first, then fill in data when it comes back.

A few techniques:

• Skeleton screen: While data loads, show a skeleton screen as placeholder — users feel it’s less slow.
• First screen data priority: Request APIs needed for first screen first, others come later.
• Cache strategy: Show last time’s data first, update when new data comes back. Users seeing old data is better than a white screen.

4. Code Injection Optimization

When a mini program starts, all JS code has to be injected into the WebView. More code = slower injection.

How to reduce injected code:

• Import on demand: Don’t import entire libraries — only import what you use. For example, with lodash, don’t import the whole thing — import just the functions you need.
• Tree Shaking: Make sure your build tool has Tree Shaking enabled — shake out unused code.
• Extract common code: Code used by multiple subpackages — extract it into the main package or an independent subpackage. Don’t bundle a copy in each subpackage.

2. Rendering Performance: Smooth Scrolling

After startup, whether it feels smooth to use depends on rendering performance.

1. Long List Optimization: The Most Common Performance Issue

Long lists are the most common cause of lag in mini programs. Hundreds of items, all rendered at once — too many DOM nodes, definitely laggy when scrolling.

Optimization solutions:

Solution 1: Pagination

Don’t load all data at once — load page by page. Load next page when scrolling to the bottom.

This is basic, everyone should know this.

Solution 2: Virtual List

If data volume is especially large (thousands of items), pagination isn’t enough — even with pagination, DOM nodes keep accumulating as you scroll, still gets laggy.

This is when you need virtual lists: only render nodes in the visible area. Nodes that scroll out get destroyed, new ones scrolling in get created. This way, no matter how many items there are, the number of DOM nodes stays constant — never lags.

WeChat has an official recycle-view component you can use directly. There are also third-party virtual list components.

Solution 3: List Item Optimization

Even with pagination and virtual lists, if list items themselves are too heavy, it’ll still lag.

Optimize list items:

• Reduce node count: fewer DOM nodes inside list items is better.
• Avoid complex layouts: Don’t put overly complex layouts in list items, especially deeply nested flex.
• Image lazy loading: Images in lists use lazy loading — load when they enter the visible area.

2. setData Optimization: The Most Overlooked Optimization Point

setData is a major performance hotspot in mini programs. Many people just stuff everything into setData, and stuff huge amounts every time.

But do you know? setData has costs. Every setData requires:

1. Logic layer sending data to render layer (cross-thread communication, has overhead).
2. Render layer recalculating and re-rendering.

If setData is too frequent or data volume is too large, it will definitely lag.

Optimization principles:

• Only pass data that needs updating: Don’t pass the whole object every time — only pass the part that changed. Supports path syntax, like this.setData({ 'user.name': 'xxx' }).
• Merge multiple setData calls: Multiple setData calls in a short time — merge into one. For example, don’t setData inside a loop every iteration — do it once after the loop finishes.
• Don’t setData for invisible data: Data users don’t see — don’t put it in setData. Intermediate variables for calculations just store on this, no need to put in data.
• Don’t setData large datasets at once: For long lists, don’t setData hundreds of items all at once — do it in batches.

3. Reduce Re-renders

When data changes in a page, does the whole page have to re-render? Not necessarily.

You can use methods to reduce unnecessary re-renders:

• Componentization: Split pages into components. When data changes, only update the corresponding component — don’t redraw the whole page.
• Pure data fields: Some data is only used for calculation, doesn’t need rendering. Use pureDataPattern to mark them as pure data fields — changes to these won’t trigger re-renders.
• Use observers wisely: Don’t trigger a bunch of calculations for every data change. What can be calculated once, don’t calculate multiple times.

3. Package Size Optimization: Smaller is Better

Package size directly affects startup speed, and there’s the hard 2MB main package limit. Package size optimization is a must.

1. Image Optimization: The Biggest Chunk

Generally speaking, images take up the largest proportion of mini program package size. Optimize images well and you can reduce package size significantly.

Optimization methods:

• Put images on CDN: Don’t put all images in the mini program package. Put whatever you can on CDN. Only keep essential small icons in the package.
• Use WebP format: Same image, WebP is 30%+ smaller than JPG/PNG. Mini programs support WebP, use it confidently.
• Compress images: Always compress images before going live. Use tools like tinypng — after compression you can’t tell the difference visually, but size is much smaller.
• Sprite sheets: Combine small icons into sprite sheets — reduces request count and file count.

2. Code Optimization

Besides images, there’s code.

• Remove unused code: Regular cleanup — delete unused pages, components, utility functions. Many projects have tons of dead code taking up space for no reason.
• Trim third-party libraries: Be careful when introducing third-party libraries. A library can be dozens of KB — is it worth it? Can you write a simple alternative yourself?
• Import on demand: As mentioned before — don’t import whole libraries, only import what you use.
• Template optimization: Don’t have too many useless nodes in WXML. Merge what you can.

3. Subpackage Optimization

We talked about subpackage loading earlier — subpackages are also an important way to control package size.

• Main package only has essentials: Keep main package as small as possible. Whatever can go into subpackages, put it there.
• Independent subpackages: Some features not closely related to the main package can be made into independent subpackages. Independent subpackages don’t depend on the main package, can be opened separately — faster startup.
• Subpackage asynchronization: Some components or JS modules not needed for first screen can be loaded asynchronously — load when needed.

4. Network Optimization: Fast, Stable, Efficient

Network requests are also an important factor in experience. Slow APIs = slow pages.

1. Reduce Request Count

Fewer requests = better.

• Merge APIs: If first screen needs several APIs, merge them into one if possible. One less HTTP request saves a lot of time.
• Sprite sheets: As mentioned before — combine small icons, reduce image requests.
• Caching: Data that can be cached — cache it, don’t request every time.

2. Speed Up Requests

• CDN acceleration: Static resources all on CDN — nearest access, faster.
• HTTP/2: If server supports HTTP/2, multiplexing — faster.
• API performance optimization: Backend APIs themselves need to be fast. Slow APIs need optimization — add indexes where needed, add caching where needed.

3. Pre-Requests

Same idea as subpackage pre-download — request ahead of time.

For example, user is on a list page, taps in to see detail page. We can pre-request detail page data when users hover over list items (or when the list page finishes loading). By the time users actually tap in, data is already back — display immediately.

Of course, control the degree of pre-requesting. Don’t pre-request too much and waste bandwidth.

4. Weak Network Optimization

What about when the network is bad? Can’t just wait with a white screen forever.

• Loading state: Show loading during requests — let users know it’s loading.
• Retry on failure: If request fails due to bad network, auto-retry a few times, or give users a retry button.
• Offline cache: Some data that doesn’t change often — cache locally. Viewable without network, update when network is available.

5. Memory Optimization: Don’t Crash

High memory and the mini program crashes. Especially on low-end phones with less memory — easier to crash.

1. Image Memory

Images are memory hogs. Too many images, too large — memory skyrockets.

Optimization:

• Don’t use oversized images: Thumbnails in lists — use thumbnail URLs, not original full-size images.
• Recycle promptly: When leaving a page, images shouldn’t keep taking up memory. For long lists, images that scroll out can be recycled.
• Avoid loading too many images simultaneously: Don’t have too many images on one screen — use lazy loading.

2. Page Stack

Mini program page stack maxes out at 10 levels. If users keep navigating deeper, more and more pages — higher and higher memory.

Optimization:

• Use redirect appropriately: Pages you don’t need to return from — use redirectTo instead of navigateTo. Then the old page is destroyed.
• Go back multiple levels: For example, A→B→C→D, after D is done you need to go back to A — don’t go back step by step. Use navigateBack to go directly back to A. Pages in between are all destroyed.

3. Timers and Event Listeners

Many people forget — when a page unloads, timers and event listeners need to be cleaned up.

• setInterval, setTimeout: Clear them on page onUnload.
• wx.onXXX event listeners: Off them when page unloads.
• Otherwise, even though the page isn’t visible, it’s still running in memory — memory leak.

4. Release Data Promptly

Pages storing lots of big data (like long list data) — when page unloads, clear it. Otherwise the page object keeps referencing the data, GC can’t collect it.

During onUnload, set big data to null to help GC回收 (collect).

6. How to Find Performance Issues?

Before optimizing, you need to know where the problems are. Can’t optimize blindly.

1. Mini Program DevTools

WeChat DevTools has a performance panel — can see startup time, render time, memory usage, network requests, etc.

• Performance Trace: Record performance data for a period of time, then analyze what’s slow.
• Code Dependency Analysis: See size of each package, each file — find large files.
• Memory Panel: See memory usage, check for memory leaks.

2. Real Device Debugging

Performance in DevTools differs from real devices. Always test on real devices, especially low-end phones.

• Real device debugging: Connect to real device, see performance data.
• Experience score: Mini program backend has experience scoring — automatically detects performance issues, gives optimization suggestions. Very useful, recommend running it regularly.

3. Performance Monitoring

After going live, you also need to monitor performance. Can’t just optimize during development and forget about it after launch.

• Custom tracking: Add tracking at key points — like startup time, first screen time, page load time — report to backend.
• Monitoring platform: Use mini program’s built-in performance monitoring, or integrate third-party APM tools — monitor live performance in real-time.

Closing Thoughts

Performance optimization isn’t something you do once and you’re done. It’s not a one-time thing and it’s not permanent.

It’s not like you optimize once and that’s it — as requirements iterate, code grows, performance gradually degrades again. So performance optimization is an ongoing process — you need to keep at it.

And performance optimization isn’t “optimizing for optimization’s sake.” All optimization ultimately serves better user experience and better business metrics. Before optimizing, figure out first: what’s the most painful point for users? Where has the biggest business impact? Optimize those first — highest ROI.

Hope this article helps you. If your mini program also has performance issues, why not try these methods?