TTFB对前端的重要性

虎·馆

2020-06-01 (Updated: 2020-06-01)

前端性能

简介

Time to First Byte(TTFB)是前端开发人员很容易忽略的指标，因为在现实的开发中我们经常会忽略他的重要性。不过，据我了解，TTFB对前端性能来说不一定是一个最重要的指标，但TTFB时间过长一定会意味着网页性能差。

作为前端开发者，你可能没有能力独自对 TTFB 进行改进。但你必须要知道，TTFB时间过长的问题会影响页面性能。你做的其他优化，比如异步加载网页字体、前端性能优化这些都会受到影响。所以你应该优先解决TTFB带来的问题。

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

TTFB 计算的是整个延迟的往返时间。 TTFB 不仅仅是在服务器上花费的时间，还包括设备请求发送到服务器，再从服务器返回到设备的时间。

TTFB 会受到延迟的影响。

那 TTFB 究竟包含了哪些东西呢。

如上所述，我们计算的是从服务器接收到请求到发出响应的时间。比如：伦敦的一台设备请求纽约的一台服务器，在理想的情况下，通过光纤仅需要28毫秒，但实际情况可能会接近75毫秒。这就是为什么我们要使用 CDN 的原因:即使在互联网时代，在地理位置上离你的客户更近也是有优势的。

如果您正在使用 CDN ，他们请求的资源不在 PoP 的缓存中时，客户可能会被路由到源数据中心。因此，请求路由到原始服务器，然后从那里检索它。将大幅增加 TTFB 的时间开销。

服务器只是从文件系统读取静态文件，如图像或系统表，都是有代价的。这些都会被计算到你的 TTFB 时间中。

HTTP 有一个优先级机制，它可以选择在服务器上停止较低优先级的响应，同时发送较高优先级的响应。撇开 H2 优先级问题不谈，即使 H2 运行顺利，这些预期的延迟也会给你的 TTFB 带来影响。

运行时需要时间是显而易见的，所以这可能是 TTFB 时间开销中占比较重的。

页面如果需要获取来自数据库的数据，那么在对数据库进行检索时将会产生时间成本，增加 TTFB 时间。

如果您需要调用任何 API (内部或其他)来填充页面，开销将计入您的 TTFB。

服务器渲染一个页面的成本可能是微不足道的，但它仍然会增加你的 TTFB 时间。

如果托管服务器的成本高于性能，那通常意味着你要与其他网站共享一个服务器，服务器性能会降低，可能会影响你接收请求的能力，也可能在运行应用程序时出现硬件供电不足。

与上一点类似，增加负载而无法自动扩容的应用程序会达到硬件基础设施的极限，进而导致性能大幅下降。

诸如 web 应用程序防火墙或负载均衡器之类的服务放在你的应用程序之前也会对你的 TTFB 有所拖累。

CDN 的特点: 尽管 CDN 是一个解决网络请求问题的重要方案，但在某些情况下，他们可能会增加 TTFB 时间。例如，请求折叠、边缘端包含等

最后一英里延迟: 当我们想到伦敦的一台计算机访问纽约的一台服务器时，我们想象一下，如果我们暴力点，让两者是直接连接，行不行？事实上，从我们自己的路由器到我们的 ISP (互联网服务提供商) ，有一系列更加复杂的中介，从手机信号塔到海底电缆。最后一英里延迟处理的是到达连接终点前无法比拟的复杂连接。

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

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

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

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

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

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

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

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

Happy Hacking~