Latência
Performance Web
Otimização
Cache
Engenharia

减少 Web 应用程序的延迟:解决正确瓶颈的快速指南

通过首先解决最大的瓶颈来解决延迟,而不是凭直觉传播优化。

减少 Web 应用程序的延迟:解决正确瓶颈的快速指南

如果您已经到达这里,您可能已经知道什么是延迟并希望采取行动。本文不会花费您的时间再次定义该概念。对于任何需要加快 Web 应用程序速度并希望以正确的顺序进行操作,而无需花费数周时间进行无济于事的优化的人来说,这都是一本实用指南。

组织接下来的一切的规则只有一个:首先解决最大的瓶颈。延迟集中。在典型的应用程序中,一两个步骤占据了大部分等待时间。找到并解决这些问题比分散的几十个小调整更有价值。

让我们从通常伤害最大的部分到通常伤害最小的部分。根据您的实际情况调整顺序,但前提是在测量之后。

始终从测量开始

跳过这一步是代价最高的错误。如果没有测量,你就会在黑暗中进行优化,并且在错误的地方搞砸的可能性很高。

在接触任何代码之前,请检测请求。你需要知道在服务器上花费了多少时间,在查询数据上花费了多少时间,在网络上花费了多少时间,以及在浏览器渲染上花费了多少时间。 [后端的可观察性0工具和浏览器开发人员工具提供了足够的入门信息。

还要查看分布,而不仅仅是平均值。最坏情况下的延迟(处于不良百分位的用户)是产生投诉和放弃的原因。可接受的平均时间可以掩盖人们遭受痛苦的长尾。考虑到这条尾巴进行优化。

数据库往往是罪魁祸首

在大多数随着时间的推移而变慢的应用程序中,瓶颈在于查询。值得从这里开始。

典型的嫌疑是没有合适索引的查询。随着表的增长,对一千条记录的即时搜索变得对数百万条记录来说是一种拖累。识别慢速查询并添加正确的索引通常是最高回报的优化。

第二个嫌疑点是按顺序执行许多查询的模式:应用程序搜索列表,并针对每个项目触发一个新查询。有 10 件物品需要去银行 11 次;一百项变成一百零一项。通过一次性获取所有数据来解决这个问题,将慢速页面变成快速页面,而无需更改任何其他内容。

三是带来过多数据的查询。当您使用三列时请求所有列,或者引入数千行来显示二十列,都会在每一层上浪费时间。仅订购您将使用的产品。

缓存:最强大也是最危险的捷径

缓存是最能减少延迟并引入最微妙错误的工具。有目的地使用。

这个想法很简单:保存昂贵操作的结果,以免重复。变化很少且被大量读取的数据(目录、配置、公共页面)都是完美的候选者。从缓存提供服务消除了数据库查找和大部分处理。

危险在于失效:确保数据更改时更新缓存。为旧信息提供服务的缓存会产生难以诊断的问题,因为系统“正常工作”,但它是错误的。在添加缓存之前,决定如何使其失效。如果您不知道如何回答这个问题,那么您还没有准备好这样做。

分层缓存

卷曲的地方不止一处,而且它们加在一起。在浏览器中,可以保存静态资源,以免再次下载。在 CDN 中,可以从物理上靠近用户的点提供内容。在服务器上,昂贵操作的结果可能保留在内存中。每一层都会减少总延迟的一部分。

缩短距离并重用连接

部分延迟是纯粹的物理因素:用户和服务器之间的距离。你无法超越光速,但你可以缩短路径。

CDN 将您的内容副本放置在靠近访问者的地方。对于巴西观众来说,从该国的存在点而不是远程服务器提供服务可以缩短旅行时间,而这是任何代码优化都无法恢复的。对于静态内容和媒体,这是最佳的努力获胜比率之一。

重复使用连接也可以节省成本。打开新的安全连接需要花费网络往返费用;保持连接活跃并使用现代协议可以减少这种重复成本。这是一个优点,尤其出现在发出许多请求的页面上。

缓解浏览器压力

即使使用快速服务器,屏幕也只会在浏览器处理响应后才会出现。最后一部分值得关注。

常见的罪犯是众所周知的。过多的 JavaScript 会减慢页面加载速度。大图像未经压缩或尺寸错误。充电时遮挡显示屏的功能。减少和推迟对第一个屏幕来说不重要的内容可以使应用程序看起来很快,即使它仍在完成其余部分的加载。

感知与数字同样重要。尽早显示有用的内容,即使是部分内容,也会让用户感受到速度。两秒钟的空白屏幕比立即显示结构然后完成它的屏幕更糟糕。

在这里也值得应用相同的比例逻辑。在以性能的名义重写整个组件之前,请确认您要攻击的部分是出现在第一个屏幕上的部分。通常,最大的收获来自于推迟加载次要的东西,而不是重写主要的东西。

优化无害的错误

值得在任何诚实的性能指南结束时发出警告:不要优化不可见的部分。人们很容易爱上一段优雅的代码,并花费数天时间节省无人注意到的毫秒时间,而真正的瓶颈仍然完好无损。

始终返回测量。每次优化后,再次测量并确认用户感觉的数字确实有所改善。如果没有改善,那么你优化了错误的东西。绩效是一个比例游戏,谦逊地衡量才能避免浪费。

结束

减少延迟并不是魔法或技术英雄主义。这是一种方法:测量,找到最大的瓶颈,解决它,再次测量。数据库、缓存、距离和浏览器是最浪费时间的地方,而且几乎总是问题集中在其中之一。

速度是伪装成工程任务的产品决策。有条不紊地对待它的团队交付的应用程序尊重用户的时间,并花费更少的精力来解决以后的性能问题。

如果你现在从事这份工作,首先要从测量开始。博客上还有其他关于架构、缓存和可扩展性的文章,深入探讨了这些要点。

另请阅读

  • [Web 应用程序中的延迟:每个团队都需要了解的基础知识11
  • [应用程序中的缓存:良好实践快速指南(及其隐藏的错误)2
  • 【应用中的电池消耗:比较和快速指南3
  • [面向初学者的渐进式 Web 应用程序:示例和优化,而不使事情复杂化4
  • [初创公司的 PWA:渐进式 Web 应用程序是正确的选择5
  • [PWA:它是什么以及如何每天处理性能6