「Gmail滚动时大概只有5帧，但数十亿人每天照样用。」这句话像一盆冷水泼在所有追求极致性能的开发者头上。

我们花了无数个深夜优化渲染管线，却可能搞错了一件事：用户真的在乎吗？

打开网易新闻 查看精彩图片

「快」是美德，还是幻觉？

工程师圈子里有种默契的信仰：慢应用=坏应用=懒惰的开发者；快应用=好应用=有匠心的手艺人。

这套道德评判体系根深蒂固。但现实数据在打脸。

Gmail帧率感人，Slack吃内存像在吃自助餐，Jira每次加载都像宇宙热寂前的最后挣扎。这三款产品各自坐拥数亿用户，是各自品类的绝对领导者。

更讽刺的是替代品的命运轨迹。每当主流应用被吐槽卡顿，就会出现「极速版」挑战者——开发者论坛一片欢呼，基准测试截图满天飞，然后……停在几千用户规模，再也涨不动。

速度导向的替代方案，市场成功率极低。不是速度完全不重要，而是相对于分发渠道、生态集成、用户习惯、品牌信任这些因素，它的权重被严重高估。

一个团队已经在用Google Workspace，攒了三年的Jira历史数据，迁移成本才是决策核心。性能可能是打破平局的筹码，但前提是先打成平局。

空建筑里的奖杯抛光师

作者见过太多团队——他自己也曾是其中之一——把整个迭代周期烧在提升Lighthouse分数上，而产品实际用户几乎为零。

这个过程很舒服：数字在涨，图表变绿，成就感满满。但作者给这种行为下了定义：这不是工程匠心，是工程自恋。

「你 literally 在空无一人的大楼里抛光奖杯柜。」

这句话的杀伤力在于精确。性能优化成了安全区，一个可以量化、可以展示、可以自我感动的舒适区。而真正的硬仗——找到产品市场契合点、构建分销网络、说服企业客户迁移—— messy、不可控、没有即时反馈。

开发者论坛里常有争论：成功应用本质上是「被容忍的垃圾」吗？作者认为这个框架本身就是错的。它们不是垃圾，而是在性能上做到「足够好」，同时在真正驱动采纳的因素上做到卓越。

用户如何真正体验你的产品

关键洞察：用户不是通过Lighthouse审计来交互的。

他们是在试图完成某项任务时与你的应用相遇。如果工作流解决了他们的问题，他们会容忍不够流畅的滚动。他们会抱怨，但会继续用。200毫秒的额外加载时间？在解决核心痛点的价值面前，这笔账很容易算。

这不是说性能无关紧要。作者明确划出了三条红线：

电商结账流程——每100毫秒延迟与转化率下降直接挂钩；实时工具如视频编辑器或交易平台——延迟本身就是产品；新兴市场的3G移动网络——物理约束无法妥协。

这些是真实的性能关键场景。但作者指出，绝大多数开发者并不在做这类应用。

性能文化的真正成本

把性能当作道德 virtue 的副作用，是资源错配。早期创业公司最稀缺的是时间和注意力，却被吸入优化 rabbit hole。成熟期公司则可能在已经满足用户需求的环节过度投资，而忽视真正的增长杠杆。

更隐蔽的成本是团队心智模式的扭曲。当「快」成为无条件优先项，产品决策会被技术审美绑架。用户研究让位于基准测试，业务指标让位于性能指标。

Gmail的案例之所以刺痛，是因为它打破了「性能-成功」的线性叙事。一个5帧的邮件客户端统治市场十年，说明用户投票的维度远比帧率复杂：搜索精度、垃圾邮件过滤、存储空间、与日历文档的深度整合、企业采购的惯性、数据迁移的摩擦成本。

这些都不是 Lighthouse 能测量的。

给你的检查清单

下次准备投入性能优化前，作者的建议是诚实回答三个问题：

你的产品属于那三类性能关键场景吗？用户规模是否值得这笔投资？还是你在用技术舒适区逃避更难的问题？

如果答案指向后者，停下来。去和用户聊聊他们为什么留下，为什么离开。去算清楚获客成本和生命周期价值。去搞清楚为什么销售周期是三个月而不是三周。

性能优化永远是手段，不是目的。当手段成为目的本身，你就成了空建筑里的奖杯抛光师——技艺精湛，观众为零。

真正的好产品，是在对的地方足够好，而不是在所有地方追求完美。