Engineering · Published March 15, 2026
Mini Program Performance: Trade-offs for a One-Second First Screen
Mini programs have bundle limits and platform startup costs, so first-screen work is about trade-offs, not tricks.
Every client asks for the same thing: it must open fast. Mini programs cap the main bundle and start through the platform layer, so the options are finite. We sort the work into three buckets by return.
Three kinds of optimisation
Fewer first-screen dependencies: the main bundle holds only the home page and shared components, other pages load as subpackages, and images go through a CDN compressed.
Fewer requests: merge home APIs into one call returning only first-screen fields, and load lists on scroll.
Cheaper rendering: avoid deep nesting and repeated nodes; use virtual scrolling for long lists.
Details that get missed
Synchronous work at startup blocks rendering; defer every initialisation that can wait.
A skeleton screen reduces perceived waiting better than a spinner, but it must match the real layout.
Test on weak networks. Many issues only appear at 3G speeds.
Optimising a mini program's first screen is mostly about cutting requirements, not stacking techniques. Do one thing first and it gets noticeably faster.
Want to apply these ideas to your project?
We are happy to go deeper into implementation details, or to discuss the specific questions you are facing.
Start a conversation →