TTFB 是 Time to First Byte 的缩写，指的是浏览器开始收到服务器响应数据的时间（后台处理时间+重定向时间），是反映服务端响应速度的重要指标。就像你问朋友了一个问题，你的朋友思考了一会儿才给你答案，你朋友思考的时间就相当于 TTFB。你朋友思考的时间越短，就说明你朋友越聪明或者对你的问题越熟悉。对服务器来说，TTFB 时间越短，就说明服务器响应越快。

TTFB 时间多长算长？

因为每个服务器的硬件和网络环境都不尽相同，每个服务器的 TTFB 时间也不相同。如果想知道你的服务器可以优化到什么程度，大家可以上传一些静态的 HTML 页面到服务器，然后打开这些静态页面，看一些这些页面的 TTFB 时间，大多数服务器的 TTFB 时间都在 50 ms 一下，这个时间就是我们优化时候可以追求的时间。下面两个图中的 TTFB 时间分别是本站所在服务器的静态和动态网页 TTFB 等待时间。

根据我们的测试，TTFB 时间如果超过了 500 ms，用户在打开网页的时候就会感觉到明显的等待。我么可以把 500 ms 以上认为是 TTFB 时间过长。可见，WordPress 智库的服务器还不算差。

TTFB 过长的原因

我们知道，对于动态网页来说，服务器收到用户打开一个页面的请求时，首先要从数据库中读取该页面需要的数据，然后把这些数据传入到模版中，模版渲染后，再返回给用户。由于查询数据和渲染模版需要需要一定的时间，在这个过程没有完成之前，浏览器就一致处于等待接收服务器响应的状态。有些服务的性能比较低，或者优化没做好，这个时间就会比较长。

当然，如果服务器到用户之间的网络不好，（比如，服务器在欧洲，用户在中国，用户打开网页的时候，请求需要跨越千山万水才能达到服务器），服务器接收到用户请求的时间过长，也是导致 TTFB 时间过长的原因。

有时候，页面在用户的浏览器中保存了过多的 Cookie，每次请求，这些 Cookie 都要发送到服务器，服务器都要处理这些 Cookie，这也是导致 TTFB 时间过长的原因之一。

Waiting (TTFB) 时间过长的解决办法

知道了原因，解决办法就显而易见了，那就是缩短服务器响应时间，最简单直接并且有效的办法就是使用缓存，把 PHP 和 MySQL 的执行时间最小化，一些缓存插件可以把 SQL 查询结果缓存起来，把几十次查询结果转换为几次；一些缓存插件可以直接把用户所请求的页面静态化，用户打开网页时，相当于直接从服务器上下载了静态页面。

如果是网络原因，换一个服务器是比较直接的解决办法。如果因为一些原因不能换服务器，可以使用一个 CDN，把页面同步到离用户比较近的 CDN 节点上，也是一个不错的解决办法。

如果是 Cookie 的原因，可以通过修改应用程序，删除一些不必要的 Cookie，或者精简 Cookie 内容，缩短 Cookie 的有效期等，都是解决办法。

记录一个问题吧。

新上线的应用，第一次上线部署了两个节点，通过DMZ的NGINX映射出去的。

上线之后，第三天突然发现访问很慢，有50%的几率保持在7秒左右，通过日志平台观察代码处理时间在40ms左右。

打开F12，发现TTFB时间消耗了6秒。猜测nginx配置有问题，可是nginx配置是我们写好发给运维同事做的，不会出问题。

再猜是DMZ区到应用服务器的防火墙没有打通。最后定位是这个原因。

现象，偶尔访问时间过长，NGINX  hash路由  消耗时间过长。

造成原因，NGINX  Hash 路由 其中某一台 无法访问，造成迂回访问，消耗时间。（可以通过curl命令直接在服务器上访问，跳过nginx 然后再分析）

当前标题：Waiting (TTFB) 时间如何理解Waiting (TTFB) 时间
网站链接：http://chengdu.cdxwcx.cn/article/isgsgd.html