Legacy Js

Avoid serving legacy JavaScript to modern browsers

Modern browsers can execute ES6+ code faster and more efficiently; serving them transpiled ES5 with polyfills adds unnecessary weight.

Quick Reference

• Use differential serving (module/nomodule) to target modern and legacy browsers
• Avoid heavy ES5 polyfills for browsers that support ES6+
• Compile code to modern targets to reduce bundle size and improve execution speed

Check

Analyze the project's JavaScript output to see if modern browsers are being served unnecessary ES5 code and polyfills.

Fix

Update the build configuration to use differential serving and set a modern target for your primary JavaScript output.

Explain

Explain how serving ES6+ code to modern browsers improves performance and why transpiling everything to ES5 is no longer recommended.

Code Review

Review the routes, assets, and loading behavior that affect Avoid serving legacy JavaScript to modern browsers. Flag exact files, requests, or rendering steps that add unnecessary network, CPU, or layout cost, and describe the measurement method used to confirm the issue.

---

For full implementation details, code examples, and framework-specific guidance, see references/rule.md.

Rule page: https://frontendchecklist.io/en/rules/performance/legacy-js

Avoid serving legacy JavaScript to modern browsers

Detects ES5 polyfills and legacy JavaScript code to reduce bundle size and improve execution

Priority: medium · Difficulty: intermediate · Time: 10 min

--- Most web traffic today comes from modern browsers that support ES6+ natively. Transpiling all your code to ES5 and including polyfills for everything is an outdated practice that adds unnecessary weight to your bundles.

Code Examples

#

Differential Serving (HTML)

<!-- ✅ Good: Serve modern JS to modern browsers, legacy JS to old ones -->
<script type="module" src="modern.js"></script>
<script nomodule src="legacy.js"></script>

Modern Target (Vite Configuration)

// ✅ Good: Targeting modern browsers specifically

  build: {
    target: 'esnext' // Or 'es2020', 'es2022'
  }
}

Modern Target (Babel / .browserslistrc)

# ✅ Good: Specifying modern browsers to avoid unnecessary polyfills
defaults and supports es6-module
last 2 versions
not dead

Why It Matters

• Bundle Size: ES6+ syntax is often more concise than transpiled ES5, resulting in smaller files.
• Execution Speed: Modern browsers can execute native ES6+ features (like classes and arrow functions) faster than their transpiled equivalents.
• Polyfill Overload: Many polyfills are completely unnecessary for the vast majority of your users and only serve to slow down the experience.
• Code Maintenance: Writing and debugging modern JavaScript is easier than dealing with heavily transpiled output.

Best Practices

✅ Use Differential Serving: Deliver small, fast code to 90%+ of your users. ✅ Set a Realistic Browser Target: Use browserslist to define exactly which browsers you need to support. ✅ Audit Your Polyfills: Use core-js with useBuiltIns: 'usage' to only include the polyfills you actually need. ✅ Prefer Native Features: If you only need to support modern browsers, use native fetch, Promise, and other modern APIs directly.

Tools & Validation

Use PageSpeed Insights or your bundle report before changing build targets, because the practical win usually comes from verifying which legacy polyfills or transpiled chunks modern browsers are still downloading.

• Browserslist can help verify the actual modern-browser target.
• Polyfill.io should be used cautiously when you still need selective legacy support.
• Lighthouse can highlight legacy-javascript on the route.
• Bundle analyzers are useful when you need to confirm which polyfills or transforms still dominate the shipped bundle.

Standards

• Use web.dev: Learn Performance as the standard for measuring the final production behavior, not just local synthetic output.
• Use Chrome Developers: Lighthouse overview as the standard for measuring the final production behavior, not just local synthetic output.

Verification

Automated Checks

• Measure the affected page or flow in Lighthouse, PageSpeed Insights, or DevTools and confirm the targeted metric improves.
• Inspect the network waterfall or performance timeline to confirm the intended resource or execution change actually took effect.

Manual Checks

• Verify the change on a throttled mobile profile, not just local desktop.
• If this rule maps to a budget or Web Vital, confirm the page now stays within that threshold.