2024 年的 JavaScript 膨胀

原文 ↗ Hacker News 讨论 ↗

现代网站即使是相对简单的页面，也经常发出数 MB 的 JavaScript——从较精简的约 1–3 MB，到 Gmail、Figma 和 Jira 这类服务的 10–60 MB 不等。评论者认为，这种膨胀源于沉重的框架、糟糕的代码分割、第三方追踪以及组织激励，并指出压缩和缓存无法解决 CPU、内存和电池成本，尤其是在低端设备或慢速连接上。有些人认为，对于富交互的网页应用来说，只要初次加载后导航够快，大包体是可以接受的；而另一些人则以轻量站点和零依赖做法为例，证明更高效的设计完全可行。

标题大小对比与意外之处

  • 评论者强调了巨大的 JS 负载：Gmail 和 Figma 约 20 MB，YouTube 约 12 MB 的 JS + 2.5 MB 的 CSS，Jira 约 58 MB，一些落地页“只是为了显示文本和图片”就有好几 MB。
  • 色情网站（例如 Pornhub）被反复提及为相对精简（约 1–1.4 MB），尽管它们以媒体内容为主。
  • 几位开发者提到自己复杂的应用只有 1–4 MB，却对更大公司的产品能发出 10–50 MB 感到困惑。

压缩、解析与设备限制

  • 关于查看压缩后还是未压缩大小的争论：压缩能减少传输，但不能降低解析/执行成本。
  • 人们特别指出，较旧和低端的 Android 设备最受大体积包和繁重 DOM 工作的影响。
  • 也有人认为仅看大小只是一个粗略指标；性能分析显示，DOM 渲染、布局、低效响应式和瀑布式请求往往占主导。

膨胀来源：SPA、框架与追踪

  • 许多人把责任归咎于 SPA 框架以及过度工程化的架构，把简单网站变成了应用。
  • 另一些人说，大量字节其实来自分析、标签管理器、A/B 测试和客服小组件，这些通常由营销团队推动，有时甚至在没有开发人员监督的情况下被注入。
  • 第三方追踪脚本本身就可能达到数 MB，而且通常从外部 CDN 加载。

用户体验：对有些人很快，对另一些人却不可用

  • 反馈不一：有人觉得 YouTube、GitHub、Discord 等“很流畅”；也有人看到明显卡顿和冻结，尤其是在中老旧硬件或移动端上。
  • 处在受限连接环境中的人（农村、漫游、2 Mbps，或每月 15 GB 之类的低流量上限）表示，许多现代网站在没有拦截器时几乎不可用。
  • 对 Spotify 和 Gmail 这类应用在离线/网络差时的体验批评很多。

争论：大包体真的有问题吗？

  • 一方观点： “少 JS = 更好” 是一个有用的经验法则；对基础 UI 来说 10–50 MB 明显是浪费，并伤害中位数用户。
  • 另一方观点：在“正常”网络条件下成本是可以接受的；与其追逐包体指标，不如优化整体 UX（缓存、应用内快速导航）。
  • 也有人认为，我们应该修复缓存/PWA 和平台问题，而不是执着于 KB 级别的数字。

方法论批评与细微差别

  • 多条评论指出文章中的测量问题：
    • 只看冷启动和未压缩大小。
    • 禁用缓存会夸大重复下载（例如 React 文档沙盒）。
    • 一些“看起来静态”的页面其实是多工具 webapp 的入口（例如 Outlook、Translate）。
  • 也有人反驳说，即便考虑这些注意事项，数量级差异和真实世界的卡顿仍表明膨胀问题确实存在。

替代方案、工具与实践

  • 建议的缓解措施包括：代码分割、懒加载、虚拟列表、避免不必要的 DOM 节点，以及包分析工具（例如 Webpack/Rollup 分析器）。
  • 一些人主张零依赖或最小依赖方案、HTMX/PJAX 风格导航，或更新的“可恢复”框架（例如 Qwik）。
  • 一个反复出现的强烈主题是：组织激励（营销、开发速度）倾向于不断堆叠 JS；性能几乎没有拥护者。