硅云帮助文档中心
搜索文档
热门搜索词:
产品简介
产品定价
入门指南
经典案例
快照
常见问题
知识拓展
名词解释
API参考
网站加载 Waiting (TTFB) 时间过长的原因和解决办法
在做网页前端加载性能测试时,经常会遇到网站加载 Waiting(TTFB)时间过长的问题。比如对于没有优化过的 WordPress 站点,TTFB 时间经常超过了页面内容的下载时间,为用户带来不必要的等待时间。这个问题的主要原因是在服务器端,不熟悉服务器运维的朋友优化起来可能会不知道从哪里下手,今天我们就从各方面分析一下网站加载 Waiting (TTFB) 时间过长的原因和解决办法。
TTFB 是 Time to First Byte 的缩写,指的是浏览器开始收到服务器响应数据的时间(后台处理时间+重定向时间),是反映服务端响应速度的重要指标。就像你问朋友了一个问题,你的朋友思考了一会儿才给你答案,你朋友思考的时间就相当于 TTFB。你朋友思考的时间越短,就说明你朋友越聪明或者对你的问题越熟悉。对服务器来说,TTFB 时间越短,就说明服务器响应越快。
因为每个服务器的硬件和网络环境都不尽相同,每个服务器的 TTFB 时间也不相同。如果想知道你的服务器优化可以到什么程度,大家可以上传一些静态的 HTML 页面到服务器,然后打开这些静态页面,看一些这些页面的 TTFB 时间,大多数服务器的 TTFB 时间都在 50 ms 以下,这个时间就是我们优化时候可以追求的时间。下面两个图中的 TTFB 时间分别是本站所在服务器的静态和动态网页 TTFB 等待时间。
根据对大量网站的测试,TTFB 时间如果超过了 500 ms,用户在打开网页的时候就会感觉到明显的等待。我么可以把 500 ms 以上认为是 TTFB 时间过长。可见,WordPress 智库的服务器还不算差。
我们知道,对于动态网页来说,服务器收到用户打开一个页面的请求时,首先要从数据库中读取该页面需要的数据,然后把这些数据传入到模版中,模版渲染后,再返回给用户。由于查询数据和渲染模版需要需要一定的时间,在这个过程没有完成之前,浏览器就一致处于等待接收服务器响应的状态。有些服务代码的性能比较低,或者代码逻辑优化没做好,这个时间就会比较长。 当然,如果服务器到用户之间的网络不好,(比如,服务器在欧洲,用户在中国,用户打开网页的时候,请求需要跨越千山万水才能达到服务器),服务器接收到用户请求的时间过长,也是导致 TTFB 时间过长的原因。 有时候,页面在用户的浏览器中保存了过多的 Cookie,每次请求,这些 Cookie 都要发送到服务器,服务器都要处理这些 Cookie,这也是导致 TTFB 时间过长的原因之一。
还有一种容易被忽视的地方,比如我们的某项服务代码中有请求外部接口资源(如采集内容等),当请求的外部资源接口数据下载量大、或者这个接口的与服务器之间的网络通信质量欠佳的时候,也会导致Waiting (TTFB)变长,这时候我们需要去和接口放确认是否能够优化两者之间的网络通信质量,也需要同步核实修改外部资源的请求策略,比如采用缓存的形式,不必每次访客访问网页都请求获取外部资源,而是直接使用缓存的资源,这针对于并非实时更新的数据是相当有效的优化手段。
知道了原因,解决办法就显而易见了,那就是缩短服务器响应时间,最简单直接并且有效的办法就是使用缓存,把 PHP 和 MySQL 的执行时间最小化,一些缓存插件可以把 SQL 查询结果缓存起来,把几十次查询结果转换为几次;一些缓存插件可以直接把用户所请求的页面静态化,用户打开网页时,相当于直接从服务器上下载了静态页面。 如果是网络原因,换一个服务器是比较直接的解决办法。如果因为一些原因不能换服务器,可以使用一个 CDN,把页面同步到离用户比较近的 CDN 节点上,也是一个不错的解决办法。 如果是 Cookie 的原因,可以通过修改应用程序,删除一些不必要的 Cookie,或者精简 Cookie 内容,缩短 Cookie 的有效期等,都是解决办法。 本站使用的是 Cachify 插件 Memcached 缓存方式,直接把用户请求过的页面,缓存到了内存中,网站加载 Waiting (TTFB) 时间达到了 50 ms 左右,感兴趣的朋友可以用谷歌浏览器的调试工具查看一下。
相关文档
您对该文档有什么建议?
本文导航