This is a common Lighthouse warning that shows up when your site sends outdated, transpiled JavaScript to browsers that don’t actually need it. Fixing it can meaningfully shrink your JavaScript bundle and speed up page loads, without breaking support for older browsers that genuinely need the extra code.
What the Warning Means
The Legacy JavaScript audit checks whether your website is serving legacy JavaScript to modern browsers that don’t require it, and serving modern JavaScript instead can help your site load faster.
This happens because JavaScript keeps evolving, but browser adoption of new features lags behind. Developers commonly use polyfills or code transforms so they can write modern code while still supporting older browsers’ visitors — Babel is a popular tool for this kind of transformation. The problem is that as browser support catches up, sites can end up sending legacy JavaScript to modern browsers that don’t need it, which hurts performance through unnecessary extra code.
Even though most modern browsers support ES6, many developers still ship code focused on legacy browser support, meaning unnecessary legacy code gets downloaded, parsed, and executed even though the browser has native support for the same features.
How Lighthouse Detects It
The audit scans your JavaScript files looking for two things: polyfills, which are pieces of code that add missing features to older browsers, and transforms, which are changes made to modern JavaScript so it works on older engines.
There’s a useful benchmark for deciding what actually needs a polyfill. “Baseline” refers to a set of browser features that have had cross-browser support for at least 30 months — features at that level generally don’t need to be transpiled unless you specifically know you must support much older browsers.
How to Fix It
Use modern build tools to create separate bundles. Tools like Webpack, Rollup, or Vite can generate one bundle for modern browsers and a separate one for legacy browsers, so each browser only downloads the code it actually needs.
Implement module/nomodule feature detection. This is the most commonly recommended fix across the board. Using <script type="module"> alongside <script nomodule> works well because every browser that supports the module attribute also supports most ES6 features. Modern, capable browsers load the module-tagged script, while older browsers that don’t understand the module attribute fall back to the nomodule version — a practice known as differential serving.
Load polyfills conditionally instead of by default. Rather than bundling every polyfill for every visitor, load them only when a feature-detection check confirms the browser actually needs it.
Update your transpiler’s target configuration. If you’re using Babel, Vite, or a framework like Next.js, check your Browserslist configuration. Setting a modern-only target — like the last two versions of Chrome, Firefox, Safari, and Edge, while excluding IE11 — tells the transpiler to assume broad ES2020+ support and skip unnecessary polyfills and class transforms.
A Note on Framework-Specific Quirks
This warning can be stubborn in certain setups. Developers using Next.js have reported that <cite name=“vercel/next.js”>warnings persist even after adjusting Browserslist settings, often because the bundler still includes legacy support by default through Babel or SWC.</cite> Similarly, some Vite users have found that changing the build target to “esnext” alone doesn’t reduce the resource size, suggesting other parts of the toolchain still need adjusting. If a single configuration change doesn’t clear the warning, it’s worth checking every layer of your build pipeline — the bundler, the framework’s compiler settings, and any third-party libraries that ship their own legacy code.
Should You Even Worry About This?
For most sites today, the vast majority of browsers already support current JavaScript standards, so differential serving is a fairly rare necessity these days. If your analytics show negligible traffic from older browsers like IE11, it may be simpler to drop legacy support in your build config entirely rather than maintaining two bundles.
Join The Discussion
Have you run into this Lighthouse warning on your own projects, and which fix actually worked for you? Whether you’re using Webpack, Vite, Next.js, or something else entirely, share what your Browserslist or build config ended up looking like once you resolved it, and if you found any framework-specific gotchas along the way, that’d be useful for others hitting the same wall.
