Web 膨胀如何影响使用慢设备的用户

原文 ↗ Hacker News 讨论 ↗

对 Web 膨胀的感知原因

  • 沉重的客户端框架、SPA 模式、庞大的 JS 包以及无限滚动界面被认为是导致网站即使在现代硬件上也会变慢、卡顿的原因。
  • 由营销驱动的附加内容（tag manager、分析、AB 测试、追踪器、广告、Cookie 横幅）被认为是 payload 和 CPU 使用量的主要来源，而且往往没有被计入。
  • “过早优化是万恶之源”被认为被广泛滥用，用来为永远不优化辩护。
  • 一些人认为，硬件改进和浏览器自动更新让开发者对性能和向后兼容性变得自满。

对慢设备和糟糕网络的影响

  • 许多人表示，主流网站（社交媒体、Substack、Reddit 新 UI、YouTube、Amazon、航空订票、银行、政府网站）在低端 Android、老款 iPad、廉价笔记本，甚至 2010 年代中期的 Mac 上已经接近不可用。
  • 问题不仅出现在弱 CPU 上，也出现在受限流量套餐以及高延迟/低带宽连接上（农村 DSL、火车/航班 Wi‑Fi、漫游）。
  • 无限滚动、沉重的 DOM 和广告脚本会导致崩溃、卡死和巨大的流量消耗；一些用户不得不改用纯文本工具或替代前端。

商业激励与“谁重要”

  • 一种观点认为：公司会优化面向新 iPhone 和高速连接的用户；每台 50 美元手机上的穷用户“赚不到钱”，因此不会优先支持他们。
  • 其他人反驳说，这忽视了在富国和穷国中，使用旧设备或中端设备的真实付费用户，并且低估了全球不平等。
  • 有人说，从收入角度看，膨胀是合理的（更快推出功能、更多分析、“勾选框”功能），即使用户体验因此变差。

开发者文化、工具与责任

  • 讨论焦点在于，膨胀主要是管理层/营销压力造成的，还是因为开发者不了解或不重视效率。
  • 框架生态和以 DX 为先的文化让发布沉重代码变得很容易；之后再清理则很困难，而且很少被安排。
  • 跟踪脚本可以通过 tag manager 在开发者控制之外被添加，但人们仍认为开发者有责任去反对或设计更轻量的架构。

例子与反例

  • 轻量网站（HN、简单论坛、静态博客、某些电子邮件服务、像 McMaster 这样的部分电商）被称赞为证明快速且功能齐全的网站是可能的。
  • 采用简单主题的 WordPress 往往比 Medium/Substack 这类时髦平台表现更好。
  • 老派论坛和极简主义/原始风格的 HTML 经常被提为正面范例。

可能的缓解措施与替代方案

  • 建议包括：语义化 HTML + 渐进增强、服务器端渲染、静态站点、更小的 JS 和 CSS、用分页替代天真的无限滚动，以及广告拦截或 DNS 拦截。
  • 有些人建议系统化的“生态开发”：始终在低端设备和慢网络上测试，把回归当作 bug 处理。
  • 还有人提到远程浏览器、Opera-Mini 风格的代理、WASM，以及原生的“recycler”组件可能是技术方向，不过其实用性存在争议。

更广泛的担忧

  • 一些人将膨胀与电子废弃物和 CO₂ 联系起来，认为这是迫使用户升级硬件所致，但其确切气候影响仍有争议。
  • 还有人担心，关键服务（政府、医疗、福利、教育）变得臃肿后，实际上会把更贫困和技术能力较弱的用户排除在外。