Last winter, we sat in the client's meeting room tapping open that tea miniprogram again and again on a two-year-old Android phone, stopwatch beside us. First screen: just over 3 seconds, occasionally 4. The client hadn't complained — it just bothered us.
First, how we measured it. What the WeChat DevTools shows doesn't count; real devices differ too much. We used the miniprogram's built-in trace plus timestamps at three points — onLaunch in app.js, the homepage's onLoad, and onReady — logging the three durations into a backend table. Twenty runs, take the median. Without this, there's no way to prove whether it got faster after the changes.
Fix 1: Images
The main package carried 11 images — 3 carousel banners, 8 category icons — all PNGs, 1.2 MB in total. We moved them to the CDN, converted them to webp, requested sizes matched to screen width, and replaced the icons with an icon font. That alone shaved nearly 900K off the main package.
One small pitfall: webp wasn't supported on some older Android versions at the time, so we kept a PNG fallback, chosen by request headers. Not much — a few lines of code.
Fix 2: Subpackaging
Four pages nobody ever opened: brand story, franchise info, historical order details, help center. They'd all been sitting in the main package, downloaded along with the first screen. We split them into a subpackage, leaving only the homepage, categories, product detail, and cart in the main package. WeChat's main-package limit was 2 MB back then; ours was 1.9 MB — right up against the line.
While splitting, we found one shared utils file imported by both the main package and the subpackage, bundled twice. Moving it into the main package to be shared saved a bit more. We also configured two predownload rules so the subpackage fetches during idle time after the homepage opens — no waiting when users tap through.
Fix 3: Requests
The homepage used to fire 3 requests: banners, categories, recommended products. Three APIs waiting in sequence could stack up over a second on a weak connection. We merged them into one home API — the PHP backend queries everything once and returns it in a single payload. API count went from 3 to 1. The response got a little bigger, but we saved two round trips.
While we were at it, we added a 300-second Redis cache for homepage data, same as the one on the client's website.
The Result
Main package: 1.9 MB down to 1.1 MB. Median across 20 real-device runs: 1.8 seconds; the slowest was 2.3 seconds, on flaky meeting-room Wi-Fi. No framework change, no server migration, no extra machines.
We later wrote this measuring method into our delivery checklist: decide how you'll measure before optimizing performance, otherwise 'it feels faster' is not a sentence you can put on an acceptance form.
We wrapped up early that day. The meeting room heating was strong, and the borrowed stopwatch never went back.
