BI 數(shù)據(jù)可視化平臺建設（3）—首頁性能提升實踐
本文是vivo互聯(lián)網(wǎng)大數(shù)據(jù)團隊《BI 數(shù)據(jù)可視化平臺建設》系列文章第3篇。
隨著越來越多代碼的堆積，平臺的運行加載性能也在逐步下降，在不同程度上極大地影響了用戶體驗，從而導致用戶流失。本文就是從這樣的一個背景出發(fā)，通過對BI數(shù)據(jù)可視化平臺的一系列的性能優(yōu)化實踐，給大家系統(tǒng)性闡述首頁性能優(yōu)化的核心策略，并探討在日常開發(fā)中如何實現(xiàn)長效性能保障。
往期系列文章：
一、背景
隨著業(yè)務的拓展和用戶數(shù)量的激增，平臺經(jīng)歷了多個周期的快速迭代，整體功能場景也越發(fā)復雜的。在快速迭代的過程中，我們很容易忽略平臺的性能，到了某一個節(jié)點，猛地發(fā)現(xiàn)，隨著越來越多代碼的堆積，平臺的運行加載性能也在逐步下降，在不同程度上極大地影響了用戶體驗，從而導致用戶流失。本文就是從這樣的一個背景出發(fā)，通過對BI數(shù)據(jù)可視化平臺的一系列的性能優(yōu)化實踐，給大家分享一下如何提升首頁性能的思路，并且讓我們在日常開發(fā)中，如何持續(xù)保持高性能，而不是又一次回過頭來優(yōu)化性能。本文主要給大家介紹一平臺在進行首頁性能提升的一些實踐經(jīng)驗。
二、了解性能指標
2.1 用戶體驗核心指標
衡量一個 Web 頁面的體驗和質量有非常多的指標，根據(jù)頁面加載流程可以將指標分成三大類：
- 文檔加載相關（TTFB、DCL等）
- 內(nèi)容呈現(xiàn)相關（LCP、FCP、FMP 等）
- 交互響應相關（INP、FPS 等）
針對這么多的性能指標，Google 提出了網(wǎng)站用戶體驗的三大核心指標 (LCP INP CLS)，分別用來衡量用戶感知的加載速度、量化網(wǎng)頁首次互交互的感受、衡量網(wǎng)頁視覺的穩(wěn)定性：
圖片來源：https://web.dev/
2.2 平臺度量指標
但是在實際規(guī)劃平臺性能度量體系時，我們可以根據(jù)自身的業(yè)務和需求進行自定義，針對數(shù)據(jù)可視化平臺來說，我們更看重用戶感知的加載速度，如何讓用戶快速看到數(shù)據(jù)可視化內(nèi)容是我們首頁性能優(yōu)化的關鍵，因此我們性能指標主要以文檔加載和內(nèi)容呈現(xiàn)為主，這里我們以 TTFB、FCP、LCP 作為我們首頁性能的度量指標，它們涵蓋了網(wǎng)絡請求到頁面主要內(nèi)容加載的過程：
網(wǎng)絡請求過程（網(wǎng)絡響應衡量指標 TTFB）：
TTFB 主要指的是以下請求階段耗時的總和：
- 重定向時間
- Service Worker 啟動時間（如果有）
- DNS 查找
- 連接和 TLS 協(xié)商
- 請求，直到響應的第一個字節(jié)到達
頁面主要內(nèi)容加載過程（內(nèi)容呈現(xiàn)衡量指標 FCP、LCP）：
圖片來源：https://web.dev/
- TTFB(Time to First Byte )：
它主要測量的是在網(wǎng)絡請求階段中，從請求資源到響應的第一個字節(jié)到達所經(jīng)過的時間，這有助于識別 Web 服務器因速度過慢而無法響應請求。由于 TTFB 發(fā)生在指標 FCP(First Contentful Paint ) 和 LCP(Largest Contentful Paint）之前，因此希望服務器能夠快速地響應導航請求。一般來說，大多數(shù)網(wǎng)站都應盡量將 TTFB 控制在 0.8秒 以內(nèi)，且超過75%以上PV 達到該范圍。
圖片來源：https://web.dev/
- FCP(First Contentful Paint)：
它用于標記網(wǎng)頁加載過程中用戶可以在屏幕上看到的第一個元素所用的時間。元素主要是指文本、圖片（包括背景圖片）、SVG 或 Canvas。可以用于衡量用戶感知的加載速度。為了提供良好的用戶體驗，網(wǎng)站的 FCP 最好不要超過 1.8 秒，且確保超過75%以上PV 達到該范圍。
圖片來源：https://web.dev/
- LCP(Largest Contentful Paint)：
它用于標記網(wǎng)頁加載過程中加載了網(wǎng)頁主要內(nèi)容的時間點。可以用于衡量用戶感知的加載速度，也是Google 提出的度量用戶體驗的三大核心指標之一。為了提供良好的用戶體驗，網(wǎng)站的 LCP 最好控制在 2.5 秒 以內(nèi)，且確保超過75%以上PV 達到該范圍。
圖片來源：https://web.dev/
三、首頁性能現(xiàn)狀
背景：性能問題主要是由于前期開發(fā)人力有限、功能快速迭代等原因，導致代碼質量和可維護性較差，積累下的技術債務。
（1）平臺性能指標分析：LCP(首屏平均耗時) 高達3.3s，遠高于Google LCP衡量的標準（2.5s）。
（2）通過Lighthouse工具進行性能分析，性能得分較低，各項性能指標都處于不及格的水平。
四、分析性能問題
4.1 通過Network面板分析
從Network面板上，可以分析得出加載過程中存在以下幾類問題：
- 入口文件體積太大，加載耗時長，阻塞其他資源加載
- 低優(yōu)先級資源阻塞了高優(yōu)先級資源加載
- 微前端子應用等非首屏依賴資源沒有進行異步加載
- 網(wǎng)絡傳輸協(xié)議還處于HTTP1.1，傳輸效率低
- 接口請求傳輸?shù)臄?shù)據(jù)體過大，存在大量冗余數(shù)據(jù)
4.2 通過Performance面板分析
從 Performance 面板上，可以分析得出加載過程中存在以下幾類問題：
- FPS 長時間出現(xiàn)紅色條形，表示幀速率下降得太低，可能出現(xiàn)動畫延遲卡頓等問題
- CPU 資源占用率過高，可能出現(xiàn)性能問題
- 主線程存在多個 Long Task(長任務)，阻塞了頁面加載渲染
4.3 通過Lighthouse工具分析
通過 Lighthouse 工具，可以分析得出加載過程中存在以下的問題：
- 大量 Long Task 阻塞了主線程工作
- 存在阻塞渲染的低優(yōu)先級資源
- DOM節(jié)點數(shù)過多，增加了內(nèi)存占用，樣式計算用時延長，并產(chǎn)生高昂的布局重排成本
- 圖片資源不是最優(yōu)壓縮效果的格式
- 存在大量未使用的CSS和JS文件代碼
五、優(yōu)化實踐
5.1 優(yōu)化方向 (時間和空間)
通過上述的問題分析，我們可以分析出資源加載渲染耗時以及瀏覽器性能資源占有 都有可能導致頁面卡頓緩慢，影響用戶體驗，因此可以從耗時和資源占用兩方面來進行性能優(yōu)化，也可以理解成時間和空間的優(yōu)化。
5.2 時間優(yōu)化 (網(wǎng)絡耗時、加載耗時、渲染耗時等)
（1）網(wǎng)絡傳輸耗時優(yōu)化
網(wǎng)絡傳輸耗時優(yōu)化主要可以從 緩存策略、傳輸協(xié)議、資源預加載預解析、CDN 等幾個方向進行。本次優(yōu)化主要是通過網(wǎng)絡傳輸升級、資源預加載、請求性能優(yōu)化等方面來講解一下。
- 網(wǎng)絡傳輸協(xié)議升級，由 HTTP/1.1 升級至 HTTP/2.0 版本，通過 HTTP/2.0 多路復用的特性解決了請求并發(fā)數(shù)限制的問題，同時二進制傳輸和頭部壓縮等特性也提高了網(wǎng)絡傳輸?shù)男省?/span>
- 刪除資源預加載（Preload），減少首頁非關鍵資源的預加載處理。通過加載瀑布流可以看到，這里提前加載了多個非首屏關鍵資源的字體文件，且文件體積高達 1.8MB，阻塞了首屏關鍵資源的加載解析。所以我們需要根據(jù)資源的優(yōu)先級，合理的使用 Preload(預加載)和 Prefetch(預解析)。
- 請求性能優(yōu)化，降低請求響應耗時。通過Network面板可以看到，首頁依賴的主要接口返回的數(shù)據(jù)體在沒壓縮前高達 3.1 MB，這里我們對請求內(nèi)容進行了分析，通過異步請求、減少非關鍵的冗余數(shù)據(jù)等處理將傳輸數(shù)據(jù)體積降低到了 500KB 內(nèi)。除了減少數(shù)據(jù)傳輸量，我們還可以通過請求合并，利用緩存等減少通信次數(shù)來進行請求性能優(yōu)化。
（2）資源加載耗時優(yōu)化
資源加載耗時優(yōu)化可以從 代碼壓縮、代碼分包、組件、工具庫、ICON等按需加載等幾個方向進行。主要是通過優(yōu)化體積來減少資源加載耗時，從而提升首屏性能。
- 首先通過 webpack-bundle-analyzer 插件對包體積進行分析，可以看到 chunk-vendors.js 文件體積較大，同時還存在依賴嵌套等問題，導致資源加載緩慢。本次優(yōu)化我們通過代碼分包、資源按需加載，圖片格式優(yōu)化等措施，減少了資源體積， chunk-vendors.js 文件也從 2.3MB 降低到 480KB。下面我們通過幾個具體示例進行講解：
- 對 Echarts 、Ant-Design-Vue-1.x ICON等UI工具庫進行按需加載。
// 優(yōu)化前 在入口文件進行全量的同步加載
import \* as echarts from 'echarts/core';
import { XXXChart } from 'echarts/charts';
import { XXXComponent } from 'echarts/components';
import { CanvasRenderer } from 'echarts/renderers';
echarts.use(\[XXXChart, XXXComponent, CanvasRenderer\]);
// 優(yōu)化后 根據(jù)使用場景進行按需加載
async function initEcharts(chartType){
const echarts = await import('echarts/core');
const { XXXChart} = await import('echarts/charts');
const { XXXComponent } = await import('echarts/components');
const { CanvasRenderer } = await import('echarts/renderers');
echarts.use(\[XXXChart, XXXComponent, CanvasRenderer\]);
}由于歷史需求迭代原因，我們對 Ant-Design-Vue-1.x 進行了二次定制開發(fā)，這也導致了ICON全量引入，我們這里使用的方案是重定向到本地文件來進行控制 ，使用 alias 將 @ant-design/icons/lib/dist 指向項目中的 antdIcon.js，然后在 antdIcon.js 文件中按需導出即可，通過按需加載，ICON引入體積從 500K+ 降低到 30K+。
// vue.config.js alias配置
resolve: {
alias: {
'@ant-design/icons/lib/dist$': path.resolve(\_\_dirname, './src/plugins/antdIcons.js'),
}
}
// src/plugins/antdIcons.js
export { default as CheckCircleOutline } from '@ant-design/icons/lib/outline/CheckCircleOutline';
export { default as CheckCircleFill } from '@ant-design/icons/lib/fill/CheckCircleFill';- 檢查刪除冗余依賴，避免重復npm包引入；隨著平臺長期的發(fā)展迭代，或多或少都會存在冗余的 mf、npm 資源，同時我們在對微前端子應用的包體積進行分析時，發(fā)現(xiàn)子應用通過 npm 引入的Echarts，而主應用本身也引入相同的庫，相對于引入了2 遍 Echarts，這個時候我們改造了子應用的依賴引入方式，通過傳參的方式將Echarts實例傳遞給子應用，避免重復引入和加載相同資源。
//主應用 通過props傳遞依賴
import { start, loadMicroApp, prefetchApps } from 'qiankun';
export default {
name: 'MicroWidgetReact',
methods: {
async loadMicroApp(){
const $echarts = await this.$initEcharts();
this.microApp = loadMicroApp({
name: \`xxx\`,
props: {
...props,
$echarts: $echarts,
},
});
},
},
};
//子應用配置 externals 并且外鏈依賴加上 ignore 屬性（這是自定義的屬性，非標準屬性）
<script ignore src\="https://cdn.jsdelivr.net/npm/echarts@5.5.0/dist/echarts.min.js"\></script>
// 當它獨立運行時，使用自己的外鏈依賴 window.$echarts
const $echarts = parent.$echarts || window.$echarts;- 對圖片、字體等資源文件進行格式優(yōu)化；我們將圖片資源統(tǒng)一轉換成WEBP格式，除了文件大小和壓縮效率上有優(yōu)勢，WEBP還支持透明度和動態(tài)圖像等，所以如果不需要考慮 IE以及舊版本Safri的兼容性，WebP 格式更適用于網(wǎng)頁開發(fā)；而字體文件則轉換成WOFF2格式，對比 TTF 格式在文件大小、壓縮效率和安全性上都更具優(yōu)勢。
5.3 空間優(yōu)化 (CPU 占用、內(nèi)存占用、本地緩存等)
我們在做性能優(yōu)化的時候，很多情況下都會依賴時間換空間、或者空間換時間等方式，這里需要根據(jù)項目的實際情況做出取舍，選擇相對合適的一種方案去進行優(yōu)化。資源占用常見的優(yōu)化方式包括：
- 代碼優(yōu)化：精簡和優(yōu)化 JavaScript 和 CSS 代碼，避免使用過多的循環(huán)和遞歸操作，減少對 CPU 的占用。
- 避免內(nèi)存泄漏：定期檢查并優(yōu)化內(nèi)存使用，避免出現(xiàn)內(nèi)存泄漏問題，可以使用瀏覽器的開發(fā)者工具進行內(nèi)存分析。
- 圖片懶加載：延遲加載圖片，只有當圖片進入可視區(qū)域時再加載，減少內(nèi)存占用。
- 數(shù)據(jù)本地存儲：使用瀏覽器提供的本地存儲功能（如LocalStorage或IndexedDB），將一些數(shù)據(jù)緩存到本地，減少對網(wǎng)絡請求的依賴，提高性能。
- 使用 Web Workers：將一些耗時的任務放到 Web Workers 中執(zhí)行，減輕主線程的負擔，從而減少 CPU 占用。
- 使用服務端渲染：使用服務端渲染技術，減少客戶端的計算壓力，提高頁面加載速度。
- 使用資源壓縮：對 JavaScript、CSS、圖片等資源進行壓縮，減小文件大小，降低網(wǎng)絡傳輸和內(nèi)存占用。
本次我們主要使用了 Web Workers 和 數(shù)據(jù)解綁 (Object.freeze) 等方式進行空間優(yōu)化，減少了CPU和內(nèi)存的占用。通過 Web Workers 將需要復雜計算任務放到 Worker 線程，避免阻塞其他首頁渲染任務，釋放主線程資源，實現(xiàn)單線程到多線程。但是這里要注意，過多的使用 Web Workers 有時候反而會導致資源的過度占用，因為 Web Workers 本身也會占用一定的內(nèi)存資源，而 Workers 之間的通信和數(shù)據(jù)同步也可能會帶來復雜性和性能開銷，特別是在大規(guī)模的并發(fā)任務處理時，所以我們需要根據(jù)場景合理使用。
六、優(yōu)化前后對比
整體性能提升 292%：
優(yōu)化后的加載效果對比：
七、性能監(jiān)控
為了保證平臺在后續(xù)的迭代過程中，持續(xù)保持高性能，我們引入Chrome 開源的 web-vitals 庫，結合自研的運行時性能監(jiān)控埋點(卡頓、崩潰)，以及平臺的數(shù)據(jù)可視化能力，實現(xiàn)對前端整體性能的監(jiān)控。并利用了平臺的數(shù)據(jù)監(jiān)控預警能力，通過對不同指標的配置告警服務，增加性能指標相關的告警，在性能指標發(fā)生異動時，及時發(fā)現(xiàn)問題，優(yōu)化性能，保障了用戶使用體驗。
八、總結
上面講了那么多優(yōu)化方法，都是針對當前項目進行的針對性優(yōu)化 ，所以我們進行優(yōu)化時，需要根據(jù)具體情況和需求，結合不同的優(yōu)化策略來達到最佳的性能優(yōu)化效果。前端性能優(yōu)化是一個重要的主題，它涉及到許多方面，包括頁面加載速度、交互響應時間、資源利用效率等。但不管什么樣的優(yōu)化方式，他們的核心思路都是一致的，因為在用戶能看到頁面，并且與之交互之前，都是有固定的步驟的，所以優(yōu)化的核心思路就是：盡可能去掉一些關鍵步驟、盡可能提前一些重要步驟、盡可能優(yōu)化某個具體步驟。比如 SSR 相比于 CSR，用戶能更快的看到頁面，就是去掉了「下載入口index.html，下載并執(zhí)行 CSS、JS，請求接口」這幾個關鍵步驟，比如上面說的對高優(yōu)先級資源進行預加載就是提前一些重要步驟，再比如說通過web workers 避免 JS 執(zhí)行時產(chǎn)生 Long Task就是優(yōu)化某個具體步驟。以上就是本次性能優(yōu)化實踐的所有內(nèi)容，希望能對你有所幫助。
