WordPress是一款开源的博客系统,功能丰富既是它的有点也是它的缺点。优点这里就不说了,缺点是有太多平时用不到的功能(即脚本和样式),在博客页面加载的同时,这些功能都会被加载上去,严重影响了网站的性能,而且随着博客内容增多,速度和性能问题便越发明显。GTmetrix是一款免费的在线网页性能测试工具,它使用PageSpeed和YSlow两个标准来测试一个网页的速度和性能,涵盖了五、六十个测试点,同时针对每一个测试点都给出了详细的解决方案供参考。

提到网站优化,我觉得很多人脑子里冒出的第一个想法就是升级服务器。确实,提升服务器性能就可以提高网站性能,但是服务器性能总归有个瓶颈,在面对大量访问的情况下,单台服务器的处理能力显然不够。况且现在用VPS搭建网站的现象还是普遍的,VPS并没有给用户开放管理员权限,而且同一台VPS上可以托管多个网站,分摊到每个网站上的计算资源就变少了。

那么作为一个开发人员兼网站管理员,得从更为专业的角度去优化网站性能,遇事得细细分析,不能一梭子直接怼,不然哪对得起程序员这个行业😆 ?

了解GTmetrix

本文标题是“使用 GTmetrix 网页性能评估工具”,那么现在就先来了解一下这款网页性能测试工具。

GTmetrix是一款免费的在线网页性能测试工具,它的测试标准有2个,引语中已经提到,第一个是PageSpeed,跟Google的网页性能分析工具同名,应该是同一个,但是有些测试点又不相同。第二个是YSlow,是Yahoo的测试工具,两者都是老牌的权威工具。

GTmetrix可以选择使用分布于全球的七个观测点进行测试,分别是美国达拉斯、中国香港、英国伦敦、印度孟买、澳大利亚悉尼、巴西圣保罗、加拿大温哥华。可以看到其中并没有位于中国大陆的观测点,所以测试大陆网站的话,得出的网页响应时间可能会跟实际去访问感受到的响应时间有偏差。但是这个影响并不大,因为两个标准的所有测试点都没有网页响应时间这一块,页面加载时间只会在最终生成报告时显示。

GTmetrix官方网站https://gtmetrix.com,点此访问。进去之后首页中间一个文本框,输入想要检测的网址,点击右侧Analyze蓝色按钮即可,稍等片刻就会有一份详细的分析报告呈现出来。

GTmetrix 首页(已登录)
GTmetrix 首页(已登录)

注:有一点需要注意,如果站点中使用了自托管的CDN,比如我这个,使用了阿里云CDN服务,域名(static.littlesecret.cn)是我自己的,不是世界主流CDN服务商的域名,GTmetrix就会在CDN检测这一项中扣分。如果不想要扣分的话,可以注册一个GTmetrix账号然后登录,在个人设置里添加自有CDN域名就可以了,GTmetrix就会正确识别CDN。

GTmetrix 测试结果
GTmetrix 测试结果

GTmetrix主要测试点(PageSpeed)

前面说到得用专业的方式去做优化,那么GTmetrix这款工具都是从哪些专业角度来测试网页性能的?一起来看看,这一块先说PageSpeed标准。

打开上一步中得到的测试报告,在PageSpeed选项卡中,有30项左右的测试点,分为HIGH、MEDIUM、LOW这3个优先级。

我这里就只列举高优先级的部分,这些是影响网页性能的主要原因,每一项的说明是我翻译的报告中的说明:

  • Serve scaled images:提供缩放版本的图像,可以节省传输流量开销
  • Optimize the order of styles and scripts:优化样式和脚本的顺序,可以更好的并行下载资源以及提升渲染速度
  • Minify JavaScript:压缩JavaScript代码
  • Minify CSS:压缩CSS样式表
  • Avoid bad requests:避免无效请求,类似于404
  • Avoid landing page redirects:避免着陆页上发生重定向
  • Defer parsing of JavaScript:推迟解析JavaScript代码,避免阻塞页面渲染
  • Enable compression:启用内容压缩,内容压缩在服务器端执行,减小传输体积
  • Enable Keep-Alive:保持HTTP持续连接,使同一个TCP连接可以进行多次HTTP传输
  • Inline small CSS:内联小的CSS文件,减少HTTP请求次数
  • Inline small JavaScript:内联小的JavaScript文件,减少HTTP请求次数
  • Leverage browser caching:利用浏览器缓存,一些静态文件无需重复请求
  • Minimize redirects:最小化重定向次数
  • Minimize request size:最小化请求体积,可以缩小Cookie和HTTP请求头的大小来实现
  • Optimize images:图片优化,措施有:压缩图片体积、在HTML指令中设置图片尺寸而不是通过CSS、以正确的格式提供图片、根据访问需要来提供图片
  • Put CSS in the document head:在head部分放置CSS,提升渲染速度
  • Serve resources from a consistent URL:从一致的URL提供资源,同一资源从一个固定的源加载,可以充分利用缓存的优势
  • Specify a cache validator:指定缓存时间,同样让浏览器充分利用缓存
  • Combine images using CSS sprites:利用CSS Sprites组合小的图片,然后使用background-position属性去使用它们

GTmetrix主要测试点(YSlow)

同上,打开YSlow选项卡,也是3个优先级,我列举一下高优先级的部分,并配上报告中各项说明的翻译:

  • Add Expires headers:添加Expires响应头,以便让浏览器知道是否该使用缓存
  • Make fewer HTTP requests:减少HTTP请求次数,可以通过合并文件以及CSS Sprites来实现
  • Compress components:内容压缩

好了,专业的检测工具已经给出了解决方案,从这些高优先级的方案中可以看出:压缩、缓存、不阻塞、不重定向,以及减少请求,是整个网页性能优化的核心。下面就是来对症下药,看看如何实际运用这些方案。

原始WordPress性能分析

首先来看看导致WordPress站点性能下降的原因吧。

我找了一个基本上没有优化过的WP(WordPress简称,下文中可能会用到)站点,没有安装任何优化插件(除了官方的Jetpack),没有使用其它CDN服务等等,就是一个类似原始状态的WP。

在原始的WP中,加载一个页面会加载各种各样我都搞不清用途的CSS和JavaScript,虽然在使用了WordPress官方的Jetpack插件(官方优化插件,提供CDN、懒加载、安全、流量分析、社交网络接入等等功能)后会通过WordPress官方的CDN服务来提供这些文件,但是仍然有一部分会从源服务器加载。

从源服务器加载,势必会产生Cookie,请求头中携带Cookie则会增大请求头体积。而从WordPress官方CDN加载的文件,虽然没有了Cookie,但是请求次数不会减少,而且官方CDN估计服务器都在国外,有时候就会一个请求阻塞很久,从而阻塞页面。

以下是我找的这个站点,它加载时的Firefox浏览器记录,我选择了JavaScript和CSS部分,部分打码域名是源站域名,这里就不泄露了:

未经优化的 WordPress 站点首页加载详情
未经优化的 WordPress 站点首页加载详情(CSS 以及 JavaScript)

以上截图,请求域名含有wp的均为WordPress官方CDN,打码的均为源站。可以看到一个首页就请求了这么多CSS和JavaScript,这还不包括图片、字体等其它静态资源文件。

而且在head部分加载的JavaScript文件,如果不使用defer(异步加载并且推迟执行)或者async(异步加载并且立即执行)属性,就会卡在那加载并且执行,从而阻塞页面继续渲染。事实上这个站点的JavaScript中,位于head部分并且会阻塞页面的就有5处。

我选的这个WP处于一个很少打理的状态,文章很少,也没添加什么额外功能,所以即便不去优化,也没有多大影响。但是如果是一个自定义内容非常多的站点,就不一样了,页面上会多出很多CSS和JavaScript,同时页面复杂度提高,服务器端的PHP计算量也会有所提高,这个时候优化就极为重要了。

我以我自己的这个WP站点为例,我添加的额外功能小到一个欢迎语,大到左下角的那个live2d动画,每个功能都需要一定量的样式和脚本来支持。这个时候每个功能都去外联一个CSS和JavaScript文件显然是非常不可取的,所以一开始我把它们都写在WP定制器里一个叫作“自定义HTML”的小工具(WordPress定制器功能之一,允许在页面指定位置添加额外HTML内容)里。随着自定义的功能增多,HTML中的CSS和JavaScript越来越多,这个时候就不符合“CSS放在head中,JavaScript推迟执行”这一原则了。

为了添加功能,有时候需要安装一些WordPress插件,正常情况下这个插件都会带有一定量的CSS和JavaScript,而且是默认加载到站点的每个页面上的,就算这个页面用不到它,也会加载,还是从源站的插件安装目录下加载,这个就很头大了,第一个问题是加载更多的无效文件,第二个问题是源站加载会携带Cookie,第三个是传输速度可能会受源站带宽影响。

关于WordPress,还有一个问题是,自身太过臃肿,除了加载一堆的文件外,本身HTML也很庞大,head里有很多用不到的meta标签,不仅增大文件体积,有的meta也会带来一些安全隐患。

对症下药,加速WordPress站点

以上说的各种问题,前面的GTmetrix报告里给出的措施,可以解决绝大多数。

解决请求文件过多

首先来看看请求文件过多的问题,这个问题最好的解决办法就是合并CSS文件、合并JavaScript文件,多个请求合并成一个,虽然合并出来的文件体积会增加,但是这一个文件的请求开销是远小于分开请求一系列文件的总开销的。因为合并的文件会进行压缩,体积会比之前多个文件的总体积小,而且合并之后只占用一次HTTP请求,只需要一次HTTP连接初始化。

推荐插件Autoptimize

Autoptimize是一款流行的WordPress静态文件合并插件,可以合并CSS和JavaScript文件,默认排除jQuery以及wp-includes文件夹下面的库文件,安装之后进入插件设置页面,配置一下需要排除的文件,然后接下来就可以交给这个插件了,Autoptimize会搜索WordPress安装目录下的所有CSS以及JavaScript,排除已经指定的排除项,合并其它的,最后在wp-content文件夹下生成一个缓存文件夹,里面存放合并之后的CSS和JavaScript,最终WordPress页面也是调用的这些缓存的文件。注意缓存文件会定期刷新,所以虽然插件提供了一个CDN的功能,我也不知道怎么用,直接拷贝生成的缓存文件到阿里云CDN源服务器是没用的,因为一旦缓存刷新,就没用了。

还有一个问题,如果发现安装的一些插件(比如语法高亮插件Enlighter)无法使用了,可能就是这个插件的CSS或者JavaScript不能被合并,这时候就要去Autoptimize排除列表里添加这个插件的路径。

推荐插件Asset CleanUp: Page Speed Booster

Asset CleanUp是另一款静态文件合并插件,在合并这方面,它不如上面的Autoptimize做的好,但是这个插件有一个强大的功能,那就是它可以给每个页面配置需要加载的CSS和JavaScript文件,移除不需要加载的。

插件是英文版的,没有中文,不过这对我来说不是问题,大概看得懂就行。Asset CleanUp插件设置页面中可以对首页加载的CSS和JavaScript进行限制,可以指定一个脚本或者样式表是全局都不加载(整站全不加载),还是只在这一个页面上不加载,这样可以很方便的剔除一些没用的WordPress自带文件。至于一些付费功能,例如设置defer或者async属性,就没法用了,不过免费的功能真的解我的愁了,也很不错了。

至于对每个内容页,也可以设置,需要进入文章编辑页面,拉到最下面,就可以看到Asset CleanUp的配置选项了。

解决渲染阻塞

解决渲染阻塞,主要就是解决JavaScript加载以及执行顺序的问题,尽可能把JavaScript移到body内容之后去。

好在上面的Autoptimize插件创建的合并出来的JavaScript文件,是以defer形式在页尾处加载的,也就是异步加载,但推迟到文档全部加载完成后再执行。

至于我写在body中的一些JavaScript代码,也可以使用Autoptimize插件全部提取出来,合并到最终生成的缓存文件里,这样就推迟到最后去执行。

要注意一点,如果使用WordPress插件来实现一些功能,这些插件大部分都是调用WordPress提供的函数钩子(wp_register_script或者wp_enqueue_script,这两个是加载外联脚本文件的内置函数)来实现外联JavaScript加载,而钩子会在head部分就加载JavaScript文件,并且也不会添加defer或者async属性,所以会导致页面阻塞。这时候有个解决办法就是修改插件文件,PHP文件修改起来也不算难,找到使用函数钩子的地方,删除这行,然后使用PHP的echo函数输出一行自定义的<script defer></script>或者 <script async></script> 标签。如果这个PHP文件是纯逻辑的,不是HTML形式的,那就没办法使用标签了,这时候就可以直接修改钩子函数的参数,把表示文件地址的参数改成CDN连接或者其它的,反正尽量不要用源站的地址。

WordPress自带JavaScript文件可以用钩子函数wp_deregister_script移除,传入脚本文件的handle名就可以了,handle名在WordPress开发者官网上都能查到,移除钩子需要在主题的functions.php文件里写。然后想要添加脚本文件,又想要异步加载或者推迟执行,这个时候就不能用官方的钩子函数了。可以在WordPress插件市场里搜索head,foot之类的插件,这些插件允许手动在WordPress页面的head(head标签最后)或者foot(body标签最后)部分添加自定义内容。注意使用多个推迟执行的脚本会有风险,因为执行顺序不一定是它们在HTML中出现的顺序,可能会出现被依赖的脚本还没执行,依赖它的就在执行的现象

解决图片问题

图片也是WordPress站点的一个麻烦事,一个内容丰富的WP,首页就有大量的图片需要加载,不仅有文章缩略图,还有背景图、顶图等等。如果有自己添加的其它功能,那图片就只会更多。

解决图片问题的第一步是减小图片文件体积,这里推荐两个去处。第一个是一个在线的图片压缩工具WebPlanet,这个在线工具不错,压缩png或者jpg图片效果明显,也不会失真,也不会像某些图片压缩工具一样把png图片的透明底搞没了。

推荐插件WP-Optimize – Clean, Compress, Cache

WP-Optimize插件采用两款国外的图片压缩API压缩图片,效果也是不错的,并且可以设置为自动压缩上传图片,无需手动操作。

在减小了图片体积之后,选择合适的加载源也是十分重要的,能不从源站加载就尽量不从源站加载。上文提到,WordPress的官方优化插件Jetpack,具有图片CDN的功能,它会自动把<img>标签内的图片上传到WordPress官方CDN节点,同时还会进行一些压缩。最好的是Jetpack还提供懒加载功能,当滚动页面时,才会加载下面的图片,不然只加载视野范围内的图片。

WordPress定制器里允许设置背景图,但是不建议在定制器里直接设置背景图,直接设置的话背景图就会从源站加载,如果背景图比较大的话就很吃亏。这时候可以在定制器的自定义CSS里手动给body设置background属性,指定从一个第三方CDN加载背景图。

一些比较小的图片,可以使用CSS Sprites来组合成一张图,然后使用background-position属性去使用它们。或者也可以转化成base64编码,写在url属性里,比如自定义鼠标指针。

使用缓存

一个网页,不仅仅它上面的图片、脚本、样式表等静态文件可以缓存,网页本身也是可以缓存的,即使是WordPress的PHP动态页面。

先来说静态文件缓存,我的WP上大部分静态文件都是由第三方CDN提供,CDN服务器有自己的缓存机制,也就是响应头里的Cache-control属性,对于通用的公共库,缓存时间都比较长,浏览器无需反复请求服务器,直接用本地缓存就行。

因为我的站点接入了Cloudflare服务(参考这篇博客),Cloudflare缓存了我站点上的CSS、JavaScript、字体以及图片,这些缓存期限可以设置长些,我设置的是8天。Cloudflare也是允许缓存HTML页面的,不过不是默认开启,需要在后台Page Rules里手动设置,怎么设置请移步官方支持

不过虽然Cloudflare可以缓存HTML页面,但是源站提供的是动态PHP文件,那也不行,这时候就需要一款超级缓存插件来实现将PHP页面静态化的功能。

推荐插件WP Super Cache

作为一款WordPress官方的超级缓存插件,这款的好评也是多多,甚至相当多的国外的WP建站平台首推的缓存插件就是它。

WP Super Cache既然是官方插件,那么使用起来自然不必多说:完整的中文说明,近乎傻瓜式的操作引导,甚至提供了一键设置的功能,如果你不熟悉高级设置里的那些功能的话。好了关于这个插件我也不多说了,反正都能一键设置了,唯一需要说一说的就是它的缓存期限,可以修改,根据自己站点文件变动频率来就行;还有缓存刷新频率,也是如此,看自己站点更新频率。

有了WP Super Cache生成的静态缓存文件,那么Cloudflare就能引用它们了,这样当我访问我的WP时候,Cloudflare就可以直接从CDN缓存里拿HTML文件返回给我,不再需要回源了。

上篇的内容就这么多了,已经7500字了,我目前使用的优化措施大部分都介绍了,总之还是结合GTmetrix的分析报告,一步步对症下药来。虽然我踩了很多坑,有好多次差点把站点搞崩了,不过看到GTmetrix双A的测评报告,还是开心的,努力没有白费。下篇中我将介绍Google PageSpeed Insights这款分析工具,看看它带来了哪些新的优化措施,毕竟对于网站优化,没有比Google更专业的了。

发表评论

电子邮件地址不会被公开。 必填项已用*标注