背景

最近做了c端的h5產(chǎn)品，上線后，部分用戶投訴說打開很慢，經(jīng)過調(diào)查發(fā)現(xiàn)，在網(wǎng)速慢的情況下，部分用戶首屏展示需要5-10s，網(wǎng)速快的情況也要將近3s。

在對項目做了一些優(yōu)化處理后，再次無緩存打開可以發(fā)現(xiàn)網(wǎng)頁幾乎是秒開，平均耗時在1s以內(nèi)

在這里總結(jié)記錄一下，基本上都是一些常規(guī)可復(fù)制的優(yōu)化手段，希望能為同樣想優(yōu)化網(wǎng)頁性能的你提供思路~

更多學習案例盡在我的github

這是優(yōu)化前的效果：

這是優(yōu)化過后的效果：

---

關(guān)于優(yōu)化

在開始之前，我們需要明白一個原則：性能優(yōu)化的最終目的是提升用戶體驗。

簡而言之就是讓用戶感覺這個網(wǎng)站很「快」（至少不慢hh），這里的「快」有兩種，一種是「真的快」一種是「覺得快」

「真的快」：可以客觀衡量的指標，像網(wǎng)頁訪問時間、交互響應(yīng)時間、跳轉(zhuǎn)頁面時間
「覺得快」：用戶主觀感知的性能，通過視覺引導等手段轉(zhuǎn)移用戶對等待時間的關(guān)注
做好這兩方面都能提升用戶對網(wǎng)站的性能評價。

---

目標

首先我們需要確定目標，根據(jù)場景和項目復(fù)雜度不同，制定的目標也不同，比如希望比競品快20%，或者符合標準的"2-5-10"原則等等

這里我定下的目標是

正常網(wǎng)速下，2s內(nèi)加載完成

---

指標和檢測分析工具

常用指標

關(guān)于指標這塊，簡單介紹下常見指標：

• FCP（First Contentful Paint）：白屏時間（第一個文本繪制時間）
• Speed Index：首屏時間
• TTI（Time To Interactive）: 第一次可交互的時間
• lighthouse score（performance）：Chrome瀏覽器審查工具性能評分（也可以npm install -g lighthouse，編程式調(diào)用）

---

分析工具

Network分析

---

Lighthouse分析

---

Webpack Bundle分析

---

優(yōu)化方案

優(yōu)化體積

優(yōu)化前 chunk.js 2.3m
優(yōu)化后 chunk.js 860kb

優(yōu)化包

? 優(yōu)化Ant-design-icon體積

這一部分，由于我們在項目中只使用了幾個Ant內(nèi)置圖標，不可能有530+KB。根據(jù)Ant文檔的描述是由于其將ICON全量引入的關(guān)系導致的，說法是當前用法如果按需加載的話無法確定使用者會不會在運行時改變icon，比如配置的ICON。

所以決定去掉這部分，改成本地的svg。

優(yōu)化前：529kb 優(yōu)化后：20kb

---

? 刪除冗余組件

部分組件是不經(jīng)常用的，但卻使用了Vue.use()全局引入了。這里去掉不常用和沒用到的全局引入，改為頁面內(nèi)import()引入

看到ant-design-select, upload只有單獨的頁面用到。放到頁面里面去引用，不放在總包里面了。

優(yōu)化前：500kb 優(yōu)化后：0

---

? 部分庫按需引入

由于我們只用了，輪播圖和提示窗，mint-ui按需引入。

crypto-js 因為我們只用了一個算法，就按需引入單獨的sha256算法
import {HmacSHA256} from ‘crypto-js’

優(yōu)化前：550kb 優(yōu)化后：120kb

---

? 使用webp

webP是谷歌推出的新圖片格式（2010），同等質(zhì)量下體積拳打png腳踢jpg，目前兼容性還算可以，就蘋果家的表現(xiàn)不太理想

---

? 優(yōu)化core-js體積

core-js實際上就是瀏覽器新API的polyfill，項目是PC端，所以主要是為了兼容IE…

presets: [“@vue/app”]

改成
presets: [
‘@vue/app’,
[
‘@babel/preset-env’,
{
‘useBuiltIns’: ‘entry’
}
]
],

優(yōu)化前：104kb 優(yōu)化后 68kb

---

網(wǎng)絡(luò)傳輸優(yōu)化

?優(yōu)化分包策略

vue-cli3的默認優(yōu)化是將所有npm依賴都打進chunk-vendor，但這種做法在依賴多的情況下導致chunk-vendor過大

optimization: isProd ? {splitChunks: {chunks: 'all',maxInitialRequests: Infinity, // 默認為3，調(diào)整為允許無限入口資源minSize: 20000, // 20K以下的依賴不做拆分cacheGroups: {vendors: {// 拆分依賴，避免單文件過大拖慢頁面展示// 得益于HTTP2多路復(fù)用，不用太擔心資源請求太多的問題name(module) {// 拆包const packageName = module.context.match(/[\\/]node_modules[\\/](.*?)([\\/]|$)/)[1]// 進一步將Ant組件拆分出來,請根據(jù)情況來// const packageName = module.context.match(/[\\/]node_modules[\\/](?:ant-design-vue[\\/]es[\\/])?(.*?)([\\/]|$)/)[1]return `npm.${packageName.replace('@', '')}` // 部分服務(wù)器不允許URL帶@},test: /[\\/]node_modules[\\/]/,priority: -10,chunks: 'initial'}}},runtimeChunk: { name: entrypoint => `runtime-${entrypoint.name}` } } : {}

---

? Gzip壓縮傳輸和圖片打包壓縮

圖片壓縮 并且開啟gzip
gzip加速
第一步安裝依賴：
npm install --save-dev compression-webpack-plugin
這樣會安裝最新的版本，如果你webpack版本過低，則會安裝失敗。
這里就需要降低compression-webpack-plugin版本，這里我使用的是5.0.1版本
npm install --save–dev compression-webpack-plugin@5.0.1
圖片資源壓縮

npm install --save image-webpack-loader

使用npm安裝命令后，安裝失敗的話需要調(diào)整

cnpm --save install image-webpack-loader

這里就會看到gifsicle已經(jīng)安裝好了

const CompressionPlugin = require("compression-webpack-plugin") module.exports = { chainWebpack: config => {//最小化代碼config.optimization.minimize(true);//分割代碼config.optimization.splitChunks({chunks: 'all'});//開啟圖片壓縮config.module.rule('images').test(/\.(png|jpe?g|gif|svg)(\?.*)?$/).use('image-webpack-loader').loader('image-webpack-loader').options({ bypassOnDebug: true })//開啟gzip加速config.plugin('compressionPlugin').use(new CompressionPlugin({test: /\.js$|\.html$|.\css$|\.otf$|\.ttf/, // 匹配文件名threshold: 102400, // 對超過100kb的數(shù)據(jù)壓縮deleteOriginalAssets: false // 不刪除源文件}))}, }

---

? 預(yù)請求預(yù)加載

<link>標簽的rel屬性的兩個可選值。
Prefetch，預(yù)請求，是為了提示瀏覽器，用戶未來的瀏覽有可能需要加載目標資源，所以瀏覽器有可能通過事先獲取和緩存對應(yīng)資源，優(yōu)化用戶體驗。
Preload，預(yù)加載，表示用戶十分有可能需要在當前瀏覽中加載目標資源，所以瀏覽器必須預(yù)先獲取和緩存對應(yīng)資源。

---

? 開啟HTTP2

HTTP2是HTTP協(xié)議的第二個版本，相較于HTTP1 速度更快、延遲更低，功能更多。
目前來看兼容性方面也算過得去，在國內(nèi)有超過50%的覆蓋率。
通常瀏覽器在傳輸時并發(fā)請求數(shù)是有限制的，超過限制的請求需要排隊，以往我們通過域名分片、資源合并來避開這一限制，而使用HTTP2協(xié)議后，其可以在一個TCP連接分幀處理多個請求（多路復(fù)用），不受此限制。（其余的頭部壓縮等等也帶來了一定性能提升）
如果網(wǎng)站支持HTTPS，請一并開啟HTTP2，成本低收益高，對于請求多的頁面提升很大，尤其是在網(wǎng)速不佳時

---

? 托管至OSS + CDN加速

當應(yīng)對一些弱網(wǎng)地區(qū)時，OSS + CDN無疑是很強力的提速手段。

海量，安全，低成本，高可靠的云存儲服務(wù)。可以通過簡單的REST接口，在任何時間、任何地點上傳和下載數(shù)據(jù)，也可以使用WEB頁面對數(shù)據(jù)進行管理。

---

SSR

想要更快可以使用ssr服務(wù)端渲染，關(guān)于服務(wù)端渲染可以看我的另一篇文章。

這里貼上ssr的首頁加載速度，可以看到?jīng)]緩存的情況下快了幾倍。頁面直接返回了Html內(nèi)容。

---

體驗優(yōu)化

預(yù)渲染

預(yù)渲染是一個方案，使用爬蟲技術(shù)。由于我們打包過后的都是一些js文件，使用一些技術(shù)（puppeteer）可以爬取到項目在chrome瀏覽器展示的頁面，然后把它寫入js,和打包文件一起。類似prerender-spa-plugin

不過這種技術(shù)的缺點也很明顯，我們在打包過程中，所展示的頁面是當時環(huán)境下的數(shù)據(jù)，也就是說如果首頁有很多的動態(tài)獲取的數(shù)據(jù)（比如說實時的股票價格），那如果采用這種方案，用戶第一眼看到并不是當時數(shù)據(jù)，會認為是個錯誤信息

---

骨架屏

首屏優(yōu)化，APP內(nèi)常見的加載時各部分灰色色塊。針對骨架屏頁的自動化生成，業(yè)界已有不少解決方案。

---

漸進加載圖片

一般來說，圖片加載有兩種方式，一種是自上而下掃描，一種則是原圖的模糊展示，然后逐漸/加載完清晰。前者在網(wǎng)速差的時候用戶體驗較差，后者的漸進/交錯式加載則能減輕用戶的等待焦慮，帶來更好的體驗

先加載小圖，模糊化渲染，圖片加載完成后替換為原圖，最典型的例子就是Medium，模糊化可以用filter或者canvas處理

---

結(jié)尾

以上就是關(guān)于指標檢測 和具體優(yōu)化方案，談到優(yōu)化其實還有構(gòu)建優(yōu)化，緩存優(yōu)化等等…

性能優(yōu)化影響的，不僅是用戶體驗，還影響了轉(zhuǎn)化率、搜索引擎排名，這些因素都會對最終的流量、銷量等收入造成影響

來自Google的數(shù)據(jù)表明，一個有10條數(shù)據(jù)0.4秒能加載完的頁面，變成30條數(shù)據(jù)0.9秒加載完之后，流量和廣告收入下降90%。

Google Map 首頁文件大小從100KB減小到70-80KB后，流量在第一周漲了10%，接下來的三周漲了25%。

亞馬遜的數(shù)據(jù)表明：加載時間增加100毫秒，銷量就下降1%。

總結(jié)

以上是生活随笔為你收集整理的⚡性能优化之首屏秒开的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。