Measuring a mini-program's performance, not its host

A mini-program is your code running inside an app you did not write, on a runtime you do not control, on hardware you did not choose. Each part of that creates a measurement problem.

What you are actually measuring

If you scope a performance capture to the host app, you measure the host’s UI, networking, analytics, background work and your mini-program. Your code is somewhere in that total, and there is no way to tell how much of it is yours.

That number cannot serve as a baseline, cannot be compared between sessions, and cannot support your case when someone says your mini-program is heavy.

The solution is to scope to the mini-program’s own process. Most hosts run each mini-program in a separate process, which is how they isolate mini-programs from each other and from the host. Once you are attached to that process, CPU, memory and frame rate describe your code.

What is still not yours

Even with correct scoping, part of the cost is structural:

• Runtime startup. The host must start the mini-program container before your first line runs. That time counts towards the session, and you cannot optimize it.
• Bridge overhead. Every call between your JavaScript and native capabilities crosses a boundary. It has a cost, and that cost is not visible in your own code.
• The host’s rendering pipeline. You describe a view; the host decides how to draw it. Your frame rate depends on a renderer you cannot profile.
• Shared memory limits. The host and every mini-program in it share the app’s memory allowance. A termination may be caused entirely by someone else’s code.

Telling these apart is most of the skill. A cold-start figure that includes container startup does not fairly measure your code, and treating it as if it does can lead to a week spent optimizing something you cannot change.

Measurements worth taking

Cold start, warm start and the difference. Run once, terminate, run again. The difference is roughly the part affected by caching; the baseline is roughly the structural part.

Memory over a round trip. Open your mini-program, use it, leave, and return. If the baseline rises each time, you are leaking memory in a process shared with other people’s code. The problem may be blamed on someone else, and it can eventually get every mini-program in the host terminated.

Frame rate on a list. Scroll performance is the most common mini-program complaint. The cause is nearly always too many nodes or images at the wrong size.

Network volume, not requests. You may not be able to see the requests, but you can see the bytes. A mini-program that downloads five megabytes on open has a problem that is visible from outside.

Hardware

Mini-programs tend to have more users on older devices. That is often why they exist, as a lighter alternative to installing an app. So a flagship on your desk is even less representative than usual.

Test on the cheapest device you can find. A mini-program that works well on a current phone but is unusable on a four-year-old one has failed at its main purpose.

Where the data is stored

Your mini-program’s storage lives in the host app’s container. Reading it answers questions that are otherwise guesswork: is the cache being written, did the package update, is the local database the expected size, is a downloaded asset complete.

The usual caution applies even more here. It is the host’s container, and it contains other mini-programs’ data along with yours. Look only at your own data, take what answers the question, and delete it afterwards.

Reporting results

When you need to justify your mini-program’s footprint to the host’s platform team, provide:

• Process-scoped captures, not host-scoped ones
• Cold and warm start times on a named device, with the device state recorded
• The same measurement before and after a change

A figure from the host’s own dashboard is a starting point for discussion. A process-scoped capture on a stated device is an answer.