polyfill-nomodule.js flagged in new experimental-analyze tool despite modern-only browserslist — related to #86785?

[zephyratech]

Summary

I'm running Next.js 16.3.0 (App Router, Turbopack) with a browserslist targeting only modern browsers, but Lighthouse still flags ~13.5 KiB of "Legacy JavaScript" on every route. Using the new next experimental-analyze command, I confirmed the source is polyfill-nomodule.js (Next.js's built-in polyfill file), not my own code or dependencies.

I believe this is the same underlying issue as #86785 and #64330, where next-polyfill-module ships unconditionally regardless of browserslist config, and is only skipped at runtime via the nomodule attribute rather than excluded at build time.

Is there a recommended way to build-time-exclude this for teams who've deliberately scoped browserslist to modern-only browsers? Or is this confirmed as expected/unfixable behavior for now?

Additional information

browserslist (package.json):
"browserslist": [
  "chrome >= 120",
  "edge >= 120",
  "firefox >= 121",
  "safari >= 17.4",
  "ios_saf >= 17.4",
  "not dead",
  "not op_mini all"
]

`npx browserslist` output confirms this resolves correctly — Chrome 120+, Firefox 121+, Safari 17.4+ only, no legacy targets.

Lighthouse "Legacy JavaScript" audit flags:
Array.prototype.at, Array.prototype.flat, Array.prototype.flatMap,
Object.fromEntries, Object.hasOwn, String.prototype.trimStart, String.prototype.trimEnd
— all Baseline-supported well below my target browser versions.

`next experimental-analyze` confirms the source directly:
polyfill-nomodule.js
38.51 KB compressed / 109.96 KB uncompressed
Polyfill
Next.js built-in polyfills

next info output: [run `npx next info` and paste it here — I don't have your environment, so I can't generate this for you]

Example

No response

[barry166]

There isn't a supported build-time opt-out for this today. The browserslist setting affects the browser target for emitted code, but the built-in legacy polyfill is still copied into the build and rendered as a noModule script; the docs' "only load these polyfills for browsers that require them" is implemented by that noModule gate, not by pruning the file from buildManifest per browserslist.

So your reading is right: a modern-only browserslist will not remove polyfill-nomodule.js, and #86785 is the right issue to track for a config/behavior change. For now I would treat it as a legacy/noModule asset in analyzer budgets or filter it out separately; stripping it from the build means carrying an unsupported Next patch.

[satiricalguru]

This is indeed expected current behavior in Next.js, and you are spot on that it stems from the same architectural limitation tracked in #86785 and #64330.

---

Why this happens despite a modern browserslist

1. Decoupled Polyfill Bundling:
   Next.js compiles and emits polyfill-nomodule.js as a static, pre-packaged bundle designed to be referenced by the root HTML template via <script nomodule>. While browserslist config controls the SWC/Turbopack transpilation targets for your application code and dependencies, it does not currently conditionally disable the generation or HTML injection of the static nomodule fallback asset.

2. Why Lighthouse Flags It (False Positive in Real-World Impact):
   Lighthouse and bundle inspection tools run static pattern matching across all script tags and generated build chunks. Because polyfill-nomodule.js contains ES5 shims (core-js, Array.prototype.flat, Object.fromEntries, etc.), Lighthouse triggers the "Legacy JavaScript" warning.

   However, in real-world modern browser traffic (Chrome 120+, Safari 17.4+, Firefox 121+), the browser's HTML parser sees <script nomodule> and completely ignores the script — it is neither downloaded nor parsed/evaluated at runtime.

---

Is there a build-time exclusion today?

• In App Router: There is currently no official config flag (e.g. experimental.disableNomodulePolyfills) to completely suppress polyfill-nomodule.js from the build output, as the document injection is managed by Next.js's internal layout renderer.
• In Webpack (Pages Router workaround): Historically, teams used custom Webpack plugins to filter out the polyfills entrypoint, but with Turbopack in App Router, this entrypoint is handled internally.

Summary / Next Steps

Your audit and breakdown are accurate. At runtime for modern browsers, this causes zero performance degradation because of the nomodule attribute, but it does create noise in static bundle audits. Upvoting #86785 is the best course of action so the Next.js/Turbopack team can add an opt-out flag or automatically omit the fallback when browserslist targets are strictly modern.