前端性能清单之 legacy-js如何停止向现代浏览器投放 ES5 代码与 Polyfill【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist导读本文基于 Front-End-Checklist 仓库中的legacy-js规则展开系统讲解避免向现代浏览器提供遗留 JavaScriptlegacy JavaScript这一性能优化项。你将掌握差异化交付differential serving的 module/nomodule 实现方式、Vite 与 Browserslist 的现代化编译目标配置、Polyfill 的审计方法以及如何用 Lighthouse、PageSpeed Insights 与 DevTools 网络瀑布流验证优化结果。读完本文你可以在自己的构建链路上直接落地一套给现代浏览器发现代代码的优化方案。规则概览legacy-js 是什么在 Front-End-Checklist 仓库中这条规则以两种载体存在一是面向 Agent 的技能文件 skills/legacy-js/SKILL.md二是承载完整规则数据的内容文件 packages/content/rules/en/performance/legacy-js.mdx同时被收录在 docs/generated/rules-catalog.md 的清单中。规则的定义非常明确Detects ES5 polyfills and legacy JavaScript code to reduce bundle size and improve execution检测 ES5 polyfill 与遗留 JavaScript 代码以减小包体积并提升执行性能其核心论断是现代浏览器原生支持 ES6且执行 ES6 代码比执行转译后的 ES5 更快、更高效如果把这些浏览器当作老浏览器对待向它们下发转译后的 ES5 代码和冗余 polyfill就是白白增加了页面重量。该规则在仓库中的元数据标注为属性值分类categoryperformance子分类subcategorymetrics优先级prioritymedium难度difficultyintermediate预估耗时estimatedTime10 分钟数据来源sourcefrontendchecklist.io技能文件的 SKILL.md 还给出了它的适用场景在审计页面加载缓慢、资源过重或渲染延迟时使用并且在提出改动建议前必须先通过 DevTools、Lighthouse 或现场数据field data确认真正的瓶颈所在——这条规则强调的是用数据说话而不是凭感觉优化。Quick Reference三条快速行动要点规则首先给出三条速查要点它们也是整条规则的纲领使用差异化交付module/nomodule分别面向现代浏览器与遗留浏览器投放代码避免为支持 ES6 的浏览器引入重型 ES5 polyfill将代码编译到现代目标modern target从而减小包体积、提升执行速度。这三点分别对应了投送方式依赖策略和编译配置三个层面下文会逐一展开。为什么要避免向现代浏览器下发 ES5 代码原生 ES6 的执行优势绝大多数流量来自原生支持 ES6 的现代浏览器。规则原文明确指出Modern browsers can execute ES6 code faster and more efficiently; serving them transpiled ES5 with polyfills adds unnecessary weight.把类class、箭头函数arrow function等语法转译成 ES5 后浏览器需要解析更多的指令、执行更多的兼容逻辑而现代浏览器可以直接执行原生 ES6 语法解析与执行路径都更短。仓库的完整规则文档 references/rule.md 中将这种差异总结为四个维度的收益包体积Bundle SizeES6 语法往往比转译后的 ES5 更简洁文件更小执行速度Execution Speed现代浏览器执行原生 ES6 特性如 class、箭头函数快于其转译等价物Polyfill 过载Polyfill Overload大量 polyfill 对绝大多数用户完全没有必要只会拖慢体验代码维护Code Maintenance编写和调试现代 JavaScript 远比维护重度转译后的产物容易。转译与 Polyfill 的隐性成本把所有代码转译到 ES5 并给一切特性打 polyfill是过时的做法。它带来三类隐性成本网络成本转译产物更长、polyfill 额外增加请求体积直接推高首屏传输字节数解析/编译成本浏览器需要解析更复杂的 ES5 兼容代码占用主线程 CPU 时间拖慢可交互时间维护成本多层转译引入的 source map 与调试链路问题让线上问题定位更加困难。Check如何检查项目中是否存在多余的 ES5 代码规则的check提示词是Analyze the projects JavaScript output to see if modern browsers are being served unnecessary ES5 code and polyfills.具体检查路径可分为三步查看构建产物目标检查打包器Vite、webpack、Babel 等配置中的target/preset-env/browserslist确认是否把全部用户当成老浏览器处理审查 polyfill 引入方式在产物中搜索core-js、regenerator-runtime、whatwg-fetch等 polyfill 的痕迹确认是否通过useBuiltIns: usage按需引入还是全量注入在真实浏览器中观察用 Lighthouse 或 DevTools 打开目标路由查看是否有legacy-javascript审计项告警以及在网络瀑布流中是否仍下载了 ES5 转换后的 chunk。Front-End-Checklist 规则的前置条件强调先验证瓶颈再提建议。技能文件的 metadata 中专门注明Verify the actual bottleneck in DevTools, Lighthouse, or field data before recommending changes即不要仅凭本地构建输出做判断而要结合真实用户环境的数据。Fix三种落地修复方案规则的fix提示词是Update the build configuration to use differential serving and set a modern target for your primary JavaScript output.下面给出规则文档中的三种具体实现均为可直接复制的配置。方案一HTML 层面的差异化交付Differential Serving差异化交付的核心思想是让现代浏览器加载现代代码让老浏览器加载遗留代码。规则文档给出的 HTML 模板!-- ✅ Good: Serve modern JS to modern browsers, legacy JS to old ones -- script typemodule srcmodern.js/script script nomodule srclegacy.js/script其原理是支持 ES Modules 的浏览器会执行typemodule脚本并忽略nomodule属性而不支持 ES Modules 的老浏览器会跳过typemodule脚本、执行nomodule脚本。这样一份 HTML 就能同时服务两类用户且现代用户永远只下载现代代码。需要注意的是nomodule脚本在现代浏览器中应配合正确构建如将其 polyfill 内联以避免重复执行主流打包器如 webpack 的module/nomodule配置会自动处理这些边界。方案二为 Vite 设置现代编译目标规则文档给出的 Vite 配置// ✅ Good: Targeting modern browsers specifically export default { build: { target: esnext // Or es2020, es2022 } }build.target决定 Vite 对产物进行语法降级的程度设为esnext表示完全不做语法转换产出最大程度保持原貌es2020、es2022等则按 ES 版本边界降级。选型原则是就高不就低——只在你的浏览器支持基线允许的前提下尽可能用高版本目标从而减小转译开销。方案三通过 Browserslist 声明真实浏览器目标规则文档给出的.browserslistrc示例# ✅ Good: Specifying modern browsers to avoid unnecessary polyfills defaults and supports es6-module last 2 versions not dead这段配置表达了三层含义defaults and supports es6-module只针对支持 ES6 模块的默认浏览器集合last 2 versions只覆盖每个浏览器最近的两个大版本not dead排除官方已停止维护的浏览器如 IE。Browserslist 是 Babel、PostCSS、Autoprefixer 等工具共同的浏览器兼容数据源声明一个现代且现实的目标集合后工具链会自动据此决定语法转换与 polyfill 的取舍从而避免给现代浏览器注入用不上的兼容代码。仓库实践参照现代构建链路中的性能取向虽然 Front-End-Checklist 的主站apps/web/next.config.js本身由 Next.js 构建、不直接配置 Browserslist但它的配置集中体现了现代目标 生产环境瘦身的思路可作为同类优化方向的参照// apps/web/next.config.js节选 transpilePackages: [thedaviddias/analytics, frontendchecklist/rules, ...], compiler: { // Remove console.log in production removeConsole: process.env.NODE_ENV production }, images: { formats: [image/avif, image/webp], deviceSizes: [640, 828, 1200, 1920], imageSizes: [32, 64, 128, 256] }其中transpilePackages只对需要转译的 workspace 包做处理、compiler.removeConsole在生产环境剔除调试日志、图片启用 AVIF/WebP 现代格式都体现了只给现代环境发必要的代码与资源这一原则在真实项目中的具体化。你可以对照自己的构建配置检查是否有类似的现代优先设置或是否存在相反的全量 ES5 全量 polyfill策略。Best Practices四条最佳实践规则文档总结了四条可直接执行的最佳实践✅ 使用差异化交付为 90% 的用户投放小而快的代码✅ 设定现实的浏览器目标用 Browserslist 精确定义你需要支持的浏览器集合而不是支持所有浏览器✅ 审计你的 Polyfill使用core-js并开启useBuiltIns: usage只引入实际用到的 polyfill✅ 优先使用原生特性如果只支持现代浏览器直接使用原生fetch、Promise等 API无需任何 polyfill。其中useBuiltIns: usage是 core-js 的按需引入模式Babel 会扫描源码只把实际使用到且目标浏览器缺失的 API 的 polyfill 打进产物避免全量注入导致的体积膨胀。Tools Validation用哪些工具验证规则文档强调在修改构建目标之前先用 PageSpeed Insights 或你的 bundle 报告确认收益——实战收益通常来自确认现代浏览器仍在下载哪些遗留 polyfill 或转译 chunk。Browserslist用于核实实际的现代浏览器目标Polyfill.io当你仍需要选择性支持老浏览器时应谨慎使用Lighthouse可以在路由上标记legacy-javascript审计项Bundle 分析器如vite-bundle-visualizer、webpack-bundle-analyzer用于确认哪些 polyfill 或转换仍占据产物主导地位。Standards衡量标准规则文档给出的测量标准是以最终生产行为为准而非本地合成输出以web.dev: Learn Performance作为衡量最终生产行为的标准以Chrome Developers: Lighthouse overview作为衡量最终生产行为的标准。这意味着优化是否有效要以生产环境真实页面的指标为准而不是看本地构建的输出规模。Verification如何验证改动生效自动化检查在 Lighthouse、PageSpeed Insights 或 DevTools 中测量受影响页面或流程确认目标指标确实改善检查网络瀑布流或性能时间线确认预期的资源或执行变化确实发生。手动检查在节流的移动端配置下验证改动而不只是在本地桌面环境如果该规则对应某个预算budget或 Web Vitals 指标确认页面保持在阈值之内。这两条验证路径与技能的Code Review要求一脉相承审查路由、资源和加载行为对legacy-js的影响精确标记增加不必要网络、CPU 或布局成本的具体文件、请求或渲染步骤并说明用于确认问题的测量方法。在 Front-End-Checklist 仓库中的延伸阅读这条规则并非孤立存在。在 legacy-js.mdx 的 frontmatter 中它与若干相关规则构成performance/metrics领域的关联网络通常会被一起评审duplicate-js.mdx避免重复加载 JavaScript与 legacy-js 同属性能指标领域gtm-present.mdx评估第三方脚本如 GTM的加载影响以及javascript-minificationJS 压缩、css-minificationCSS 压缩等相邻规则。如果想深入这条规则在 Agent 侧的执行方式可以继续阅读 skills/legacy-js/SKILL.md 与其详细实现 references/rule.md如果想了解规则在清单中的完整上下文可查看 docs/generated/rules-catalog.md。整套仓库提供了从规则定义 → 技能执行 → 站点应用的完整链路供你在自己的项目中对照落地。【免费下载链接】Front-End-Checklist The essential checklist for modern web development, for humans and AI agents项目地址: https://gitcode.com/gh_mirrors/fr/Front-End-Checklist创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考