关注网页前端性能的朋友,在优化网页性能的时候都会遇到网站加载 Waiting(TTFB)时间过长的问题,为什么优化这项,因为速度性能也是搜索引擎的一个重要的指标。对于没有优化过的 WordPress 站点,TTFB 时间经常超过了页面内容的下载时间,为用户带来不必要的等待时间。这个问题的主要原因是在服务器端,不熟悉服务器运维的朋友优化起来可能会不知道从哪里下手,今天我们就从各方面分析一下网站加载 Waiting (TTFB) 时间过长的原因和解决办法。

什么是 Waiting (TTFB) 时间

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 时间过长的原因之一。

但是造成 TTFB 过长的因素非常多,当时我能想到的有:

服务器的硬件性能和资源占用;
页面大小、复杂程度;
环境配置的正确与否;
源站代码;
DNS 解析的连通情况;
CDN 的性能;

不可避免的又要进行一场分析和试错。

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

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

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

如果是 Cookie 的原因,可以通过修改应用程序,删除一些不必要的 Cookie,或者精简 Cookie 内容,缩短 Cookie 的有效期等,都是解决办法。本站使用的是Cachify 插件 Memcached 缓存方式,直接把用户请求过的页面,缓存到了内存中,网站加载 Waiting (TTFB) 时间达到了 50 ms 左右,感兴趣的朋友可以用谷歌浏览器的调试工具查看一下。

1、使用高级DNS服务

典型的主机包不提供高级DNS(尽管一些托管的WordPress主机提供)。投资于高级DNS提供商将确保通过使用DNS服务器的全球网络以低延迟回答DNS查询,从而帮助您减少TTFB。如果您想更进一步,请考虑在站点上启用DNS预取。该技术允许您告诉浏览器在用户浏览时在后台的页面上执行DNS查找。有关这方面的更多信息,请查看Preload、Prefetch、Preconnect:如何使用浏览器资源提示加快站点的速度。

2、使用缓存

减少TTFB最简单的方法之一是在WordPress站点上设置缓存。缓存有助于减少服务器处理时间,从而减少TTFB。检查您的web主机,看看它们提供了什么对象缓存功能。通常,您需要做的就是请求您的主机启用它。另外,在您的站点上启用WP Rocket来缓存动态内容,以便更快地将页面交付给返回站点的访问者。

3、减少查询

通常,站点为从数据库获取信息而运行的查询数量会影响TTFB。要帮助识别任何查询瓶颈,可以尝试安装一个诊断插件(如query Monitor),或者考虑一个更重要的工具(如New Relic)。后者将帮助您真正深入研究最耗时或查询时间最慢的数据库查询,以便您能够发现哪些插件、主题或设置正在影响站点的页面速度。

4、不同网站程序

比如wp,要保持WordPress,插件和主题的更新,WordPress核心团队,以及插件和主题作者,经常在他们的更新中添加性能优化。有时,这意味着他们优化了代码运行到数据库的查询,或者进行了影响PHP代码效率的更新。

最好的做法是只保留您需要的插件和主题,而删除其余的。所以要经常检查你的插件和主题,删除你不再使用的插件和主题。插件的质量也会影响TTFB,所以要注意那些影响站点性能的插件。例如,坏链接检查器被设计为在后台运行,经常检查坏链接。结果是WordPress管理速度变慢,TTFB增加了。

你还可以在站点上实现许多其他高级技术来改进TTFB,比如磁盘IO、TLS开销、减少自动加载的数据等等。但是我们在本文中介绍的方法相对容易实现,并且会给你带来最大的实惠。

那么问题来了,到底选择缓存还是CDN呢?

理论上来说缓存的安全隐患是最大的,并且结合明月给众多站长们排查网站故障的时候碰到出问题最多的就是缓存造成的入侵、恶意代码植入、后门木马植入这些,都是利用缓存实现的,可以说是防不胜防,无论你是缓存插件(如:W3 Total Cache、WP Super Cache、WP-Rocket 等等)、缓存扩展(如:Redis、Memcached 等等)都有很大的风险,除非你的服务器运维能力非常的强悍,至少有发现可疑后台进程并清除的能力,否则奉劝各位少用缓存插件。

那么缓存插件对于站点速度的提升真实有多大的提升呢?明月的实测结果是,效果会有,但是跟 CDN 加速相比几乎人类是无法感知到的,至于说测速网站之类的数据时缺乏科学性的,有些站长会说自己使用了缓存插件后实测速度提升明显,这是怎么回事儿呢?这个明月要说的是仅仅是个“假象”而已,因为缓存后都会生成一个 HTTP 头定义传递给浏览器,浏览器就会对这个站点进行缓存保存到本地,这时候你浏览自然就快了,CDN 实现的跟这个原理基本类似,并且 CDN 也支持开启浏览器缓存。所以相对于 CDN 来说从安全性上考虑,还是优先使用 CDN 为宜。缓存插件因为涉及生成站点缓存的需求就需要有写入权限,这就给恶意代码植入、木马后门的植入提供了一个入口途径,等于说你留给别有用心的黑客一个小后门了。

所以建议大家能用 CDN 加速网站,就用 CDN,缓存插件是能少用就尽量不要用了,真心是很不安全的。网站速度优化其实是个很系统的工作,并不是仅仅使用个 CDN 或者缓存插件、缓存扩展后就完成了加速优化了,就明月目前的实践经验来看,这些工作仅仅是个开始而已,服务器层面的加速也是必不可少的一环,像服务器端代码执行效率、服务器带宽拥堵的减缓、站点恶意请求的屏蔽和拦截、数据库缓存的启用、PHP 代码运行缓存等等这些对用户端的载入速度都是有影响的。

    版权声明:

     本网站的所有文字、图片资料,未标注转字的均由作者亲自整理创作,如需复制、转载、转贴等方式发布/发表,请以锚链接的方式显示原文出处,请尊重我的劳动成果,侵权必究。本网站转载的文章如有侵权的地方请及时联系本人,核对后会第一时间删除!

阿沐
1625139774@qq.com

发表评论