什么是 TTFB, 为什么 TTFB 很重要

什么是TTFB
揭开 TTFB 的神秘面纱

我正在为客户做一个电子商务的网站，对性能方面要求较高，简单的说就是对页面加载时间有要求。页面图片加载速度有多快，取决于开始渲染的时间。所以，什么时间开始渲染就显得很重要。

Time to First Byte(TTFB) 是一个前端开发人员很容易忽略的指标，因为它即将进入后端领域。不过，据我了解，
一个快的 TTFB 不一定意味着你会有一个快速的网站，但一个慢的 TTFB 一定会意味着网页慢。

作为前端开发者，你可能没有能力独自对 TTFB 进行改进。但你必须要知道，高 TTFB 的问题会影响页面性能。你做的其他优化，比如优化图片、清除关键路径、异步加载网页字体这些努力都会受到影响。
所以你应该优先消灭那些 TTFB 带来的问题，而不应该忽略 TTFB 对页面性能的影响。

什么是 TTFB？

TTFB 的时间线不是很明显，查看大图/质量（375kb）

TTFB 包含了许多不同的东西，但由于具体细节不好分别描述，因此我们经常会忽略它。很多人以为 TTFB 是花销在服务器端的时间，这其实只是其中很少的一部分而已。

不知道大家注意到没有，TTFB 计算的是整个延迟的往返时间。 TTFB 不仅仅是服务器上花的时间，它还包括从我们设备到服务器，再从服务器到设备的时间。（没错，这才是真正的 TTFB。）

有了这个知识，我们就能理解为什么 TTFB 在移动设备上的增长异常显著。你可能会这样想，服务器根本不知道我在使用移动设备，怎么会增加 TTFB 呢？移动网络通常都有高延迟连接。如果你的往返时间（RTT），从您的手机到服务器再返回到手机，花销了250ms，那么你就会立即看到 TTFB 时间有增加。

读完本文后，我希望你能记住一句话。TTFB 会受到延迟的影响。

那 TTFB 究竟包含了哪些东西呢？下面是一个详尽无遗的列表，顺序无先后。

延迟:如上所述，我们计算的是从服务器接收到请求到再到发出后的时间。伦敦的一台设备请求纽约的一台服务器，理论上最理想的环境，光纤速度是28毫秒，但实际情况可能接近75毫秒。这就是为什么我们要使用 CDN 的原因:即使在互联网时代，在地理位置上离你的客户更近也是有优势的。
路由: 如果您正在使用 CDN ーー而且您应该这样做! ーー利兹的一个客户可能会被路由到 MAN 数据中心，结果发现他们请求的资源不在那个 PoP 的缓存中。因此，它们将被路由到您的原始服务器，然后从那里检索它。所以如果你的源服务器是在弗吉尼亚州，将大幅增加 TTFB 的时间开销。
文件读取：服务器只是从文件系统读取静态文件，如图像或系统表，都是有代价的。这些都会被计算到你的 TTFB 时间中。
优先级: HTTP/2 有一个(重新)优先级机制，它可以选择在服务器上停止较低优先级的响应，同时发送较高优先级的响应。撇开 H/2 优先级问题不谈，即使 H/2 运行顺利，这些预期的延迟也会给你的 TTFB 带来影响。
运行时: 运行时需要时间是显而易见的，所以这可能是 TTFB 时间开销中占比较重的。
数据库查询: 页面如果需要获取来自数据库的数据，那么在对数据库进行检索时将会产生时间成本，增加 TTFB 时间。
API 调用: 如果您需要调用任何 API (内部或其他)来填充页面，开销将计入您的 TTFB。
服务器端渲染: 服务器渲染一个页面的成本可能是微不足道的，但它仍然会增加你的 TTFB 时间。
廉价的托管服务器: 如果托管服务器的成本高于性能，那通常意味着你要与其他网站共享一个服务器，服务器性能会降低，可能会影响你接收请求的能力，也可能在运行应用程序时出现硬件供电不足。
DDoS 或高负载: 与上一点类似，增加负载而无法自动扩容的应用程序会达到硬件基础设施的极限，进而导致性能大幅下降。
WAFs 和负载均衡器: 诸如 web 应用程序防火墙或负载均衡器之类的服务放在你的应用程序之前也会对你的 TTFB 有所拖累。
CDN 的特点: 尽管 CDN 是一个解决网络请求问题的重要方案，但在某些情况下，他们可能会增加 TTFB 时间。例如，请求折叠、边缘端包含等)
最后一英里延迟: 当我们想到伦敦的一台计算机访问纽约的一台服务器时，我们想象一下，如果我们暴力点，让两者是直接连接，行不行？事实上，从我们自己的路由器到我们的 ISP (互联网服务提供商) ，有一系列更加复杂的中介，从手机信号塔到海底电缆。最后一英里延迟处理的是到达连接终点前无法比拟的复杂连接。

0 延迟的 TTFB 是不可能存在的！所以我们需要注意的是，以上列表任意项不好，不代表会使得 TTFB 时间增加。但你看到的 TTFB 时长包含了上面各项内容。在这里我不单独介绍某一项内容，只是介绍下这些都会影响到你的 TTFB 时长。所以现在想想，网页加载成功简直是太厉害了，堪称奇迹。

嗯，这部分就到这里了。

揭开 `TTFB` 的神秘面纱

现在是不是更加了解 TTFB 了？我们可以花时间开发一个工具，在chrome 开发者工具的网络请求中来显示服务器时间Api。帮助我们识别和调试潜在的性能问题。

Server Timing API 允许开发人员在响应报头中查看的 Server-Timing HTTP 的数据，该报头包含应用程序测量自身的计时信息。

这正是去年我们在 BBC iPlayer 所做的:

Server-Timing Header 可以添加进任何响应头中。查看全部

注意: 服务器计时不是浏览器自带的: 您需要实际测量上面列出的每一项，然后用相关数据填充服务器计时头。浏览器所做的只是在相关工具中显示数据，使其在前端可用:

[外链图片转存失败(img-W8B4r5N9-1569294463933)(https://csswizardry.com/wp-content/uploads/2019/08/screenshot-ttfb-iplayer.png)]
在浏览器中，我们可以看到 TTFB 详细的花销内容。 [查看全部]（https://csswizardry.com/wp-content/uploads/2019/08/screenshot-ttfb-iplayer-full.png)

为了帮助你去实现这个功能，Christopher Sidebottom 在我们优化 iPlayer 的时候写了他的服务器计时 API) 的实现。

理解 TTFB 对于性能提升工作是很重要的。TTFB 会有连锁反应，它的时间开销的长短会直接影响到页面性能。

如果你跑出大门时速度慢了，你将在剩下的比赛中追赶上来。

原文地址：https://csswizardry.com/2019/08/time-to-first-byte-what-it-is-and-why-it-matters/