Lighthouse与首屏优化
之前提到首屏优化，想到的就是Vue项目首页打开很慢需要优化。一般都是肉眼看看，对当前的加载速度并没有一个准确的衡量标准，也没有很清晰的解决思路。
前两天我想给自己的网站申请谷歌广告，听说审核对网站的性能要求很高。于是网上搜索后发现了一个网站优化利器--Lighthouse
一：Lighthouse是什么？
Lighthouse 是一个由 Google 开发的开源自动化工具，用于改进网页质量。它提供全面的网页性能、可访问性、最佳实践和 SEO 分析，帮助开发者构建更好的网站体验。
Lighthouse这个工具前端开发者又熟悉又陌生，说她熟悉因为她就在Chrome的F12面板中，跟Network在一块。说她陌生是因为，可能大多程序员没注意到她，也不知道她是干什么用的。
Lighthouse使用起来很简单，F12里找到她，输入需要检测的网站即可。我第一次使用时的得分如下
二：Lighthouse的相关指标
1、主要指标
如上截图中主要4个指标，相关概念如下
| 性能 (Performance) | 页面加载速度和用户体验 | 包含FCP, LCP, TTI, TBT, CLS |
| 可访问性 (Accessibility) | 残障用户友好度 | 屏幕阅读器支持，色彩对比度，ARIA 属性 |
| 最佳实践 (Best Practices) | 现代Web开发标准 | HTTPS, 安全的API使用，图片优化 |
| SEO (Search Engine Optimization) | 搜索引擎优化 | 元标签，结构化数据，移动友好性 |
2、性能(Performance)下的指标
- FCP (First Contentful Paint) 首个内容绘制时间
测量页面首个元素呈现的时间，让用户知道网站开始载入了。
-
LCP (Largest Contentful Paint) 最大内容绘制时间
测量页面主要内容加载完成的时间，让用户知道网站载入完毕，可以交互了。
- CLS (Cumulative Layout Shift) 累积布局偏移
测量页面内容意外移动的程度，比如一个按钮在点击时因其他元素加载突然下移了。
3、指标作用
通过这些指标得分，我们可以量化的知道自己网站的性能效果。有一个参考值，便于针对性的优化。
三：优化建议
Lighthouse的每个指标都有对应的优化建议，如下图。如图右上角可以切换各个指标
四：成功实践
我根据Lighthouse的建议，针对性的做了相关的措施。最终成绩如下，我网站效果为CodingLife，忙活了4天结果还算满意~
先说下我服务器的配置，2核2G 3M带宽。为了节省费用，配置堪称寒酸！
1、分割打包 按需加载
首先要在路由配置中，使用按需加载与分包设置
// router.js文件中
routes: [{path: '/',name: 'BlogDetail',component: () => import(/* webpackChunkName: "blogDetail", webpackPrefetch: false */ '@/components/MainPage/BlogDetail');}
]其次一定要配合webpack配置，否则很可能无法按需加载。即首页渲染时，加载其他页面的js包
// vue.config.js文件
module.exports = {chainWebpack: config => {// 禁用所有 prefetchconfig.plugins.delete('prefetch');}
};2、压缩资源包体积
将JS资源文件打包为.gz格式，可以高效减少资源包体积。shezhi前端webpack打包时，就做GZip压缩
// vue.config.js文件
module.exports = {configureWebpack:config=>{// GZip压缩const CompressionPlugin = require('compression-webpack-plugin');config.plugins.push(new CompressionPlugin({algorithm:'gzip',test:/\.(js|css|woff|woff2|svg)$/, // 要压缩的文件threshold:10240, // 压缩超过10k的数据deleteOriginalAssets:false, // 不删除压缩前的文件，如果浏览器不支持Gzip，则会加载源文件minRatio:0.8 // 压缩比大于0.8的文件将不会被压缩}));}
};
Nginx服务器，配合设置
server {gunzip on; # 如果客户端不支持 gzip，自动解压返回原始文件gzip off; # 关闭动态压缩（因为已经有预压缩文件）
}3、减小图片体积
图片使用webp格式，可以大幅减小图片体积。使用webp主要工作在ngnix上，具体操作如下
安装cwebp，处理图片
# 下载最新版源码（当前最新版本1.3.0）
wget https://storage.googleapis.com/downloads.webmproject.org/releases/webp/libwebp-1.3.0.tar.gz# 解压并进入目录
tar -xvzf libwebp-1.3.0.tar.gz
cd libwebp-1.3.0# 配置编译选项（确保启用PNG和JPEG支持）
./configure --enable-libpng --enable-libjpeg# 编译并安装
make
sudo make install# 刷新库缓存
sudo ldconfig# 验证安装
cwebp -version配置nginx有限返回webp格式图片
http {# 简化的WebP检测map $http_accept $webp_suffix {default "";"~*webp" ".webp"; # 添加.webp后缀}# HTTPS 服务器 - 主配置server {listen 443 ssl http2;server_name codinglife.online www.codinglife.online;location /uploads/ {alias /opt/CodingLife/uploads/;autoindex off;# 核心缓存策略（根据文件类型区分）location ~* \.(jpe?g|png|gif|webp|svg|avif)$ { try_files $uri$webp_suffix $uri =404;add_header Vary Accept; # 关键：标记内容协商}}}
}4、减少图片请求数量
我的博客首页是个列表，列表的每条都包含一个缩略图，刚开始设置每页8条数据。8个图片，对于3M的带宽来说，压力太大。
于是我将分页请求中每页条数精细化，根据设备分辨率动态设置。比如移动端每页3条，笔记本电脑每页4条，外接显示器8条。
calculatePageSize() {if (this.windowWidth < 1366) {this.perPageNum = 3 // 移动端和小屏设备} else if (this.windowWidth >= 1366 && this.windowWidth < 1600) {this.perPageNum = 4 // 14寸笔记本} else if (this.windowWidth >= 1600 && this.windowWidth < 1920) {this.perPageNum = 5 // 15.6寸笔记本} else {this.perPageNum = 8 // 大屏幕}}5、减少无用Dom
因为Lighthouse还模拟移动设备测试首屏性能，并且模拟条件极为苛刻。具体如下
-
Desktop：默认使用 150ms TCP延迟的"有线"网络 (类似稳定WiFi/光纤)。 -
Mobile：默认使用 300ms TCP延迟 + 1.6Mbps下载/0.75Mbps上传的"慢速4G"网络。
我的网站使用媒体查询，自适应移动端和pc端。因为移动端屏幕大小有限，我选择隐藏了很多不必要的模块。但原有的css设置隐藏是奢侈的，依旧消耗性能，我本次将无用的dom需要彻底删掉。
<section v-if="isDeskTop"></section>data: function () {return {isDeskTop: window.innerWidth > 768 // 是否是桌面端}
},6、剔除无用请求
以前适配移动端时大大咧咧，只想着实现效果就行。很多无用模块都是css配置display:none，js接口正常请求，现在看来是真的浪费。本次我又精细化的过了一遍，移动端时删除不必要的接口请求。
// 移动端时删除不必要的接口请求
if(this.isDeskTop){ //渲染留言个数this.GetLeaveMessageNum();this.GetCommentNum();
}7、提高传输效率
chrome最多同时发6个请求，如果需要同时发起7个请求，第7个就要等待前6个结束。可SPA同时发起7个请求可太常见了。
于是我将HTTP/1升级到HTTP/2，做到单 TCP 连接上并行传输多个请求/响应。原理如下，告别了network里同时并行一堆请求的历史
原理
network效果
nginx的配置超级简单，只需要一行：
server {listen 443 ssl http2;
}五：最终效果
哥们的网站CodingLife，最终效果不管移动端还是PC端都是秒开。摸索了4天，最终看到Lighthouse打分99时，我跟个傻子一样哈哈大小，那是真的开心！
打开F12的network可以看到如下差别，不提速是不可能的啦
- 请求的JS文件条数明显少了（按需加载，只加载首屏js）
- JS资源文件最大的也就700k（Gzip压缩）
- 图片大都100k以内（webp格式图片）
- 请求的图片条数明显减少（动态设置列表条数）
- 发起的接口请求明显减少（删除移动端无用请求）
- 请求缩略图只有一条（启用http/2）