Web 应用程序的延迟：每个团队都需要了解的基础知识

速度是用户在能够解释之前感受到的少数产品特征之一。没有人打开一个网站并认为“这里的延迟很高”。人们只是觉得事情进展缓慢，他们变得不耐烦并离开。延迟是不可见的，直到它变成放弃。

对于那些开始深入研究网络性能的人来说，第一个困惑是将延迟视为“慢速互联网”的同义词。它不是。延迟是指一个操作和对该操作的响应之间的时间，它是由一系列远远超出用户连接范围的因素构成的。了解这个链条是将发起优化的人和从源头上解决问题的人区分开来的。

这篇文字是一个基础。我们的目标不是提供秘诀，而是为您提供词汇和心理模型，以便清楚地推理延迟，因为如果不了解延迟的来源，任何优化都会变成反复试验。

事实上，什么是延迟

延迟是等待时间。当有人单击按钮并且服务器上需要发生某些事情时，单击和可见响应之间会存在延迟。这个间隔就是感知的延迟，它是几个更小的时间的总和。

将延迟与吞吐量分开非常有用，这两个概念经常被混淆。延迟是单个请求花费的时间。吞吐量是系统每秒可以处理的请求数量。你可以同时拥有一个高吞吐量和高延迟的系统，它为很多人服务，但每个人都在等待。对于个人用户来说，重要的是延迟。对于操作而言，两者都很重要。

本文的中心论点是：**延迟是步骤的总和，而您只能改进您所看到的内容。**任何将延迟视为单个不透明数字的人都会陷入通用优化的困境。谁打破了这条链条，谁就会发现时间真正浪费在哪里。

想象一下典型请求的路径，从用户单击到屏幕上的响应。这条路径的每一段都会增加时间。

存在物理距离。信息以有限的速度在网络上传输，用户和服务器之间的距离很重要。另一个大陆上的服务器在进行任何处理之前，仅在往返过程中就增加了数十毫秒。对于由远程基础设施服务的巴西公众来说，这是问题的真正组成部分。

连接已建立。打开安全连接涉及客户端和服务器之间的初始协商，该协商需要通过网络进行往返。重新调整用途的连接只需支付一次此费用；每次新连接都会付费。

服务器上有处理。应用程序理解请求、查询数据库、执行业务逻辑和组装响应所花费的时间。这是团队可以直接控制的大部分延迟所在。

有数据查询。数据库往往是最大的隐藏恶棍。索引不良的查询、连续触发数十个其他查询的调用、链中缓慢的外部服务，所有这些都会将快速响应变成等待。

还有浏览器内渲染。即使响应到达后，浏览器也需要对其进行处理并绘制屏幕。繁重的 JavaScript、阻塞资源和大图像会增加最后一部分的时间，就在用户正在查看的地方。

人们很容易将延迟视为一个工程问题。这是管理失误。延迟对转化、保留和质量感知有直接影响。缓慢的应用程序被放弃，并且放弃不请求许可。

想想公共服务门户。试图发放副本、安排预约或咨询福利的公民没有无限的耐心，并且经常通过连接程度较低的手机访问这些信息。如果每个步骤都需要时间，那么完成率就会下降，面对面的服务就会膨胀，并且“政府系统不起作用”的感觉就会强化。在这种情况下，延迟是获取权利的障碍。

在私人产品中，逻辑在另一个名称下是相同的：每一秒的等待都是金钱的流失。这就是为什么延迟不应成为仅在用户抱怨时才出现的问题。它应该是一个像监控收入一样被监控的指标。

了解延迟的人最常犯的错误是在测量之前开始优化。你在这里添加缓存，在那里重写一个函数，所有这些都是凭直觉进行的，结果是分散的精力，没有明显的影响。

正确的纪律则相反。首先衡量时间浪费在哪里，然后解决最大的瓶颈。延迟通常分布不均匀：单个步骤可能占总时间的大部分。优化别人是浪费。

不仅值得关注平均情况，而且还值得关注最坏的情况。平均延迟可能看起来很长，而相关部分用户则经历了长时间的等待。正是这些用户，那些处于不良百分位的用户，放弃并抱怨。对于许多人来说，良好的平均值可能掩盖了可怕的经历。

性能热情的另一面也存在风险：优化不重要的东西。兴奋的团队花了数周时间在用户从未注意到的部分上节省了几毫秒，而最长的等待仍然完好无损。

性能始终是一个比例问题。减少只占总时间一小部分的步骤并不会改变体验。成熟在于抵制优雅优化的诱惑，首先要问它是否移动了用户感受到的数字。

另一个陷阱是将延迟视为经过一轮改进后解决的问题。系统不断发展，数据不断增长，新功能不断增加呼叫。如果没有人注意，延迟会再次增加。这是一个需要持续监控的指标，而不是一项需要划掉的任务。

延迟是每个 Web 应用程序都要缴纳的无形税款，而用户才是感受到这笔帐单的人。了解它的基本原理，了解它是一系列步骤的总和，了解它在优化之前进行衡量，了解它对业务和工程的重要性，是构建人们不会因为不耐烦而放弃的产品的第一步。

速度既不是奢侈品，也不是技术细节。这是您的产品做出的承诺的一部分。那些将性能视为产品决策而不是最后一刻调整的人，可以提供尊重屏幕另一端用户时间的体验。

如果您开始更认真地考虑应用程序的性能，那么从一开始就进行测量是值得的。博客上还有其他有关架构和可扩展性的文章，更深入地探讨了该主题。