Frontend Development 14 min read

Package Size Control Practices in Didi Ride‑Hailing Mini Program

After moving its WeChat/Alipay entry to a Didi Ride‑Hailing mini‑program, the team kept the main bundle under the 2 MB limit by applying MPX‑based webpack tree‑shaking, minification, CDN‑compressed assets, aggressive sub‑package splitting and a lightweight cover page, reducing the core to about 1.1 MB while shifting most business logic into 800 KB–1.2 MB sub‑packages.

Didi Tech
Didi Tech
Didi Tech
Package Size Control Practices in Didi Ride‑Hailing Mini Program

The article describes how Didi Ride‑Hailing migrated its WeChat/Alipay entry to a mini‑program in late 2019, which caused a rapid increase in code and asset size, especially for the main package that must stay under 2 MB per sub‑package and 20 MB total.

Background : The mini‑program originally only handled ride‑hailing, but after adding many business lines (bus, chauffeur, bike, car‑pool, etc.) the homepage became a single page that hosts all business‑line components, leading to a bloated main package.

Volume Control : The team introduced a series of optimizations, starting with basic techniques such as resource compression, removing dead code, CDN delivery, and asynchronous loading. The MPX framework (https://github.com/didi/mpx), which is built on webpack, provides built‑in support for these optimizations.

Key practices include:

Using webpack’s tree‑shaking, code minification, and split‑chunks to eliminate redundancy.

Uploading static assets (images, videos) to CDN after compression.

Leveraging mini‑program sub‑packages to load pages and resources on demand.

Analyzing Package Size : The team used npm run build --report with webpack-bundle-analyzer to visualize the composition of the main bundle (e.g., moment, lodash, socket‑weapp, core‑js) and identify large modules.

Configuring Sub‑Packages : By moving less‑frequently used pages (e.g., itinerary, route selection, personal center) into sub‑packages, they reduced the main bundle by about 400 KB. MPX’s early support for sub‑package rules was extended to automatically place npm‑installed dependencies into the appropriate sub‑package based on import paths.

Fine‑Grained Sub‑Package Management : The framework now marks each dependency with the sub‑packages that reference it. If a dependency is used by only one sub‑package, it is emitted into that sub‑package; shared dependencies are extracted into dedicated cache groups. Resources referenced by multiple sub‑packages but not by the main bundle are duplicated in each sub‑package to keep the main bundle minimal.

Cover Page Solution : To further protect the main bundle, a lightweight cover page (containing only the Didi logo) is shown first, then immediately redirects to the actual business page placed in a sub‑package. This keeps the main bundle limited to core framework code (~1 MB) while the bulk of business logic resides in sub‑packages.

Result : After applying these strategies, the main package stayed around 1.1 MB, while the primary business sub‑package occupied roughly 800 KB–1.2 MB. Future feature growth mainly affects the sub‑package, preserving headroom in the main bundle and avoiding frequent size‑limit issues.

The article concludes that MPX provides extensive support for mini‑program package size control, and the described practices can help other developers facing similar constraints.

Package Optimizationfront‑end developmentWebpackMini ProgramDidi Ride-HailingMPX FrameworkSplit Packages
Didi Tech
Written by

Didi Tech

Official Didi technology account

0 followers
Reader feedback

How this landed with the community

login Sign in to like

Rate this article

Was this worth your time?

Sign in to rate
Discussion

0 Comments

Thoughtful readers leave field notes, pushback, and hard-won operational detail here.