Mini Program Upload Says the Code Package Exceeds 2M: Is Cutting Features the Only Way Past It?

Conclusion first: When upload warns that the code package exceeds the limit, in most cases it is not because too many features were built, but because things were put in the wrong place—static assets such as images and audio/video were bundled into the code package, and pages used only once, along with heavyweight third-party libraries, were stuffed into the main package. Following common practice in 2026—move resources out first, then split the structure, and finally replace dependencies—most mini programs can get back under the limit without touching core features. Cutting features comes last; only when feature density is genuinely high does it make sense to talk about trimming.

First, distinguish: is it the main package, a single subpackage, or all subpackages combined that exceeds the limit?

Platforms set separate upper limits for these different kinds of size, and the error messages differ, as do the handling paths. If you only stare at the total size and delete files, you can spend a long time deleting and still get stuck on the same warning when you re-upload.

• Main package over limit: The main package holds the launch page, tabBar pages, and shared logic, and is often blown up by assets such as logos, banner images, and font files.
• A single subpackage over limit: Usually a business module's pages and images have grown large together; splitting that module further generally gets it through.
• All subpackages combined over limit: This is an overall scale problem. Clean up redundant dependencies and old pages that have not been used for a long time rather than continuing to split packages.

The proper approach is: in the developer tool's code dependency analysis or package size analysis, first see clearly how large each package is and which part exceeds the limit, and only then start. If you cannot say which package exceeds the limit, or whether it is assets or code, do not start deleting files. The specific upper and lower limits for each platform are subject to the current official documentation; they differ across platforms and over time.

Where the size usually goes: three commonly overlooked big consumers

From what we see on delivery projects, package size is rarely blown up all at once; it usually piles up gradually over several rounds of adding requirements, swapping images, and integrating third-party libraries. The experience range is roughly: static assets such as images and audio/video often account for 30% to 60% of main package size, whole-package imports of third-party component libraries easily run into hundreds of KB, and the rest is duplicate icon fonts and built-in dictionary-type data.

• Assets: Banners, product images, large onboarding images, demo videos, and notification audio—often bundled only so they load faster locally.
• Dependencies: A full UI library, chart library, rich text editor, or map capability package, imported as a whole package even when only one component is used.
• Redundancy: Multiple sets of icon fonts in the same style, province/city/district dictionary JSON, and abandoned pages and images left over from earlier versions.

A typical counterexample: three images around 200KB each on the home page placed directly in the local directory come to nearly 600KB once bundled, and stacking a whole-package component library on top leaves the main package with almost no headroom.

A reusable three-layer slimming method

Do it in this order because it is ranked by high payoff and low risk: moving resources out shows results quickly and barely changes business logic; structural adjustments solve most of the remaining size but require regression testing; dependency replacement changes how features are implemented, carries higher risk, and should be done last.

1. Layer one: move resources out. Move images, audio/video, and fonts to object storage or cloud storage, keep only paths in the code, and verify whether the download domain has been added to the allowlist. The bar for success is that the package basically no longer contains large images, while first-screen image load time remains acceptable.
2. Layer two: structural splitting. Divide subpackages by business module, keep shared components and utilities in the main package, and keep the launch path lean. Use on-demand injection and subpackage preloading when necessary, but configure preloading only for the next step with high certainty—do not preload all packages at once.
3. Layer three: dependency replacement. Switch component libraries to on-demand imports, replace large unused libraries with lightweight implementations or native code, and clean up abandoned pages and duplicate static assets. Every time you replace a dependency, regress the related pages.

A common situation on delivery projects: the client has a limited budget and a fixed launch date, but operations wants images changed every day and keeps adding more assets. A workable approach is to do only the resource move-out first, put images uniformly in object storage and complete the download domains, then split products, campaigns, and membership into three subpackages by business. The result is usually the main package dropping from just over 3MB to around 1.5MB and upload passing again; the cost is that the allowlist missed one domain the first time, online image loading failed, and it took most of a day of rework to fill the gap.

In terms of experience range, doing layer one alone usually cuts 20% to 30% of size, and stacking two layers clears most over-limit warnings; if after all three layers you are still right at the limit, that means feature density really is high, and only then is it reasonable to discuss cutting features or launching in batches.

Comparing three routes: how fast they work, effort, and risk

Even when the goal is the same—cutting package size—different approaches take very different amounts of effort. Use the experience ranges below to estimate how far your project should go.

• Resource move-out only: Effort is typically half a day to two days, reduction is typically 20% to 30%, risk is low, and the cost is maintaining domain and permission configuration—a missed entry directly affects online images.
• Resource move-out plus business-based subpackaging: Effort is typically three to eight working days (including regression testing), reduction is typically 30% to 50%, risk is medium, and the cost is long-term maintenance of subpackage configuration and path rules.
• Adding dependency replacement on top: Effort increases with the number of components, typically one to three weeks; reduction depends on the share of dependencies; risk is higher; and the cost is re-regressing related pages and possibly handling compatibility for certain interactions.

These are the typical ranges, but for your project it also depends on the share of images, the number of third-party libraries, and how familiar the team is with split structures. Laying out these three routes makes it easier to discuss timeline and budget clearly than starting by deleting features.

When it is worth doing, and when it is not

Typical cases worth investing in: content- or image-heavy apps (malls, campaign pages, galleries), many independent business modules, plans for long-term iteration, and package size already close to the limit. In 2026 there is another category: mini programs that integrate heavy dependencies such as live streaming, maps, or rich text editing should be planned around a subpackage structure from project initiation.

Conversely, if it is a display-only mini program with just three to five pages, generated from a template or low-code tool, with basically no new features added in the six months after launch, then building a full subpackage and preloading system usually is not worth the return. Putting images on a CDN and deleting unused files is enough.

One rule of thumb sums it up: For mini programs with a small total package and infrequent iteration, light resource move-out is enough; only projects that will keep growing and are already at the limit are worth maintaining a subpackage structure as long-term engineering.

FAQ

Is compressing images before uploading enough?

It saves some space, but the payoff has a ceiling. Resolution, format (such as WebP), and whether images are moved to a CDN usually matter more than repeated compression, and compressing too many times degrades image quality.

After subpackaging, will cross-package page navigation break?

With proper configuration, navigation works, but paths must be declared in the subpackage configuration, private files from other subpackages cannot be referenced, and shared logic and shared components must be placed in the main package.

If I use cloud development storage, do images still need to be moved out?

Cloud storage is itself a form of moving resources out. You still need to verify the domain allowlist and permission configuration in sync; if configuration is missed, online image loading will fail.

When upload warns of exceeding the limit, should I delete features or move resources first?

Move resources first. Based on project delivery experience, most over-limit cases are resolved by moving resources out plus reasonable subpackaging; deleting features should be left until all three layers are done.

Does a large package size affect review?

Review generally will not reject you outright because of size, but an oversized package slows first open, which affects judgment of experience-related metrics and indirectly causes problems.

Next step: run a package size analysis first, list the three categories—assets, dependencies, and redundancy—and estimate how much can be cut. If the estimate still leaves you at the limit, then evaluate cutting features or launching in batches. Note that subpackaging and preloading are engineering changes suited to projects with ongoing iteration plans; lightweight mini programs that launch once and then barely change only need resource move-out. Following Xiyue Company's practice in custom mobile delivery, this kind of change is best completed before QA submission, to avoid rework close to launch.