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. Every part of that sentence is a measurement problem.

What you are actually measuring

Scope a performance capture to the host app and you get: the host’s own UI, its networking, its analytics, whatever else it is doing in the background, and your mini-program. Your code is somewhere in that total, and there is no way to tell how much of it is yours.

Which means the number is not usable as a baseline, not comparable between sessions, and not defensible when somebody says your mini-program is heavy.

The fix is to scope to the mini-program’s own process. Most hosts run each one in a separate process — that is how they isolate them 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 scoped correctly, some of the cost is structural:

• Runtime startup. The host has to bring up the mini-program container before your first line runs. That time is attributed to the session and is not something you can optimise.
• Bridge overhead. Every call between your JavaScript and native capability crosses a boundary. It is not free, and it 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. Getting killed can be somebody else’s fault entirely.

Knowing which of these is which is most of the skill. A cold-start number that includes container startup is not a fair measure of your code, and treating it as one leads to a week of optimising something you cannot change.

The measurements worth taking

Cold start, warm start, and the difference. Run once, kill, run again. The difference is roughly the part that is caching; the floor is roughly the part that is structural.

Memory over a round trip. Enter your mini-program, use it, leave, come back. If the floor rises each time, you are leaking inside a process you share with other people’s code — which will eventually be blamed on someone else and eventually get everyone killed.

Frame rate on a list. The single most common mini-program complaint is scroll performance, and it is nearly always either 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 pulling five megabytes on open has a problem visible from the outside.

The hardware point

Mini-programs skew towards users on older devices — often that is exactly why they exist, as a lighter alternative to installing an app. So the flagship on your desk is even less representative here than usual.

Test on the cheapest device you can find. A mini-program that is fine on a current phone and unusable on a four-year-old one has failed at the thing it was for.

Where the data lives

The host app’s container holds your mini-program’s storage. Reading it settles a whole class of questions that are otherwise guesswork: is the cache actually being written, did the package update, is the local database the size you expect, is a downloaded asset intact.

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

Reporting it

When you have to defend your mini-program’s footprint to the host’s platform team — and eventually you will — the useful artefacts are:

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

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