Lighthouse与首屏优化

之前提到首屏优化，想到的就是Vue项目首页打开很慢需要优化。一般都是肉眼看看，对当前的加载速度并没有一个准确的衡量标准，也没有很清晰的解决思路。

前两天我想给自己的网站申请谷歌广告，听说审核对网站的性能要求很高。于是网上搜索后发现了一个网站优化利器--Lighthouse

可以先看下我优化后的效果：CodingLife

一：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 => {
    // 禁用所有 prefetch
    config.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）

六：案例二

首先优化后的结果演示：Coding Admin

因为精力和时间有限，以前一直未对我个人网站的管理后台做首屏优化和SEO。

前两天发现，首屏加载将近3s，加载页面时等的心焦，忍无可忍就给他优化了下。

1、优化前效果

首屏加载将近3S

最大JS文件2.4M

2、优化后

首屏加载将近0.9S

最大JS文件：607KB

3、优化措施

因为个人网站需要建设的太多，没在管理后台性能优化上花太多时间。只做了两点

• 前端打包时进行GZIP压缩处理
• 服务端启用返回GZIP文件

如上两步具体操作请参考上文。

只做了如上两步vendor.js从原来的2.4M，压缩到600k。其实 vendor.js资源文件，可以做进一步的拆分。但webpack3拆分完还要控制js的加载顺序，比较麻烦，我没做彻底。等有精力时再说。