【问题标题】:Confused by the "Time to first byte" TTFB对“第一个字节的时间”TTFB 感到困惑
【发布时间】:2012-03-09 21:56:49
【问题描述】:

著名的TTFB让我很困惑。

具体描述它是什么,我的 HTTP 响应的第一个字节或 TCP 等底层协议的第一个字节?

您经常会看到压缩内容可能会降低 TTFB,但为什么呢?压缩意味着服务器端有更多的 CPU 负载,这会导致更差的 TTFB 还是我在这里错了?

“刷新”内容的时间似乎很重要,但我很难找到有关它的更多信息。我如何影响冲洗,例如在基于 PHP 的网页上?它是服务器的简单设置/配置,还是只是我的代码中执行“回声”的位置?

谢谢

【问题讨论】:

  • 浏览器接收到的页面的第一个字节。 en.wikipedia.org/wiki/Time_To_First_Byte
  • 我已经发现了,但在我看来还不够准确
  • 我认为您在问题中描述的差异不会相关。您真正关心的是页面的响应能力,对吗?
  • 不,这不相关,你是对的。但是在和同事讨论的时候,最好知道我在说什么的细节;)

标签: php performance load gzip


【解决方案1】:

TTFB 是请求结束和收到响应之间的延迟,因为我们在这里讨论的是网络,它将是浏览器收到第一个字节的时间。

压缩内容会略微增加 TTFB,但前提是服务器没有不堪重负,延迟应该可以忽略不计。

gzipping 的作用是减少下载内容的总时间。

通常,在整个页面生成之前,服务器不会将页面发送到浏览器,提早刷新会向浏览器返回一些内容以便它可以处理并开始下载和更快地引用文件。

从本次演讲的幻灯片 51 开始对早期冲洗的一个很好的解释 - http://www.slideshare.net/profyclub_ru/progressive-downloads-and-rendering-stoyan-stefanov

【讨论】:

  • 启用 gzipping 后,我的 TTFB 速度明显变慢。我认为这是合乎逻辑的。因为网络服务器现在需要渲染整个页面直到结束(例如在 PHP 页面的情况下),然后它才能开始压缩,然后开始发送第一个字节。因此,如果第一个文件需要大量时间来渲染,它会显着减慢您的 TTFB。
  • 如果您在启用 gzip 后发现速度明显下降,则表明 gzip 压缩级别过于激进或服务器 CPU 性能不足(也可能是其他一些原因,但仅此而已我将从哪里开始)
猜你喜欢
  • 1970-01-01
  • 2018-01-23
  • 2022-01-04
  • 1970-01-01
  • 2011-06-25
  • 1970-01-01
  • 1970-01-01
  • 2013-09-06
  • 1970-01-01
相关资源
最近更新 更多