网站性能突破-Lighthouse

132 阅读6分钟

本教程主要参考 参考developer.chrome.com的教程 developer.chrome.com/docs/devtoo…

1.环境搭建

官方使用的是一个云线上react代码,实际效果比较卡顿,图片也无法查看。可以通过git地址本地跑调试

本地启动

npm i # 安装
npm run develop  # 启动

访问 http://127.0.0.1:1234/

image.png

确认自己的chrome版本

在地址栏输入 查看自己的版本,不同版本确实命名和位置都不太一样

chrome://version

image.png

使用隐私模式启动

为了避免分析的时候,被插件的影响诊断,建议使用无痕模式启动

image.png

设置开发者工具 默认为中文

英语不好,可以设置为中文便于理解 image.png

image.png

2.lighthouse分析

建立基准

就是通过多次生成lighthoust报表,对比差异才能明确是否被正确优化到位。

再浏览器空白右键,选择inspect/开发者工具, 打开开发者工具

image.png

打开 Lighthouse 面板。它可能隐藏在 “更多面板”后面。

image.png

选择移动端,然后点击“分析xxx”

image.png

开始审查。。。

image.png

得到一份糟糕的结果,当然分数每次可能都不太一样,应该跟多关注下面的建议 image.png

通过点击这里的按钮可以切换不同的评估建议

image.png

给出了很多建议 image.png

3.优化

1.优化请求压缩

image.png

这里提示我们要把服务器的资源压缩后在返回给客户端解压。

设置网络请求

网络请求默认不展示 解压前的资源大小 image.png

打开网络面板,然后依次选择 settings Settings(设置)> check_box勾选框 Use large request rows(大请求行)。

打开前后对比资源 image.png

image.png

修改代码

打开我们项目

image.png

const fs = require('fs');
const compression = require('compression'); // 引入压缩包

app.use(compression()); // 使用压缩
app.use(express.static('build'));

再次请求,在网络里面看已经 看到明显的压缩了,比如lodash从 540 kB 到 96.9 kB

image.png

请求头也增加了 gzip

image.png

再次诊断 从 51 变成 52

image.png

2.优化图片

提示图片太大 建议调整大小 image.png

我们在url加上边缘渲染的压缩参数

修改代码

调整 src/model.js

image.png

 image: `https://dn-dora-document.qbox.me/pexels-clement.jpg?imageView2/1`, 
 改成 
 image: `https://dn-dora-document.qbox.me/pexels-clement.jpg?imageView2/1/w/300`,  

从网络请求查看 大小也从 4300k 变成了 28k

image.png

建议策略

  • 在构建过程中调整图片大小。
  • 在构建过程中为每个图片创建多种尺寸,然后在代码中使用 srcset。在运行时,浏览器会负责选择最适合其所运行设备的大小。请参阅相对大小的图片
  • 使用图片 CDN,以便在您请求图片时动态调整图片的大小。
  • 至少要优化每张图片。这通常可以带来巨大的节省。优化是指通过可缩减图片文件大小的特殊程序运行图片。如需更多提示,请参阅图片优化必备知识
  • 请求图片使用loading="lazy" 实现懒加载
  • Cache API + Service Worker 缓存资源

3.移除阻塞资源

呈现阻塞资源是指浏览器必须先下载、解析和执行的外部 JavaScript 或 CSS 文件,然后才能显示网页。目标是仅运行正确显示网页所需的核心 CSS 和 JavaScript 代码。

image.png

确认资源是否正常被引用和使用

打开快速搜索

  • 在 Mac 上,按 Command+Shift+P
  • 在 Windows、Linux 或 ChromeOS 上,按 Ctrl+Shift+P

搜索 显示覆盖范围 image.png

底部会显示覆盖率,点击刷新按钮开始扫描

image.png

扫描结果 红色为未使用,灰色为已经使用 image.png

点击其中一条 lodash,可以看到灰色大部分都是变量定义和注释,实际定义的方法并没有被调用

image.png

加入block

我们可以加入block 阻止这些资源加载看看程序是否还能正常运行。

继续快捷键 Command+Shift+P ,搜索 屏蔽,选择 网络请求屏蔽

image.png

底部新增 网络请求屏蔽 页签,点击+ 输入过滤条件 /libs/* image.png

image.png

image.png

刷新页面,可以看到资源已被block ,但是业务正常,可以移除多余资源

image.png

修改代码

template.html

image.png

移除

    <script src="/libs/lodash.js"></script>
    <script src="/libs/jquery.js"></script>

关键呈现路径是指加载网页所需的代码。一般来说,您可以通过仅在网页加载期间提交关键代码,然后延迟加载所有其他代码来加快网页加载速度。

优化建议:

  • 您不太可能找到可以直接移除的脚本,但您经常会发现,许多脚本在页面加载期间不需要请求,而是可以异步请求。请参阅使用 async 或 defer
  • 如果您使用的是框架,请检查它是否具有正式版模式。此模式可能会使用摇树优化等功能,以消除阻止关键渲染的不必要代码。

修改文件 webpack.config.js

image.png

mode: "development",
改成
mode: "production",

4.减少主线程工作

可以看到大部分都是 js阻塞执行导致。 image.png

performance 性能面板

js主线程要是单线程执行,如果有同步阻塞的方法会影响渲染,具体的检查 需要使用 performance 性能面板

image.png

点击刷新按钮进行录制

image.png

新版支持 modern模式 推荐

image.png

这里我们重点关注 黄色的山图,这里:主要:cpu有大量运算,最底部有最终调用的js逻辑,可以看到是mineBitcoin。

image.png

修改代码

我们在项目代码全局搜索 mineBitcoin,找到在src/App.jsx 下面构造方法执行了mineBitcoin方法。里面死循环了1.5秒。我们注释该代码再运行look look。

image.png

重新评分 一下飙到 87

image.png

可以使用 User Timing API 任意标记应用生命周期的特定阶段,以跟踪每个阶段所需的时间。

5.布局偏移原因

image.png

常见问题

  • 没有给图片设置预留的宽高 可以配合aspect-ratio 设置
  • 没有给广告位设置预留的宽高
  • 字体加载的变化

由于字体默认需要时间才能加载完,你可以根据自己清空调整

  • 希望快速加载可以使用 swap,但会导致cls问题
  • 希望保证字体加载完成可以使用 block,但是首屏会等待比较久。
@font-face {
   font-display: optional 
}
阻塞时间超时行为适用场景
auto由浏览器决定不确定默认值,不推荐显式使用
block约 3 秒超时后 FOUT + 后续切换优先保证字体加载完成
swap0 秒(立即 FOUT)加载完成后替换尽快显示文本(如新闻)
fallback约 100ms超时后 FOUT + 不再切换非关键字体(如图标)
optional约 100ms超时后 FOUT + 可能不加载性能优先,避免布局抖动

注意:实际开发中,字体由于传输延迟问题,往往会一直影响文字的动态排版,这时候使用图片并给出固定的宽高是一个不错的选择

4.总结

lighthouse 是一个实操性很强的报告,我们按上面提示依次优化,就能把页面焕然一新。

5.源码

github.com/mjsong07/li…