性能测试和商业模式：缓慢代价高昂的真实案例

缓慢很少会导致系统瘫痪。她的表现更糟：她默默地耗尽了业务，从不发出警报。

系统故障会产生事件、会议、立即采取行动。不是一个慢系统。它继续“工作”，可用性图表变成绿色，没有人注意到，每多等待一秒，一小部分用户就会放弃、放弃购物车或干脆不再回来。损害确实存在，但在有人测量之前是看不见的。

性能测试可以在这种损失成为一种习惯之前让其变得显而易见。而且，与普遍看法相反，它不是一个孤立的工程问题，它是技术和收入之间最直接的联系之一。我想用真实的案例来展示这一点，而不是理论。

性能是伪装成技术指标的业务指标

响应时间似乎是服务器的事情。事实上，它是人类行为的决定因素。人们对等待缺乏耐心，每种商业模式都以不同的方式感受到这种不耐烦。

性能测试测量响应时间、效率和使用中的系统行为。负载测试的区别是焦点之一：负载询问“它可以处理多少个？”，性能询问“它响应多快？”，通常已经在一定负载下，因为一个用户的速度和一千个用户的速度是不同的事情。

我想说的是，这个技术指标应该被理解为一个业务指标。不是“页面在 X 秒内加载”，而是“每等待一秒，我们就会失去 Y% 的转化者”。这是相同的信息，翻译成任何人决定的语言。

研究最多的案例是数字零售。速度和转化之间的关系是最一致的关系之一：更快的页面转化更多，而且下降很早开始，不是在十秒内，而是在几秒钟内。

残酷的细节是最慢的地方：结账时。这是购买意愿最大、脆弱性最大的时候。购物车需要很长时间才能响应，“最终确定”按钮似乎被卡住了，而且实际上已经结束的销售也消失了。更糟糕的是：用户会感觉该网站“不起作用”，并将这种不信任带到下一次。

在这里，性能测试是值得的。从字面上看，衡量和优化购买流程的响应时间就是在恢复默默损失的收入。这不是技术上的改进；而是技术上的改进。这是现金泄漏修正。

在订阅产品中，性能会影响较少的即时转化和较高的保留率，而在循环模型中，这就是金钱所在。

每天使用该工具的用户都会反复感受到每次速度变慢。屏幕多花三秒不会立即降低使用率，但会削弱质量感知。当更新到来时，或者当“更快”的竞争对手出现时，累积的摩擦会影响留下或离开的决定。

这里真正反复出现的情况是产品功能增加但速度下降。每个新功能都添加了一个查询、一个负载、一个权重。个别的，难以察觉的；此外，该产品的速度很慢。定期进行性能测试可以在这种逐渐下降的情况成为取消的原因之前发现它。

在公共部门，绩效具有私营部门所没有的一个维度：机会公平。

缓慢的服务门户并不会平等地将每个人赶走。那些网络连接不好、设备陈旧或对数字技术不太熟悉的人恰恰是最受速度缓慢之苦的人，而且往往是最依赖该服务的人。一个只能在快速互联网和新手机下才能正常运行的系统完全排除了公共服务应优先考虑的人群。

真实的情况是基本服务、日程安排、福利、文档，这些服务在技术上是“实时的”，但在实际使用条件下速度非常慢，以至于在实践中变得无法访问。在现实场景中进行的性能测试，模拟适度的连接和设备，揭示了可用性数字隐藏的这种无声的排除。

在所有这些情况下，都有一个共同的陷阱：相信平均值。平均响应时间是最具误导性的统计数据之一。

良好的平均值可以忍受糟糕的尾巴。如果大多数用户加载速度很快，但 5% 的用户等待很长时间，则平均值看起来不错，而相关部分的用户体验很差。这个部分往往是最敏感、最糟糕的连接、使用高峰、极端数据情况。

因此，在性能测试中，我会关注高百分位数，即最坏情况下的体验，而不是平均值。这就是放弃、取消和排斥的根源。优化平均值让数字变得漂亮；优化尾部恢复业务。

最常见的战略陷阱是将性能留到最后，“首先我们让它发挥作用，然后我们优化”。问题是，当“稍后”到来时，缓慢已经植根于难以逆转的架构决策。

性能是整个开发过程中选择的结果，而不是最后的调整。持续的性能测试是发布过程的一部分，可以随着产品的发展控制速度。仅在发布前一天进行测量才能在修复成本最高的时候发现问题。

结束是我提倡的优先级倒置：将响应时间视为具有所有者和目标的产品功能，而不是基础设施细节。因为归根结底，性能是对使用你产品的人时间的一种尊重，而用户会通过转化、保留和信任来回报这种尊重。

如果您怀疑速度缓慢会导致您的产品收入损失，并且没有人给出具体数字，那么这种衡量方式往往会让双方都感到惊讶。我在博客上还有其他关于性能、转换和体验的文章，这些文章更深入地探讨了该主题。