. , . — , . — , , , , ( , , ). , . : « ?». .
, , , - . (Time to First Byte, TTFB). , TTFB, , , . , , : « TTFB , , TTFB ».
, - , TTFB, , TTFB . -, , . , , , , , -. , , , . TTFB , , , . , , , TTFB, , , .
什么是TTFB？
TTFB看起来信息不多（ 全图 ）TTFB是一个看起来不透明的指示器。 他的影响如此之大，以至于我感到我们一直都在掠夺他的认真分析。 许多人认为TTFB只是服务器准备响应所花的时间，但实际上，这只是影响TTFB的一小部分。
我要引起您注意的第一件事是，在学习到人们通常会感到非常惊讶的东西之后。 我们正在谈论一个事实，即TTFB包括来自客户端的请求通过网络到达服务器的时间，以及将服务器响应路径传递给客户端的时间。 这就是所谓的“往返时间”（往返时间，RTT）。 TTFB不仅仅是服务器准备响应所花费的时间。 这也是花费在数据从客户端到服务器以及从服务器到客户端的路径上的时间（当然，此数据包含我们感兴趣的“第一个字节”）。
现在，有了这些知识，我们就可以轻松理解为什么从移动设备查看站点时，TTFB指示器通常只是大得令人讨厌。 在这种情况下，很可能您会问过这样的事情：“我确定服务器不知道我正在通过移动设备查看网站。 那它如何增加TTFB？” 其原因是，通常，移动网络连接是高延迟连接。 如果RTT指示器（例如，反映数据从电话到服务器往返传输所需的时间）为250毫秒，则TTFB将增加相应的值。
如果我希望本书的读者仅从中吸取一个主要想法，那么我可以将这个想法表述为：“网络延迟会影响TTFB。”
还有什么影响TTFB？ 实际上-很多东西。 这远不完整是什么构成了此指标的清单。 此列表中的项目是随机顺序的。
- 网络延迟。 如前所述，TTFB包括将请求传递到服务器并从服务器返回响应所花费的时间。 以位于伦敦的设备与位于纽约的服务器之间的数据交换会话所需的时间为例。 理想情况下，使用光纤连接时为28 ms。 但这是基于许多非常乐观的假设。 实际上，您应该期望75毫秒左右的时间 。 这就是使用CDN如此重要的原因。 即使是现在，在Internet时代，某些企业及其客户在地理上的接近也是一个优势。
- 路由选择 如果您使用CDN（应该是这样！），那么您的客户请求（例如，来自利兹的请求）只能重定向到MAN数据中心，因此结果是，客户需要的资源不在相应的PoP缓存中。 然后，该请求将随您的资料一起重定向到真实的服务器，以便将其所需的内容传输给客户端。 例如，如果此服务器位于弗吉尼亚州，则上述所有原因都会导致TTFB的严重增加，而没有明显原因。
- 处理文件。 即使服务器仅从其文件系统中读取静态数据（例如图像或样式文件），也需要花费一些时间来完成此操作。 这次也是TTFB的一部分。
- 优先次序 HTTP / 2协议具有用于优先处理请求的机制。 结果，可能会导致低优先级请求在服务器上被延迟，而让位于高优先级请求。 即使您没有考虑HTTP / 2优先级排序机制，并假设一切运行顺利，这些预期的延迟也可能导致TTFB。
- 运行应用程序。 实际上，这很明显，但是我想指出，运行服务器应用程序所需的时间会严重影响TTFB。
- 数据库查询。 如果您需要从数据库请求某些内容来形成页面，那么完成此类操作的时间也将包含在TTFB中。
- API调用 如果需要来自某些API（内部或外部）的数据来准备页面，则对这些API的调用将影响TTFB。
- 服务器渲染 很明显，服务器端渲染需要时间，这个时间很容易估算，但这并不能抵消此操作对TTFB的贡献。
- 廉价托管。 如果您使用廉价的主机，试图尽可能节省并牺牲性能，这通常意味着许多其他项目都在使用项目所在的服务器。 也许相当可观。 结果，使用廉价主机的人可能会认为服务器性能会下降，这可能会影响项目处理请求的能力。 实际上，我们在谈论服务器硬件的功能不足以满足应用程序需求这一事实。
- DDoS攻击，项目负担沉重。 在这里，我们继续该列表的上一段中讨论的主题。 即，如果服务器上的负载增加，并且该项目无法提供灵活的服务器容量扩展，则导致设备开始达到极限的事实。 结果，应用程序性能下降。
- WAF，负载均衡器。 位于服务器应用程序前面的WAF或负载平衡器之类的服务会增加TTFB。
- CDN的某些功能。 使用CDN无疑会对TTFB产生有益的影响，但是CDN的某些功能可能会使情况变得更糟。 例如，这是请求折叠 ， ESI等。
- 在“最后一英里”处延误。 当我们谈论伦敦的一台计算机访问位于纽约的服务器时，我们通常会简化这种情况，几乎将其简化为计算机与服务器直接连接的事实。 但实际上，一切都更加复杂。 计算机和服务器之间的信号通过许多中介。 我们的路由器将其发送给提供商； 通过无线网络，他进入了铺设在海底的电缆。 “最后一英里”的延迟包括了在终端设备之间进行数据传输的所有困难。
0毫秒的TTFB是梦dream以求的事情。 因此，需要注意的是，列表中没有任何东西总是对TTFB产生负面影响或使该指标恶化。 最好将此列表理解为对项目TTFB结构的描述。 我的目标不是批评某些技术，而是展示某些技术如何影响TTFB。 而且，老实说，考虑到在客户端从服务器接收到响应的第一个字节之前发生了多少事情，这些站点通常正在加载已经令人惊讶。
揭秘TTFB
现在，希望TTFB不再看起来那么神秘。 而且，如果您花一些时间在API
Server Timing的实现上，则可以开始测量棘手的服务器时间指示器并将其发送到客户端系统。 这将使Web开发人员能够检测并消除以前看不到的潜在性能瓶颈。
Server Timing API允许开发人员使用可选的
Server-Timing HTTP标头扩展查询响应。 它包含由应用程序本身测量的时间信息。
去年，我们在BBC iPlayer上使用的正是这种机制。
可以将新的Server-Timing标头添加到任何答案中（ 全尺寸图片 ）
请注意，“服务器定时”也会给系统带来压力。 在其工作过程中，您需要测量相关指标并填写
Server-Timing标头。 浏览器仅允许前端开发人员使用适当的工具查看此数据。
现在，在浏览器中，您可以看到TTFB结构（ 全图 ）如果要实现Server Timing API，请查看
此资料 。
总结
网站开发人员必须了解TTFB在多大程度上影响他们所谓的“网站性能”，这一点非常重要。 越过第一个字节的时间是一个特定的边界，我们可以讨论网站优化。 该指标越低越好。
亲爱的读者们！ 您是否使用TTFB优化您的Web项目？
