在网络性能方面，有两个主要限制因素会降低您的速度：带宽和延迟。
带宽定义为……
…给定路径上的最大数据传输速率。
一般来说，增加带宽仅在传输或下载大文件时特别有用。如果您正在播放视频，那么2mb?1连接和20mb连接之间的区别肯定会受到赞赏。如果您正在浏览网页 – 大多数页面由更小的文件构成 – 那么带宽的相同变化可能感觉不那么多。
延迟定义为……
…一些数据通过网络从一个节点或端点传输到另一个节点或端点需要多长时间。
在带宽处理容量的情况下，延迟更多地是关于传输速度2。作为一个网络用户 – 通常会传输大量较小的文件 – 减少延迟几乎总是一个值得欢迎的改进。
因此，尽管人们普遍认为，至少对于常规网页浏览而言，延迟是更大的瓶颈3，但仍需要注意延迟或确实是带宽会降低特定文件的速度。
在这篇快速文章中，我想分享一些我在性能研讨会上经历过的devtools小提示：一种快速粗略地确定您的资产是否会从带宽增加或延迟减少中获益最多的简单方法带我到第一点：
使用诸如增加带宽?和减少延迟等短语是一种误称。我们真的没有能力简单地“增加带宽” – 虽然这样会很好！ – 我们真正想做的就是减少转移量。同样，我们无法真正“减少延迟”，但我们可以通过将资产移近客户端（例如cdn）或减轻网络开销（例如使用资源提示）来避免延迟。
使用大请求行为了利用这个小技巧，我们需要在chrome的网络面板中启用large request rows（1）。这将使瀑布图中每个条目的高度加倍，从而显示更多细节（2）。
为什么这不是默认视图，我永远不会知道 – 这里有太多有用的额外信息！
在“?名称”列中：除了查看资源的名称外，我们现在还可以看到其完整文件路径或其域（如果适用）。这使我能够快速，轻松地确定资源是第一方还是第三方。在“?大小”列中：现在我们将看到两个值。顶部较暗的数字是通过电线传输的kb数;?较低，较浅的数字表示持久保存到磁盘的kb数。这两个数字之间的巨大差异表明存在gzip或brotli，或者较小的差异可能显示http标头和cookie的开销。在“?时间”列中：最高值是从分派请求到下载整个响应所花费的总时间。第二个值是在网络协商上花费的时间量（资源调度，连接开销，ttfb）。这个较低的数字实际上是您的延迟。这是我们要关注本文的专栏。在时间栏从请求文件到我们能够开始下载它有很多不同的阶段。一旦发现资源，可能需要安排其传出请求;?浏览器可能需要执行dns查找以确定资源的来源ip地址;?然后我们需要打开到该源的tcp连接;?希望我们正在运行一个安全的连接，这将导致一些tls协商;?一旦我们在服务器上，我们处理时间到第一字节（ttfb）4，其中包括在服务器上花费的时间以及第一个数据字节穿过网络并最终返回到机器上所花费的时间。
这是一项很多工作，对于较小的文件，了解协商所有网络开销通常需要比内容下载本身更长的时间并不令人惊讶。
nb这个瀑布仅仅是一个例子，例如，请不要在这里读取任何实际数字。它仅用于说明目的。让我们再看看上面的截图。专注于第一个条目，即html有效载荷csswizardry.com。在其时间单元格中，您将看到总持续时间为77毫秒，延迟值为74毫秒。从顶部值减去底部给我们3ms。下载此文件只花了3毫秒，但是协商网络需要74毫秒。
换句话说，延迟花费了我们这个资源的带宽24.6倍。到目前为止，这里最大的限制因素是延迟。
换句话说，减小此文件的大小不太可能使其更快到达。这不是我们应该优化其大小的文件。
看看第二个条目masthead-large.jpg。取其总值为113毫秒并减去其延迟（非常微小！）12毫秒，我们将看到花费101毫秒下载此文件。
换句话说，带宽比延迟花费了8.4倍。这是一种资源，其中文件大小的减少将导致更快的交付。
lux.js从speedcurve看下一个条目，我们将看到总时间为78毫秒，延迟时间为77毫秒。只需一毫秒即可下载此文件 – 太棒了！减小它的尺寸确实会产生很小的差异。
最后，看看最后五个图像请求，我们发现它们的所有延迟时间都在140毫秒左右，而下载时间则为2毫秒。如果我想加快这些图像的传送速度，我不太可能通过进一步优化它们获得任何实际收益。
重要考虑因素我用作演示的瀑布就是一个演示。至关重要的是，您要在不同的网络条件下多次运行自己的测试，以评估关键资源的响应方式。
要记住的一个好的经验法则是，对于常规的web浏览，延迟的改进比带宽的改进更有利，并且在处理更大的文件时更多地注意到带宽的改进。