距离上一篇介绍GTmetrix网页性能测试工具(传送门),已经过去好久了😅。这次来说说Google推出的网页性能测试工具PageSpeed Insights,这款工具是内置在Chromium系浏览器中的,打开浏览器开发者工具,选择Audits选项卡就能看见。不过浏览器内置的功能生成的测试报告是英文的,要想生成中文测试报告,需要访问Google开发者官网PageSpeed Insights页面(点此访问)。

注意:这两种测试方式,无论是使用浏览器自带工具中还是在网页上在线测试,都需要可访问Google的先决条件,请自备相关工具再进行测试。

了解 PageSpeed Insights

Chromium系浏览器的Audits功能
Chromium系浏览器的 Audits 功能

上图是Chromium系浏览器开发者工具中的Audit选项卡。所谓Chromium系浏览器,就是以Google Chromium开源内核为引擎的一众浏览器,包括Google自家的Chrome,以及一众第三方浏览器,国内的QQ浏览器、360浏览器等等都是这种。我使用的Vivaldi也是基于Chromium的浏览器,在之前的一篇文章中我对它进行了简单介绍。

Chromium浏览器内置的Audits功能非常强大,它其实是Lighthouse自动化工具(查看简介),用来帮助开发者改进Web应用质量。它生成的测试报告包含了性能表现(Performance)、可访问性(Accessibility)、搜索引擎优化(SEO)、最佳做法(Best Practices)以及渐进式Web应用(Progressive Web App)这些方面。其中Performance这一块就是PageSpeed Insights。

Chromium系浏览器中Lighthouse测试报告
Chromium系浏览器中 Lighthouse 测试报告

注意:根据Google的提示,由于浏览器扩展会对测试产生影响,所以上图中的报告是在隐私窗口中测试得到的。隐私窗口中禁用了所有浏览器扩展。

先来说PageSpeed Insights,也就是上图Lighthouse测试报告中的Performance方面,这一方面集中分析网页性能。由于浏览器内置的工具只有英文,所以来看看网页版的在线测试:

PageSpeed Insights 在线测试工具
PageSpeed Insights 在线测试工具

居然只有可怜的78分,想想我在GTmetrix上测试的结果可是AA。哎先不管这个分数,Google的这个分数是包含了资源加载耗时的,而我把大图和字体文件都放在了我国内的CDN节点上,Google从国外去访问,速度当然会大打折扣。

抛开分数不谈 ,来看看Google PageSpeed Insights都给出了哪些测试点,这些测试点仍然是网站优化中需要参考的。

分析 PageSpeed Insights 测试报告

PageSpeed Insights 优化建议
PageSpeed Insights 优化建议

上图中是PageSpeed Insights给出的两条最需要考虑的方面:缩短TTFB,以及启用压缩。

缩短 TTFB

首先TTFB(查看说明),是Time to First Byte的缩写,也就是从浏览器发出请求到拿到第一个字节数据所消耗的时间,这个时间包含了服务器处理用户请求再返回页面数据的全过程,数据库查询,创建页面内容,都在这个TTFB时间内。

我这个小站使用了Cloudflare作为前置代理,我在浏览器中运行Lighthouse时显示的TTFB值是480ms,在网页上的在线测试就变成580ms了,可能是Google访问的Cloudflare服务器中没有缓存,Cloudflare需要从源站拉取再返回,造成了TTFB值增加。

TTFB值衡量的是服务器性能高低以及浏览器到服务器之间的网络环境好坏。对于没有管理员权限的VPS主机,要优化这两点几乎是不可能的。如果有管理员权限,可以自由操作Web服务器配置的话,那就可以进行如下操作:

  • 采用新版的运行环境、数据库系统。相比于老版本的来说,新版本的软件性能更好也更安全,PHP语言尤其如此,7.0版本往后的PHP性能远远好于5.x版本。
  • 使用成熟的Web应用框架也会显著提升服务器处理HTTP请求的效率,这些框架对于线程和内存的调度方案也更优。
  • 最后还一点,升级服务器硬件配置,使用固态硬盘,更大的内存以及为服务器专用的CPU。

至于网络方面,访问量大的站点可以接入类似于Cloudflare的前置代理服务,充分利用缓存的优势,让访问者就近取用网站内容,降低内容传输时长,也能减少源服务器的处理压力。

启用内容压缩

这一点的话,在上篇介绍GTmetrix的文章中就已经提过了,在GTmetrix测试报告中,这一点我是通过测试的,然而Google这边,就不行了。

查看报告,PageSpeed Insights要求我压缩的是.moc.mtn文件,这些文件是Live2d动画的素材包,至于它们能不能压缩或者怎么压缩,我还没有了解过(⊙o⊙)。

其它需要启用压缩的文件还有JavaScript、CSS、HTML这些文本型的静态文件,Web服务器会默认对这些内容进行压缩,常见压缩方式有gzip、brotli等。具体选用哪种压缩方式,会在服务器发往浏览器的响应头中用content-encoding头标出。

接着看PageSpeed Insights报告,接下来需要注意的两点是字体可见性以及浏览器主线程负载优化。

确保文本在网页字体加载期间保持可见状态

这一点是PageSpeed Insights特别提出的,支持这一功能的是一项CSS的实验性属性,估计又是Google提出来的(→_→)。

在加载新字体的CSS指令中,添加一行font-display: swap属性。告诉浏览器在字体文件加载完成前,使用系统默认字体代替,避免显示空白。

@font-face {
  font-family: 'xxx';
  font-style: normal;
  font-weight: normal;
  src: local('xxx'), url(xxxx) format('xx');
  font-display: swap;
}

但是,这一属性只适用于自然语言的字体,不适合FontAwesome这种图标字体,因为图标字体系统是无法代替的。而PageSpeed Insights还没有注意到这点,它把无法代替的图标字体也算进去了,还写进了测试报告要我优化(╯‵□′)╯︵┻━┻。

最大限度地减少主线程工作

根据Google开发者网站上的介绍(点击查看),浏览器渲染引擎的主线程会负责解析HTML、CSS、JavaScript,同时还负责响应用户事件,工作量巨大。所以为了减轻它的工作量,让它腾出时间来响应用户交互,需要尽可能的减少它在解析CSS和JavaScript上花费的时间。而主线程最多的工作量是来自于JavaScript,优化JavaScript性能就显得尤其重要。

Google给出的优化措施有:

只发送用户需要的代码

这点其实并不容易,JavaScript模块化开发打包以及按需调用还没有普及。往往是在加载一个网页时加载了N多个js文件或者是它们的简单聚合体(仅仅只是组合了这些js文件的粗糙bundle,没有剔除不需要的部分),这些js文件中很大部分的代码是用不到的,而浏览器却需要逐个去解析它们。

随着JavaScript社区的不断发力以及ES6语法的逐渐普及,JavaScript模块化打包以及模块的按需调用正在流行起来。流行的打包工具,像webpack、Rollup开始支持动态调用。

下面是Google开发者网络上的一个例子,演示了按需调用模块A,当提交表单事件被触发时模块A才被加载:

form.addEventListener("submit", e => {
  e.preventDefault();
  import('library.moduleA')
    .then(module => module.default) // using the default export
    .then(someFunction())
    .catch(handleError());
});

const someFunction = () => {
    // uses moduleA
}

压缩代码

这步操作可以移除代码中的空白部分,以及其它的在创建有效的压缩版本中不需要的代码,还可以对js代码进行一些混淆操作。许多在线工具提供JavaScript压缩及混淆功能,如果不放心在线工具,可以使用Terser这款工具,安装以及操作文档请看这里

移除不需要的代码

这点类似于第一点“只发送需要的代码”。那么如何判断代码是否需要?

第一种方法是使用流行的打包工具如webpack、Rollup来分析代码bundle。

第二种方法是使用Chromium系浏览器开发者工具内置的一项功能“Coverage”,启用Coverage分析后,浏览器会分析整个页面以及所有外联的CSS和JavaScript,并且告知在页面渲染过程中哪些代码被执行了,哪些没有被执行。关于如何使用这项功能,会在本文最后进行说明。

使用PRPL模式加载资源

这里我就套用Google给出的说明了:PRPL是首字母缩略词,它描述一种用于使网页加载并变得交互式,更快的模式 。它包括以下方面:

  • 推送(或预加载)最重要的资源。
  • 尽快渲染初始页面。
  • 预缓存剩余资源。
  • 延迟加载其它页面路由和非关键资源。

这是在JavaScript方面优化浏览器渲染引擎主线程负载。在CSS方面,也是一样,同样需要移除不需要的样式,尽快加载必须样式。

移除阻塞渲染的资源

这一点尤为重要,在一开始的PageSpeed Insights测试中,这一项总是过不去,原因是我在head部分加载了大量的js文件,阻止了浏览器渲染HTML内容。

现在我总算是把这一项优化到极致了,head部分只加载核心CSS,并且以内联style标签的形式加载,不放任何script标签(除了Cloudflare App添加的那两个)。全部js脚本打包成一个js文件放到body最末端,wordpress自带的核心库我用钩子函数移除了,然后再手动在body末端添加,最后body部分的资源加载顺序就是这样的:

<link href="https://cdn.jsdelivr.net/npm/font-awesome@4.7.0/css/font-awesome.min.css" rel="stylesheet" media="all">
<script src="https://cdn.jsdelivr.net/gh/jquery/jquery@1.12.4/dist/jquery.min.js"></script>
<script src="https://cdn.jsdelivr.net/gh/xb2016/kratos-pjax@0.3.6/static/js/live2d.js"></script>
<script type="text/javascript" src="https://stats.wp.com/e-202008.js" async="async" defer="defer"></script>
<script defer="" src="https://www.littlemeteor.me/wp-content/cache/autoptimize/js/autoptimize_265d864486bb8f42655b649652226565.js"></script>

从上往下依次是:

  • FontAwesome图标库:这虽然也是个CSS文件,但是它不是关键CSS,所以不需要放在head部分。
  • jQuery库:作为下面几个js文件的依赖,jQuery必须先加载,同时为了不阻塞HTML渲染,它不能放在head部分。
  • Live2d动画库:是最后一个js文件的依赖,但不是jQuery的依赖,所以放在jQuery后面加载。
  • WordPress跟踪代码:类似于Google分析,是WordPress官方的流量分析工具,它不是本站任何js文件的依赖,也不依赖于任何js文件,并且没有操作HTML文档,所以使用async属性,让浏览器使用新线程加载并且立即执行。
  • 本站核心js文件:这是使用了Autoptimize插件(上篇中有介绍)打包出来的一个js文件bundle,它依赖于上述的jQuery库和Live2d库,所以放在最后。给它用defer属性是因为它后面可能还会有其它的js代码,比如Cloudflare自动生成的代码段,为了不影响后面js代码的执行,使用了defer属性调用新线程加载它,但是在整个文档加载完毕后才执行它。

使用Coverage分析工具

最后一起来学学Chromium浏览器内置的代码覆盖率分析工具。

Chromium 系浏览器 Coverage 分析
Chromium 系浏览器 Coverage 分析

如上图打开开发者工具,选项卡定位到Sources,在红框处会发现Coverage一项,如果没有,也别担心,点击红框左侧的“More Tools”按钮(3个黑点状),选择Coverage一项。

接着点击Coverage窗口中Record按钮(黑点状),随后窗口中会输出各个CSS以及JavaScript文件的利用情况:

Coverage 分析报告
Coverage 分析报告

点击任意一项还会在上方源文件窗口中显示具体的覆盖情况,红色表示未被使用,蓝色表示已被使用。利用这项功能可以准确查看未被利用的代码及样式,并对此加以优化,移除没有使用到的资源减少请求总体积,同时还能减轻渲染引擎的工作负担。

我靠着这个功能,把没用到的CSS样式给删除掉了大半,原主题太复杂,还带了个图标库,很多用不到的样式图标也一并加载,显然是不可取的。经过我删减的主题style.css文件,从120KB变成了97KB,图标库CSS文件fontface.css从36KB变成了4KB,少了50多KB的CSS,是个不小的进步了\^o^/。还有语法高亮插件EnlighterJS,自带的CSS文件包含了所有外观的样式,而我只用其中一个外观,于是乎,35KB的样式表被我砍成了4KB。

PageSpeed Insights剩余的测试内容,跟GTmetrix差不多了,这里就不再一一展开说了。

一开始提到的Lighthouse工具,本文中只着重说了PageSpeed Insights,也就是Lighthouse报告中的Performance部分,关于Lighthouse,剩下的部分我就放到下篇中去说。

上篇链接:从0开始做网站优化(上)——使用 GTmetrix 网页性能评估工具

发表评论

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