另一个问题是每个请求都有

rmruhul

恒定的延迟假设您请求两个大文件，往返时间为 100 毫秒，下载时间为 250 毫秒，这是 250 毫秒的两倍。如果您乘以 24 个请求，您仍然会遇到恒定的延迟，们将其确定为 100 毫秒，所以现在您的延迟为 2400 毫秒，并且有 24 次……而不是 250 毫秒下载，我们假设它的下载时间为 25 毫秒，实际上需要更长的时间，因为延迟保持恒定，并且您只需将延迟乘以更多请求即可。因此，我会看到那些读过 H2 就是这颗灵丹妙药的客户。他们会分裂……哦！他们无法简化开发过程，我们不需要进行捆绑或串联等等。最终它会变慢，因为你已经设法分散你的请求，这是承诺，但你的延迟保持不变，所以你实际上在浏览器中得到了 n 倍的延迟。就像我说的，在没有视觉效果的情况下试图解释这一点真的很难，可能毫无意义，但与人们希望它能做到的相比，H2 的表现是值得注意的。

德鲁：分片过程是否还有好处，好吧，获取全部数据仍然需要相同 电报号码数据 的时间，但是当你在 24 日获得第一个分片的 100% 时，你就可以开始处理它并开始执行24号之前就结束了。

哈利：哦，伙计，另一个好问题。所以，绝对地，如果事情进展顺利，并且它确实以更像 H1 的响应表现出来，那么这个想法将是文件一首先返回，然后返回两个、三个、四个，然后它们可以按照到达的顺序执行。因此，您实际上可以通过确保事物同时到达来缩短总时间。如果我们查看网页而不是瀑布，并且您注意到请求是交错的，那就是坏消息。因为正如我所说，JavaScript 文件的 10% 是无用的。

哈利：如果服务器正确地完成其工作并且发送、发送、发送、发送、发送，那么它会变得更快。然后，您的缓存策略就会变得更加精细，从而带来连锁反应。所以真正烦人的是你更新日期选择器小部件上的字体大小。在 H1 世界中，您必须缓存大约 200 千瓦的站点宽 CSS。而现在，您只需缓存bust datepicker.css。所以我们有这样的分支利益，这绝对是非常有价值的。

德鲁：我想，在您神奇地立即返回所有请求的情况下，这显然会使客户端陷入困境，不是吗？

哈利：是的，有可能。然后实际发生的情况是客户端必须进行大量的资源调度，因此您最终会得到一个瀑布，其中所有响应同时返回，然后您在响应之间会有相当大的差距最后到达的响应及其执行能力。因此，理想情况下，当我们谈论 JavaScript 时，您希望浏览器按照请求顺序（基本上是您定义它们的顺序）请求所有这些内容，服务器以正确的顺序返回所有内容，以便浏览器可以执行它们按正确的顺序排列。因为，正如你所说，如果它们都同时返回，你就需要立即运行大量 JavaScript，但仍然需要对其进行调度。因此，您可能会对文件到达和变得有用之间长达一秒的时间产生怀疑。所以，实际上，H1…我想，理想情况下，你所追求的是 H2 请求调度、H1 风格的响应，这样当事情到达时就可以变得有用。



德鲁：所以你基本上是在寻找一个看起来可以滑下来的响应瀑布。

哈利：是的，完全正确。德鲁：但你不需要降落伞。

哈利：是的。这真的很困难……我想大声说出来听起来真的很微不足道，但考虑到 H2 的销售方式，我发现它相当……没有挑战性，因为这让我的客户听起来……很愚蠢……但这需要解释一下对他们来说……如果你想想 H1 是如何运作的，那就没那么糟糕了。如果我们得到类似这样的回复，“哦，是的，我现在可以看到它了”。我以前曾教过性能工程师这一点。做我所做的事情的人。我必须告诉性能工程师，我们不会太在意何时发出请求，我们真正关心的是响应何时变得有用。