WeChat for Dummies: How to make your WeChat Mini Program blazing fast

太慢了！
        - WeChat user who waited 2.4 seconds

The standard for “fast” in the WeChat world has changed, and user expectations have caught up.

We love how easy it is to make highly available, fast, and polished applications on the platform. Then again… looking at the competition, they are also equally “fast”. Suddenly we don’t feel so fast anymore.

On top of this, the community lacks a clear set of best practices for optimizing and avoiding performance bottlenecks in Mini Programs. A lot of common frontend “bugs” and other pain points in the Mini Program platform are often due to performance issues.

Outside of a silky smooth user experience, we also want it to feel 🔥blazing fast.

How can we do that?

Looking under the hood of the Mini Program framework, we’ve pinpointed some performance issues we often see out in the wild, and put together some guidelines for how to avoid them.

Decrease static bundle size

When a user opens your Mini Program for the first time, whether it’s by scanning a QR code or clicking an internal WeChat link, users have to download your Mini Program bundle on the spot. This initial load speed of your Mini Program is mission critical to achieving business goals, and is directly dependent on the size of your Mini Program. To decrease this bundle size, make sure only UI-critical assets and images are included in the source code you upload to WeChat. Everything else should be loaded asynchronously from your API. Remove any unused WXSS or WXML markup before release.

WeChat imposes a size limit of 2MB, but if you use all 2MB of this allotment, you could potentially have a slow Mini Program on your hands.

Avoid fancy CSS animations

One of the main culprits of UI janky-ness in the MP environment is the misuse of CSS animations. Although they look cool, CSS keyframes and transforms can cause noticeable scroll bugginess or UI lag in your Mini Program. It’s the unfortunate truth. This is similar to the web, but particularly pronounced on the Mini Program platform. Consider the trade-offs: if animations are crucial to your desired user experience, use them sparingly and test on a variety of devices.

Be smart with HTTP requests

Too many HTTP requests from the Mini Program can cause a buggy frontend user experience if not coordinated properly. Every time the MP receives new data, it has to render the UI again. An added pain: WeChat limits your Mini Program to 10 concurrent HTTP requests at any given time. If you exceed 10 concurrent requests, the framework will put your remaining requests into a request queue, which could cause a slow response time from the user’s perspective.

Solution: Batch requests whenever possible. If you have a lot of data I/O, consider caching anything reusable on the client side. The best way to do this is with a state management library such as Redux.

Don’t let images kill your load speed

Optimizing your HTTP requests will be futile if you don’t also optimize image rendering. First of all, make sure your backend team is aligned on the performance needs of the Mini Program. Images rendered from API or CDN can be cached by the Mini Program if Cache-Control header is configured.

Utilize image optimization through your CDN if possible. High definition images can add unnecessary load speed, and potentially block the network for other requests the Mini Program needs to make. In an ideal world, keep image size below 150kb.

Icon solutions: If you have a lot of icons in your Mini Program, consider using a CSS image sprite to cut down on bundle size and increase load speed of icons.

Don’t write crappy code

When writing JavaScript code for your Mini Program, be mindful of the event loop, and don’t abuse it. In the Mini Program environment, some common JavaScript functions such as setTimeout and setInterval are set in the global scope, not page scope. A setInterval initialized on a page will continue taking up memory throughout the MP if clearInterval is not called when the page is unloaded, causing a memory leak!

Utilize asynchronous functions whenever possible, especially when working with the Mini Program’s native API. For example, wx.getSystemInfoSync will block your runtime, while wx.getSystemInfo will allow you to use a callback and avoid runtime blockage.

Similar to optimizing web performance, writing clean WXML and WXSS code will help you optimize your Mini Program’s load speed and render speed — remember your code has to be bundled and sent over HTTP by WeChat, then parsed and rendered by the client. Messy or repetitive code inherently slows this process down.

Fight the good fight: don’t allow any spaghetti code in to your Mini Program codebase.

Yikes! That sounds complicated…

This may seem like a lot of complicated issues to tackle, but as with anything, start small and move from there. Start by monitoring the performance of your Mini Program to identify any issues. Performance profiling for Mini Programs is still very limited, but make sure to at least get familiar with the audit and trace tabs in your WeChat IDE. These tools can help you get a basic idea of your UI render performance.

A quick summary for the attention deficit, this is how you make your mini program blazing fast:

• Decrease static bundle size
• Avoid fancy CSS animations
• Be smart with HTTP requests (and cache!)
• Don’t let images kill your load speed
• Don’t write crappy code

Lastly — don’t be afraid to experiment. At a meager two years old, the Mini Program platform is still young, and different cases may require a new method for shaving off the extra 500ms or so of load speed that can make or break your business goals.