當前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

⚡性能优化之首屏秒开

發布時間：2024/1/8 编程问答 34 豆豆

生活随笔收集整理的這篇文章主要介紹了 ⚡性能优化之首屏秒开小編覺得挺不錯的,現在分享給大家,幫大家做個參考.

背景

最近做了c端的h5產品，上線后，部分用戶投訴說打開很慢，經過調查發現，在網速慢的情況下，部分用戶首屏展示需要5-10s，網速快的情況也要將近3s。

在對項目做了一些優化處理后，再次無緩存打開可以發現網頁幾乎是秒開，平均耗時在1s以內

在這里總結記錄一下，基本上都是一些常規可復制的優化手段，希望能為同樣想優化網頁性能的你提供思路~

更多學習案例盡在我的github

這是優化前的效果：

這是優化過后的效果：

關于優化

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

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

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

目標

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

這里我定下的目標是

正常網速下，2s內加載完成

指標和檢測分析工具

常用指標

關于指標這塊，簡單介紹下常見指標：

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

分析工具

Network分析

Lighthouse分析

Webpack Bundle分析

優化方案

優化體積

優化前 chunk.js 2.3m
優化后 chunk.js 860kb

優化包

? 優化Ant-design-icon體積

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

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

優化前：529kb 優化后：20kb

? 刪除冗余組件

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

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

優化前：500kb 優化后：0

? 部分庫按需引入

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

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

優化前：550kb 優化后：120kb

? 使用webp

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

? 優化core-js體積

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

presets: [“@vue/app”]

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

優化前：104kb 優化后 68kb

網絡傳輸優化

?優化分包策略

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

optimization: isProd ? {splitChunks: {chunks: 'all',maxInitialRequests: Infinity, // 默認為3，調整為允許無限入口資源minSize: 20000, // 20K以下的依賴不做拆分cacheGroups: {vendors: {// 拆分依賴，避免單文件過大拖慢頁面展示// 得益于HTTP2多路復用，不用太擔心資源請求太多的問題name(module) {// 拆包const packageName = module.context.match(/[\\/]node_modules[\\/](.*?)([\\/]|$)/)[1]// 進一步將Ant組件拆分出來,請根據情況來// const packageName = module.context.match(/[\\/]node_modules[\\/](?:ant-design-vue[\\/]es[\\/])?(.*?)([\\/]|$)/)[1]return `npm.${packageName.replace('@', '')}` // 部分服務器不允許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安裝命令后，安裝失敗的話需要調整

cnpm --save install image-webpack-loader

這里就會看到gifsicle已經安裝好了

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的數據壓縮deleteOriginalAssets: false // 不刪除源文件}))}, }

? 預請求預加載

? 開啟HTTP2

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

? 托管至OSS + CDN加速

當應對一些弱網地區時，OSS + CDN無疑是很強力的提速手段。

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

SSR

想要更快可以使用ssr服務端渲染，關于服務端渲染可以看我的另一篇文章。

這里貼上ssr的首頁加載速度，可以看到沒緩存的情況下快了幾倍。頁面直接返回了Html內容。

體驗優化

預渲染

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

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

骨架屏

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

漸進加載圖片

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

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

結尾

以上就是關于指標檢測和具體優化方案，談到優化其實還有構建優化，緩存優化等等…

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

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

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

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。