Time To First Byte通常用于测量Web服务器响应请求的速度,而且公共Web测试服务会报告该请求。(理论上)响应的越快Web服务器越好。但理论并不是很完善。

维基百科将Time To First Byte 定义为“从虚拟用户发出HTTP请求到浏览器接收到页面的第一个字节的持续时间”。但是,流行的网页测试网站实际报告的究竟是什么的结果呢?为了找到答案,我们创建了一个测试服务器,在HTTP响应中插入延迟,用以找出实际测量的内容。令人吃惊的是,TTFB并不是一个有效的衡量指标。

当Web浏览器向Web服务器请求页面时,它会发送请求本身以及一些请求头,这些请求头指定了响应的可接收格式之类的内容。服务器响应以更多的请求头(包含有关页面的信息),后附带有状态行(通常是HTTP / 1.1 200 OK表示页面可用),最后才是页面内容。

CloudFlare的TTFB测试服务器的行为略有不同。当它收到请求时,它会发送HTTP / 1.1 200 OK(H)的第一个字母,然后等待10秒钟,然后再发送其余的请求头和页面本身。(你可以在这里获取TTFB服务器的代码;它是用Go编写的)。

如果你用WebPageTest从CloudFlare TTFB服务器下载页面,你就会发现 WebPageTest报告的TTFB为接收到H的时间(而不是页面本身实际发送的时间),从十秒的等待时间你就很容易可以看出这一点。

gomez也报告了完全相同的数字。

报告的TTFB不是接收到页面的第一个数据字节的时间,而是HTTP响应的第一个字节到达的时间。这两者是很不一样的,因为响应请求头可以非常快速地生成,但其实是页面数据影响着这一最重要的指标:用户查看页面的速度。

在CloudFlare,我们大量地使用着nginx,而在调查TTFB时,使用或不使用压缩的情况下来自nginx的TTFB存在显着差异。网页的Gzip压缩大大减少了网页下载所需的时间,但压缩本身需要付出代价。尽管网页的完整下载更快了,但压缩的成本也导致TTFB更大。

为了说明此情况,我们采用了最大的维基百科页面(高级龙与地下城第二版怪物列表)并分别使用开启和不开启gzip压缩的nginx服务。下表显示了打开和关闭压缩情况下的TTFB和总下载时间。

                          |  TTFB   |  Page loaded
------------------------- | ------- | -------------
No compression (gzip off) | 213us   | 43ms
Compressed (gzip on)      | 1.7ms   | 8ms

请注意,如果使用gzip压缩,页面下载速度会提高5倍,但TTFB却高出8倍。那是因为nginx在发送HTTP头之前需要等待压缩开始; 当压缩关闭时,它才会立即发送请求头。因此,如果只看TTFB,你就会觉得压缩页面并不好。但是如果看下载时间,你会得到相反的结论。

从最终用户的角度来看,TTFB几乎没用。在这个(实际)示例中,实际上TTFB与下载时间负相关:TTFB越大,下载时间越快。我们发现,如果我们使用nginx源代码,我们可以作假,而且快速地发送请求头。这样做能够让我们的TTFB即使压缩了页面也不会显得太长,但我们不会这样做:使用nginx源代码使得TCP慢速启动时会浪费掉一个有价值的数据包,这会影响终端用户体验。这个行为可能会让CloudFlare在某些测试中看起来很好,但实际上却影响了终端用户的体验。

也许TTFB的唯一用处是用于观察趋势。并且=最好在服务器本身进行TTFB测量,这样就消除了网络延迟。通过研究其趋势,我们可以发现Web服务器上是否存在问题(例如当它变得过载)。

远程测量TTFB意味着您还要同时测量网络延迟,这会模糊TTFB测量实际指代的内容:Web服务器能够响应请求的速度。

在CloudFlare,TTFB不是一个重要的指标。我们希望优化终端用户体验,因此我们更关注真正的终端用户页面可见的时间。我们将推出专门用于监控终端用户体验的工具,使得我们所有的发布者都能监测到他们的访问者的用户体验。