Optimizing Build and Dependency Installation for Dada's Large-Scale Frontend System

Dada Express, a leading instant‑delivery platform in China, operates a massive backend system whose frontend codebase has grown to about 260,000 lines and involves roughly 20 developers. Frequent releases require a four‑step pipeline—code merge, build, gray‑release, and full rollout—taking about 25 minutes, with the build stage alone consuming roughly 10 minutes.

Problem : The lengthy build time caused low front‑back collaboration efficiency, long waiting periods for feature releases, and often forced developers to work late into the night.

The original build workflow showed that both the dependency‑installation phase and the webpack compilation phase were major time consumers.

Optimization – Dependency Installation

The project uses yarn for package management. During yarn install four steps are executed, and a large amount of time is spent copying node_modules from the system cache to the project directory. By creating a cache pool of pre‑built node_modules directories on the build server and reusing them across builds, the install time could theoretically drop to 1‑2 seconds. However, the original copy command cp -r did not preserve file timestamps, causing the cache to become invalid and the install to fall back to a full 100‑second duration.

Replacing cp -r with cp -a preserved timestamps, reducing the install step from about 100 seconds to roughly 2 seconds.

Optimization – Packaging & Compilation

The frontend uses webpack and babel . Key webpack configuration items such as entry , output , resolve , module , devtool , loader , and plugin were reviewed. Loaders include css-loader , style-loader , and babel-loader . Plugins such as define-plugin , ignore-plugin , commons-chunk-plugin , uglifyjs-webpack-plugin , and hot-module-replacement-plugin were listed.

Babel’s cacheDirectory option enables caching of transformed files. In the original setup, differing node_modules paths across environments caused the cache key to change, invalidating the cache and forcing recompilation.

To fix this, the team standardized the node_modules path inside each Docker container (e.g., /data/node_modules ) and mounted the same host directory into every container, then created a symlink to the project’s code directory. This ensured a consistent cache key and restored Babel cache effectiveness.

Additional optimizations included:

Eliminating duplicate dependency bundles.

Adopting micro‑frontend architecture to split the project.

Removing unused resolve.extensions entries.

Replacing third‑party SCSS imports with CSS to cut Sass compilation time.

Offloading large libraries (e.g., moment , UI components) to CDN.

Disabling source maps for production builds (planned async builds).

Removing the IgnorePlugin after extracting moment to CDN.

After implementing these measures, the average build time dropped from roughly 600 seconds to about 100 seconds, significantly improving development velocity.

Conclusion

Through collaborative effort between Dada’s frontend team and cloud platform engineers, systematic caching, command adjustments, and webpack/Babel tuning achieved a dramatic reduction in build duration, demonstrating the impact of targeted performance engineering on large‑scale frontend projects.