Stop Over-Polyfilling: Optimizing Browser Support with @babel/preset-env

The Legacy Browser Burden

Writing modern JavaScript (ES2020+) is a productivity win, but deploying it to a fragmented browser landscape is a technical headache. The traditional approach was to include a massive "polyfill bundle"—a library that adds missing functionality to older browsers—regardless of whether your code actually used those features. This results in bloated bundles and slower load times for users on modern browsers who don't need the legacy code.

The solution is @babel/preset-env. Instead of manually picking plugins, it allows you to define your target environments and automatically determines which syntax transforms and polyfills are required. The goal is to ship the leanest possible code that still functions across your supported browser list.

How Target Resolution Works

preset-env relies on a mapping between JavaScript features and the browser versions that support them. It typically pulls this data from browserslist, a configuration shared across tools like Autoprefixer and ESLint. When you specify a target (e.g., "last 2 versions"), Babel cross-references your code against this list. If you use an async function but target a browser that doesn't support it, Babel applies the necessary transform. If the browser supports it natively, Babel leaves the code untouched, preserving performance.

Strategic Polyfilling with useBuiltIns

Syntax transforms (like converting arrow functions to standard functions) are only half the battle. APIs like Promise or Array.prototype.includes require polyfills via core-js. The useBuiltIns option determines how these are injected:

• entry: You import core-js once at your app's entry point. Babel replaces that single import with a list of specific polyfills required by your target browsers.
• usage: Babel analyzes every file and injects an import for a polyfill only if the feature is actually used in that file. This is the most aggressive way to reduce bundle size.

Implementation Example

To implement this, you need @babel/core, @babel/preset-env, and core-js installed in your project. Below is a configuration targeting an environment that includes legacy browsers like IE11.

File: .babelrc

{
  "presets": [
    [
      "@babel/preset-env",
      {
        "targets": "ie 11",
        "useBuiltIns": "usage",
        "corejs": 3
      }
    ]
  ]
}

Scenario: If your source code contains [1, 2].includes(1), Babel will detect that IE11 lacks Array.prototype.includes. Because useBuiltIns: "usage" is set, Babel will automatically insert import "core-js/modules/es.array.includes.js"; at the top of that specific file during the build process.

Operational Risks and Trade-offs

While useBuiltIns: "usage" is efficient, it has limitations. Because polyfills are injected at the file level, they can sometimes interfere with tree-shaking in certain bundler configurations. Furthermore, if you use third-party dependencies that require polyfills but are not processed by your Babel config (e.g., they are in node_modules), usage may miss them, leading to runtime crashes in legacy browsers.

Verification and Results

To verify your configuration, run the Babel CLI on your source directory:

# Run from project root with necessary permissions
npx babel src --out-dir lib

Check the generated files in /lib. Search for core-js imports to confirm that polyfills are being injected only where needed. To quantify the impact, compare the total size of the /lib folder with useBuiltIns set to false versus "usage". You should see a significant reduction in the final bundle size when targeting modern browsers.