Rule Details

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
export default {
  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 (opens in new tab) 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 (opens in new tab) 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.