之前提到首屏優(yōu)化，想到的就是Vue項(xiàng)目首頁打開很慢需要優(yōu)化。一般都是肉眼看看，對當(dāng)前的加載速度并沒有一個(gè)準(zhǔn)確的衡量標(biāo)準(zhǔn)，也沒有很清晰的解決思路。

前兩天我想給自己的網(wǎng)站申請谷歌廣告，聽說審核對網(wǎng)站的性能要求很高。于是網(wǎng)上搜索后發(fā)現(xiàn)了一個(gè)網(wǎng)站優(yōu)化利器--Lighthouse

一：Lighthouse是什么？

Lighthouse 是一個(gè)由?Google 開發(fā)的開源自動(dòng)化工具，用于改進(jìn)網(wǎng)頁質(zhì)量。它提供全面的網(wǎng)頁性能、可訪問性、最佳實(shí)踐和 SEO 分析，幫助開發(fā)者構(gòu)建更好的網(wǎng)站體驗(yàn)。

Lighthouse這個(gè)工具前端開發(fā)者又熟悉又陌生，說她熟悉因?yàn)樗驮贑hrome的F12面板中，跟Network在一塊。說她陌生是因?yàn)?#xff0c;可能大多程序員沒注意到她，也不知道她是干什么用的。

Lighthouse使用起來很簡單，F12里找到她，輸入需要檢測的網(wǎng)站即可。我第一次使用時(shí)的得分如下

二：Lighthouse的相關(guān)指標(biāo)

1、主要指標(biāo)

如上截圖中主要4個(gè)指標(biāo)，相關(guān)概念如下

性能 (Performance)	頁面加載速度和用戶體驗(yàn)	包含F(xiàn)CP, LCP, TTI, TBT, CLS
可訪問性 (Accessibility)	殘障用戶友好度	屏幕閱讀器支持，色彩對比度，ARIA 屬性
最佳實(shí)踐 (Best Practices)	現(xiàn)代Web開發(fā)標(biāo)準(zhǔn)	HTTPS, 安全的API使用，圖片優(yōu)化
SEO (Search Engine Optimization)	搜索引擎優(yōu)化	元標(biāo)簽，結(jié)構(gòu)化數(shù)據(jù)，移動(dòng)友好性

2、性能(Performance)下的指標(biāo)

• FCP (First Contentful Paint)??首個(gè)內(nèi)容繪制時(shí)間

?測量頁面首個(gè)元素呈現(xiàn)的時(shí)間，讓用戶知道網(wǎng)站開始載入了。

• LCP (Largest Contentful Paint)?最大內(nèi)容繪制時(shí)間

?測量頁面主要內(nèi)容加載完成的時(shí)間，讓用戶知道網(wǎng)站載入完畢，可以交互了。

• CLS (Cumulative Layout Shift)?累積布局偏移

?測量頁面內(nèi)容意外移動(dòng)的程度，比如一個(gè)按鈕在點(diǎn)擊時(shí)因其他元素加載突然下移了。

3、指標(biāo)作用

通過這些指標(biāo)得分，我們可以量化的知道自己網(wǎng)站的性能效果。有一個(gè)參考值，便于針對性的優(yōu)化。

三：優(yōu)化建議

Lighthouse的每個(gè)指標(biāo)都有對應(yīng)的優(yōu)化建議，如下圖。如圖右上角可以切換各個(gè)指標(biāo)

四：成功實(shí)踐

我根據(jù)Lighthouse的建議，針對性的做了相關(guān)的措施。最終成績?nèi)缦?#xff0c;我網(wǎng)站效果為CodingLife，忙活了4天結(jié)果還算滿意~

先說下我服務(wù)器的配置，2核2G 3M帶寬。為了節(jié)省費(fèi)用，配置堪稱寒酸！

1、分割打包 按需加載

首先要在路由配置中，使用按需加載與分包設(shè)置

// router.js文件中
routes: [{path: '/',name: 'BlogDetail',component: () => import(/* webpackChunkName: "blogDetail", webpackPrefetch: false */ '@/components/MainPage/BlogDetail');}
]

其次一定要配合webpack配置，否則很可能無法按需加載。即首頁渲染時(shí)，加載其他頁面的js包

// vue.config.js文件
module.exports = {chainWebpack: config => {// 禁用所有 prefetchconfig.plugins.delete('prefetch');}
};

2、壓縮資源包體積

將JS資源文件打包為.gz格式，可以高效減少資源包體積。shezhi前端webpack打包時(shí)，就做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的數(shù)據(jù)deleteOriginalAssets:false, // 不刪除壓縮前的文件，如果瀏覽器不支持Gzip，則會(huì)加載源文件minRatio:0.8 // 壓縮比大于0.8的文件將不會(huì)被壓縮}));}
};

Nginx服務(wù)器，配合設(shè)置

server {gunzip on;       # 如果客戶端不支持 gzip，自動(dòng)解壓返回原始文件gzip off;        # 關(guān)閉動(dòng)態(tài)壓縮（因?yàn)橐呀?jīng)有預(yù)壓縮文件）
}

3、減小圖片體積

圖片使用webp格式，可以大幅減小圖片體積。使用webp主要工作在ngnix上，具體操作如下

安裝cwebp，處理圖片

# 下載最新版源碼（當(dāng)前最新版本1.3.0）
wget https://storage.googleapis.com/downloads.webmproject.org/releases/webp/libwebp-1.3.0.tar.gz# 解壓并進(jìn)入目錄
tar -xvzf libwebp-1.3.0.tar.gz
cd libwebp-1.3.0# 配置編譯選項(xiàng)（確保啟用PNG和JPEG支持）
./configure --enable-libpng --enable-libjpeg# 編譯并安裝
make
sudo make install# 刷新庫緩存
sudo ldconfig# 驗(yàn)證安裝
cwebp -version

配置nginx有限返回webp格式圖片

http {# 簡化的WebP檢測map $http_accept $webp_suffix {default   "";"~*webp"  ".webp";  # 添加.webp后綴}# HTTPS 服務(wù)器 - 主配置server {listen 443 ssl http2;server_name codinglife.online www.codinglife.online;location /uploads/ {alias /opt/CodingLife/uploads/;autoindex off;# 核心緩存策略（根據(jù)文件類型區(qū)分）location ~* \.(jpe?g|png|gif|webp|svg|avif)$ {		try_files $uri$webp_suffix $uri =404;add_header Vary Accept;  # 關(guān)鍵：標(biāo)記內(nèi)容協(xié)商}}}
}

4、減少圖片請求數(shù)量

我的博客首頁是個(gè)列表，列表的每條都包含一個(gè)縮略圖，剛開始設(shè)置每頁8條數(shù)據(jù)。8個(gè)圖片，對于3M的帶寬來說，壓力太大。

于是我將分頁請求中每頁條數(shù)精細(xì)化，根據(jù)設(shè)備分辨率動(dòng)態(tài)設(shè)置。比如移動(dòng)端每頁3條，筆記本電腦每頁4條，外接顯示器8條。

  calculatePageSize() {if (this.windowWidth < 1366) {this.perPageNum = 3 // 移動(dòng)端和小屏設(shè)備} 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

因?yàn)長ighthouse還模擬移動(dòng)設(shè)備測試首屏性能，并且模擬條件極為苛刻。具體如下

• Desktop：默認(rèn)使用?150ms TCP延遲的"有線"網(wǎng)絡(luò)?(類似穩(wěn)定WiFi/光纖)。

• Mobile：默認(rèn)使用?300ms TCP延遲 + 1.6Mbps下載/0.75Mbps上傳的"慢速4G"網(wǎng)絡(luò)。

我的網(wǎng)站使用媒體查詢，自適應(yīng)移動(dòng)端和pc端。因?yàn)橐苿?dòng)端屏幕大小有限，我選擇隱藏了很多不必要的模塊。但原有的css設(shè)置隱藏是奢侈的，依舊消耗性能，我本次將無用的dom需要徹底刪掉。

<section v-if="isDeskTop"></section>data: function () {return {isDeskTop: window.innerWidth > 768 // 是否是桌面端}
},

6、剔除無用請求

以前適配移動(dòng)端時(shí)大大咧咧，只想著實(shí)現(xiàn)效果就行。很多無用模塊都是css配置display:none，js接口正常請求，現(xiàn)在看來是真的浪費(fèi)。本次我又精細(xì)化的過了一遍，移動(dòng)端時(shí)刪除不必要的接口請求。

// 移動(dòng)端時(shí)刪除不必要的接口請求
if(this.isDeskTop){      //渲染留言個(gè)數(shù)this.GetLeaveMessageNum();this.GetCommentNum();
}

7、提高傳輸效率

chrome最多同時(shí)發(fā)6個(gè)請求，如果需要同時(shí)發(fā)起7個(gè)請求，第7個(gè)就要等待前6個(gè)結(jié)束?？蒘PA同時(shí)發(fā)起7個(gè)請求可太常見了。

于是我將HTTP/1升級到HTTP/2，做到單 TCP 連接上并行傳輸多個(gè)請求/響應(yīng)。原理如下，告別了network里同時(shí)并行一堆請求的歷史

原理

network效果?

nginx的配置超級簡單，只需要一行：

server {listen 443 ssl http2;
}

五：最終效果

哥們的網(wǎng)站CodingLife，最終效果不管移動(dòng)端還是PC端都是秒開。摸索了4天，最終看到Lighthouse打分99時(shí)，我跟個(gè)傻子一樣哈哈大小，那是真的開心！

打開F12的network可以看到如下差別，不提速是不可能的啦

• 請求的JS文件條數(shù)明顯少了（按需加載，只加載首屏js）
• JS資源文件最大的也就700k（Gzip壓縮）
• 圖片大都100k以內(nèi)（webp格式圖片）
• 請求的圖片條數(shù)明顯減少（動(dòng)態(tài)設(shè)置列表?xiàng)l數(shù)）
• 發(fā)起的接口請求明顯減少（刪除移動(dòng)端無用請求）
• 請求縮略圖只有一條（啟用http/2）