Serve Modern JavaScript to Modern Browsers: How to Fix It

What this audit means

Modern browsers understand current JavaScript syntax: arrow functions, classes, async/await, spread operators, and more. For years, build pipelines transpiled all of that down to ES5 and bundled in polyfills so the code would run on old browsers like Internet Explorer 11. The problem is that this transpiled output is usually served to every visitor, including the modern browsers that never needed it.

Lighthouse (the engine behind SEO ProCheck's performance grade) detects this by scanning your scripts for telltale patterns left behind when modern code is rewritten for old browsers. It uses a database of known polyfill signatures and counts the helper patterns that appear when modern classes and syntax are downleveled. If even one of those unnecessary polyfills or transforms is present, the audit flags the page.

Why it matters

Transpiling modern syntax to ES5 makes JavaScript files bigger. A class written in three lines can expand into dozens of lines of helper code, and polyfills for features the browser already has add even more weight. The browser still has to download, parse, compile, and execute all of it.

That extra work lands on the main thread, the same thread that handles user input. Bloated bundles push out interactivity and hurt your Interaction to Next Paint (INP), while the download and parse cost slows first render. On mobile devices with slower CPUs, the penalty is larger. Trimming legacy code is one of the cleaner wins available because it removes work without removing functionality.

How it gets flagged

Lighthouse looks at the JavaScript your page actually serves and matches it against known legacy patterns, such as polyfills for features that have been baseline-supported for years and the transform helpers emitted when classes or generators are compiled down. When it finds these in scripts delivered to a modern context, it reports them under "Avoid serving legacy JavaScript to modern browsers" along with the estimated wasted bytes. SEO ProCheck surfaces the same finding inside your performance report.

How to fix it

1. Set a modern browserslist target

Most transpilation behavior is driven by your browserslist config. If it still targets ancient browsers, your tooling will downlevel everything. Tighten it so the build assumes modern engines. A common modern query:

// .browserslistrc or package.json "browserslist"
> 0.5%
last 2 versions
not dead
supports es6-module

With Babel's @babel/preset-env, this target tells it to skip transforms and polyfills the supported browsers no longer need. Pair it with useBuiltIns: "usage" and a pinned corejs version so only the polyfills your code truly references are included, instead of the whole library.

2. Use the module / nomodule pattern

If you still need to support legacy browsers, ship two builds. Every browser that supports <script type="module"> also supports modern ES6+ syntax, so modern browsers load the lean module bundle and old browsers fall back to the transpiled one:

<!-- Modern browsers load this and ignore nomodule -->
<script type="module" src="/js/app.modern.js"></script>

<!-- Legacy browsers load this and ignore type="module" -->
<script nomodule src="/js/app.legacy.js"></script>

Build tools like Vite, Webpack, and Rollup can generate both bundles automatically. Vite's legacy plugin, for example, emits the modern build by default and adds the nomodule fallback only when configured.

3. Drop unnecessary polyfills

Audit what you actually import. Blanket polyfill imports and dependencies that bundle their own core-js are common culprits. Remove polyfills for features that are baseline across your target browsers, and prefer libraries that publish modern ES module builds. The goal is a modern build that contains no ES5 helper boilerplate at all.

False positives

Not every flag is your own code. Third-party scripts, ad tags, analytics, embeds, and chat widgets often ship their own transpiled-and-polyfilled bundles, and you cannot rebuild them. These will keep triggering the audit even after your first-party JavaScript is clean. Treat them separately: defer or lazy-load them where possible, and verify the flagged file's URL before spending effort. Some frameworks (for instance certain Next.js or Nuxt versions) inject a small fixed polyfill set that you may not be able to fully strip; in those cases the realistic target is your application code, not the framework runtime. Reducing first-party legacy code is also a natural companion to minifying your JavaScript.

FAQ