从第一个字节到第一个字节的时间通常被用来衡量web服务器对请求的响应速度以及公共web测试服务报告请求的速度。它越快越好的web服务器（理论上）。但是这个理论不是很好。Wikipedia将第一个字节的时间定义为"从虚拟用户发出HTTP请求到浏览器接收到页面第一个字节的持续时间"，但是流行的web页面测试站点实际报告了什么呢？为了找到答案，我们创建了一个测试服务器，它将延迟插入到HTTP响应中，以找出真正被度量的内容。答案让人大吃一惊，并表明TTFB并不是一个有用的衡量标准。当web浏览器从web服务器请求一个页面时，它会发送请求本身和一些头部，其中指定了响应的可接受格式等内容。服务器用一个状态行（通常是HTTP/1.1200ok表示页面可用），然后是更多的标题（包含关于页面的信息），最后是页面的内容。CloudFlare的TTFB测试服务器的行为稍有不同。当它收到一个请求时，它发送第一个字母HTTP/1.1200ok（H），然后等待10秒，然后再发送其余的标题和页面本身。（您可以在这里获取TTFB服务器的代码；它是用Go编写的）。如果您要求webgetest从CloudFlare TTFB服务器下载一个页面，您会得到以下惊喜。WebPageTest将第一个字节的时间报告为收到H的时间（而不是页面本身实际发送的时间）。10秒的等待让这一点显而易见。

戈麦斯报告的数字完全相同。报告的TTFB不是页面的第一个数据字节的时间，而是HTTP响应的第一个字节的时间。这是非常不同的事情，因为响应头可以很快生成，但是数据将影响所有最重要的指标：用户查看页面的速度。在CloudFlare，我们广泛使用nginx，在研究TTFB时，发现在使用或不使用压缩时，TTFB与nginx之间存在显著差异。网页的Gzip压缩大大减少了网页下载所需的时间，但压缩本身也有成本。这一成本导致TTFB更大，即使完整下载更快。为了说明我们使用了最大的Wikipedia页面（高级地下城和龙的列表第二版怪物），并使用nginx提供服务，无论是否启用gzip压缩。下表显示了打开和关闭压缩时的TTFB和总下载时间。|TTFB |页面已加载------------------------- | ------- | -------------无压缩（gzip关闭）| 213us | 43ms压缩（gzip开启）| 1.7ms | 8ms注意使用gzip压缩时，页面下载速度提高了5倍，而TTFB的下载速度提高了8倍。这是因为nginx在发送HTTP头之前一直等到压缩开始；当压缩被关闭时，它会直接发送头。所以如果你看一下TTFB，看起来压缩是个坏主意。但如果你看下载时间，你会看到相反的结果。从最终用户的角度来看，TTFB几乎没有用。在这个（真实的）例子中，它实际上与下载时间负相关：TTFB越差，下载时间越好。窥视nginx源代码，我们意识到我们可以作弊并快速发送邮件头，这样即使是压缩，我们的TTFB看起来也非常棒，但最终我们决定不这样做：这也会对最终用户体验产生负面影响，因为当TCP正经历缓慢启动时，我们会浪费宝贵的数据包。它会使CloudFlare在某些测试中看起来不错，但实际上会伤害最终用户。也许TTFB唯一有用的时候是作为一种趋势。而且最好在服务器本身进行测量，这样就消除了网络延迟。通过检查趋势，可以发现web服务器上是否有问题（例如它变得过载）。远程测量TTFB意味着您同时也在测量网络延迟，这就掩盖了TTFB实际测量的东西：web服务器响应请求的速度。在CloudFlare，TTFB不是一个重要的指标。我们对优化最终用户的体验感兴趣，这意味着真正的最终用户页面是可见的。我们将推出专门用于监控最终用户体验的工具，以便我们所有的出版商都能看到并衡量他们的访问者的体验。