How to Slash Frontend Bundle Size: Babel, Polyfills, Tree‑Shaking & Duplicate Dependency Fixes

Why Bundle Size Matters

Even as network speeds improve, larger JavaScript bundles increase load time, memory usage, and trigger more frequent V8 garbage‑collection cycles, which can degrade page interactivity.

Babel Polyfill Strategies

Babel is primarily used for API and syntax down‑leveling. The generated code often includes core‑js polyfills, which can inflate bundle size.

core‑js with @babel/preset‑env

Using @babel/preset‑env allows automatic insertion of only the polyfills required for the browsers defined in browserslist. The useBuiltIns option controls the insertion mode:

entry : Add import 'core-js' at the top of the entry file; all possible polyfills are bundled, leading to a large core‑js payload (≈50 KB gzipped).

usage : Babel scans the source code and injects polyfills only for the APIs actually used, reducing size but risking missing polyfills for third‑party modules that are not compiled.

When usage is chosen, developers must ensure that dependencies in node_modules are also transpiled, otherwise runtime errors may occur.

@babel/runtime for Syntax Helpers

Repeated use of class, async, etc., generates duplicate helper functions (e.g., createClass) in each module. Installing @babel/plugin-transform-runtime replaces these inline helpers with imports from @babel/runtime, allowing reuse across modules and shrinking the bundle.

However, this approach depends on all dependencies correctly referencing @babel/runtime; otherwise, some packages may still bundle their own helpers.

Tree‑Shaking

Tree‑shaking removes unused exports from ES modules. To enable it:

Ensure packages expose an module field pointing to an ESM build.

Set sideEffects: false in package.json (or list files that have side effects, such as *.css).

Keep ES module syntax in Babel output by configuring { "presets": [["@babel/preset-env", { "modules": false }]] }. This prevents conversion to CommonJS, which would break static analysis.

Side‑effect declarations are essential for assets like CSS, which introduce runtime side effects even though they export nothing.

Duplicate Dependencies

When two versions of the same library are installed (e.g., [email protected] and [email protected]), both may be bundled, increasing size and potentially causing conflicts. Resolve by aligning version ranges and deduping with tools such as npm dedupe or find-duplicate-dependencies, then verify with webpack-bundle-analyzer.

Best‑Practice Build Pipeline

Combine the above techniques in a unified build system:

Use a company‑wide @company/app-builder to drive the application build.

Delegate dependency builds to @company/module-builder, which applies a shared Babel config ( @company/babel-base) that disables core‑js API down‑leveling and enables the polyfill.io service for on‑demand polyfills.

Enable @babel/plugin-transform-runtime in @company/babel-base to extract syntax helpers.

Configure module-builder to preserve ESM syntax so that app-builder can perform effective tree‑shaking.

This engineering approach reduces bundle size across the entire codebase, from the application itself to internal shared libraries.

Conclusion

Reducing bundle size requires coordinated effort: selective polyfill insertion, runtime helper extraction, proper tree‑shaking configuration, and vigilant dependency management. When these practices are applied consistently across both application and internal packages, the final build can be dramatically smaller and more performant.

References

https://docs.npmjs.com/cli/v8/commands/npm-dedupe

https://babeljs.io/docs/en/babel-plugin-transform-runtime

https://babeljs.io/docs/en/babel-preset-env

https://babeljs.io/docs/en/babel-polyfill

https://webpack.js.org/guides/tree-shaking/#root

https://cdn.polyfill.io/v3/