Optimizing Taro H5 Bundle Size with Tree Shaking and ES Module Refactoring

Taro is a multi‑platform development framework that originally bundled all core dependencies (e.g., @tarojs/components and @tarojs/taro-h5 ) into the H5 output, resulting in a first‑screen payload of over 400 KB. Users reported that even an empty project produced bundles larger than 400 KB, and many APIs added unnecessary weight.

Because most H5 applications do not use the entire Taro component set, dead‑code elimination (tree shaking) becomes a primary optimization technique. By analyzing side‑effects and removing unused modules, the bundle size can be cut dramatically.

The optimization steps include:

Ensuring npm packages declare a sideEffects field in package.json so webpack can safely drop modules without side effects.

Using ES6 module syntax throughout the codebase, because webpack’s tree‑shaking works only with static import/export statements.

Running the build in production mode to enable minification and further dead‑code removal via Terser.

For the component library, the original UMD bundle ( dist/index.js , ~462 KB) was replaced by an ES module build, allowing webpack to prune unused components automatically. The same approach was applied to the @tarojs/taro-h5 API package, reducing its bundle from ~262 KB to a fraction of that size.

Because developers typically import Taro with a default import ( import Taro from '@tarojs/taro-h5' ) and then access APIs via property access (e.g., Taro.navigateTo() ), tree‑shaking cannot eliminate unused APIs. To solve this, a custom Babel plugin ( babel-plugin-transform-taroapi ) was introduced. It rewrites specified API calls into named imports, e.g.:

// before
import Taro from '@tarojs/taro-h5';
Taro.setStorage();
Taro['getStorage']();

// after
import Taro, { setStorage as _setStorage, getStorage as _getStorage } from '@tarojs/taro-h5';
_setStorage();
_getStorage();

The plugin receives a configuration object with packageName and a Set of API names to transform, and a Rollup task automatically generates the API list during the build.

After applying these changes, the example project’s bundle shrank from 455 KB to about 96 KB (roughly one‑fifth of the original size), demonstrating the effectiveness of the optimizations.

Future work includes adding support for more high‑demand APIs (e.g., switchTab , onPageScroll , onPullDownRefresh ), unified page transition animations, and a more stable multi‑page mode.