第一字节的时间。它是什么以及为什么它很重要

我目前正在为一个客户项目工作，由于他们是一个电子商务网站，我很想为他们研究很多方面的性能：加载时间是一个好的开始，开始渲染对于那些想快速看到信息的客户来说是很关键的（提示：那是所有的客户），以及客户特定的指标，如关键产品图片的加载速度如何？都能提供有价值的见解。

然而，我觉得前端开发者很快就忽略了一个指标，那就是_到达第一个字节的时间_（TTFB）。这是可以理解的–几乎是可以原谅的–当你考虑到TTFB开始进入后端领域时，但如果让我尽可能简洁地总结一下这个问题，我会说。

虽然一个好的TTFB不一定意味着你会有一个快速的网站，但一个坏的TTFB几乎肯定会保证一个慢的网站。

尽管作为一个前端开发者，你可能无法自己对TTFB进行改进，但重要的是要知道，任何高TTFB的问题都会使你处于劣势，而你为优化图像、清除关键路径和异步加载你的网页字体所做的任何努力都将是为了追赶。这并不是说应该放弃更多面向前端的优化，但不幸的是，有一种马后炮的感觉。 你真的想尽快解决那些TTFB的错误。

什么是TTFB？

TTFB的计时条目并不特别有见地。查看完整大小/质量 (375KB)

至少可以说，TTFB是一个有点不透明的东西。它由许多不同的东西组成，我常常认为我们倾向于掩盖它。很多人猜测TTFB仅仅是在服务器上花费的时间，但这仅仅是事情真实程度的一小部分。

我想提请大家注意的第一件事，也是最令人惊讶的一件事是，TTFB计算了整个往返的延迟。 TTFB不仅仅是在服务器上花费的时间，它也是我们从设备到服务器再返回的时间（携带，这是正确的，第一个字节的数据！）。

掌握了这些知识，我们很快就能理解为什么TTFB在移动端经常会急剧增加。你肯定会想，服务器根本不知道我在用移动设备，它怎么可能增加TTFB呢？原因是，移动网络通常是高延迟连接。如果你从手机到服务器再返回的往返时间（RTT）是250ms，你会立即看到TTFB的相应增加。

如果说我很想让你从这篇文章中得到一个关键的东西，那就是TTFB受到延迟的影响。

但还有什么是TTFB呢？请注意，这里有一个非详尽的清单，没有特定的顺序。

• **延迟。**如上所述，我们计算的是去往服务器的旅程和从服务器返回的旅程。从伦敦的设备到纽约的服务器，理论上的最佳速度是28ms，但这是非常乐观的假设。期望接近75毫秒。
  • 这就是为什么从CDN提供内容是如此重要：即使在互联网时代，在地理上更接近你的客户是有利的。
• **路由。**如果你使用CDN–你应该这样做！–一个在利兹的客户可能会被路由到MAN数据中心，但却发现他们所请求的资源不在该PoP的缓存中。因此，他们会一路被送回你的原点服务器，从那里获取资源。如果你的原点在弗吉尼亚州，这将是一个巨大的、看不见的TTFB的增加。
• **文件系统的读取。**服务器简单地从文件系统中读取静态文件，如图片或样式表，是有代价的。这一切都会被添加到你的TTFB中。
• 优先权。HTTP/2有一个（重新）确定优先级的机制，它可以选择在服务器上停滞低优先级的响应，而将高优先级的响应发送到线下。撇开H/2的优先级问题不谈，即使H/2运行顺利，这些预期的延迟也会对你的TTFB产生影响。
• **应用程序的运行时间。**这其实是很明显的，但是运行你的实际应用程序代码所需的时间将对你的TTFB有很大的影响。
• **数据库查询。**需要数据库数据的页面在搜索时将产生成本。更多的TTFB。
• **API调用。**如果你需要调用任何API（内部或其他）来填充一个页面，其开销将被计入你的TTFB。
• 服务器端渲染。服务器渲染一个页面的成本可能是微不足道的，但它仍然会贡献给你的TTFB。
• **廉价主机。**为成本而不是性能而优化的主机通常意味着你与任何数量的其他网站共享一个服务器，因此预计服务器性能会下降，这可能会影响你满足请求的能力，或者可能只是意味着试图运行你的应用程序的硬件功率不足。
• **DDoS或重负载。**与上一点类似，在没有办法自动扩展你的应用程序的情况下，增加负载将导致性能下降，你开始探索你的基础设施的极限。
• **WAFs和负载平衡器。**诸如网络应用程序防火墙或负载平衡器等位于你的应用程序前面的服务也将有助于你的TTFB。
• CDN功能。尽管CDN是一个巨大的净赢，但在某些情况下，它们的功能可能会导致额外的TTFB。例如，请求折叠，边缘侧包括，等等）。)
• **最后一英里的延迟。**当我们想到一台在伦敦的计算机访问纽约的服务器时，我们往往会把这个过程过度简化，几乎可以想象这两者是直接相连的。现实情况是，从我们自己的路由器到我们的ISP，从手机塔到海底电缆，有一系列复杂得多的中间环节。最后一英里延迟处理的是连接终点处的不相称的复杂性。

不可能有0ms的TTFB，所以重要的是要注意，上面的列表并不代表一定是坏的东西，或使你的TTFB变慢。相反，你的TTFB代表了上述项目中的任何数量。我在这里的目的不是要指责堆栈的任何特定部分，而是要帮助你理解TTFB到底会带来什么。在我们的TTFB阶段有这么多潜在的事情发生，网站能够加载几乎是一个奇迹

所以。很多。的东西!

揭开TTFB的神秘面纱

值得庆幸的是，这一切都不再是那么不清楚了!通过实施服务器计时API的一点点额外工作，我们可以开始测量并将复杂的计时信息浮现在前端，使网络开发人员能够识别和调试之前被遮蔽的潜在瓶颈。

服务器计时API允许开发者用一个额外的Server-Timing HTTP头来增加他们的响应，其中包含应用程序自己测量的计时信息。

这正是我们去年在BBC iPlayer所做的事情。

新提供的Server-Timing 标头可以被添加到任何响应中。查看完整大小/质量 (533KB)

注意：服务器计时不是免费的：你需要自己实际测量上面列出的方面，然后用相关数据填充你的Server-Timing 标头。浏览器所做的只是在相关工具中显示数据，使其在前端可用。

现在我们可以在浏览器中看到，我们的TTFB的某些方面花了多长时间。查看完整尺寸/质量 (419KB)

为了帮助你入门，Christopher Sidebottom在我们优化iPlayer的过程中写了他对服务器计时API的实现。

我们必须了解TTFB能涵盖哪些内容，以及它对整体性能有多重要。TTFB会产生连锁反应，这可能是一件好事，也可能是一件坏事，这取决于它的起点是低还是高。

如果你一开始就很慢，你就会在剩下的比赛中追赶。