在構(gòu)建 Web 站點(diǎn)的過程中，任何一個(gè)細(xì)節(jié)都有可能影響網(wǎng)站的訪問速度。如果開發(fā)人員不了解前端性能相關(guān)知識(shí)，很多不利網(wǎng)站訪問速度的因素會(huì)在線上形成累加，從而嚴(yán)重影響網(wǎng)站的性能，導(dǎo)致網(wǎng)站訪問速度變慢、用戶體驗(yàn)低下，最終導(dǎo)致用戶流失。頁面性能對(duì)網(wǎng)頁而言，可謂舉足輕重。因此，對(duì)頁面的性能進(jìn)行檢測(cè)分析，是開發(fā)者不可忽視的課題。那么我們?nèi)绾螌?duì)頁面進(jìn)行監(jiān)控分析及性能評(píng)判？對(duì)性能評(píng)判的規(guī)則又是什么樣的呢？

從技術(shù)方面來講，前端性能監(jiān)控主要分為兩種方式，一種叫做合成監(jiān)控（Synthetic Monitoring，SYN），另一種是真實(shí)用戶監(jiān)控（Real User Monitoring，RUM）。

• 合成監(jiān)控，就是在一個(gè)模擬場(chǎng)景里，去提交一個(gè)需要做性能檢測(cè)的頁面，通過一系列的工具、規(guī)則去運(yùn)行你的頁面，提取一些性能指標(biāo)，得出一個(gè)性能報(bào)告。

• 真實(shí)用戶監(jiān)控，就是用戶在我們的頁面上瀏覽，瀏覽過程就會(huì)產(chǎn)生各種各樣的性能數(shù)據(jù)，我們把這些性能數(shù)據(jù)上傳到我們的日志服務(wù)器上，進(jìn)行數(shù)據(jù)的提取清洗加工，最后在我們的監(jiān)控平臺(tái)上進(jìn)行展示的一個(gè)過程。

前者注重“檢測(cè)”，后者注重“監(jiān)控”。

下文將從多個(gè)方面，向大家介紹政采云前端 ZooTeam 的 Web 性能優(yōu)化分析系統(tǒng)—— “百策”，是如何采集頁面性能數(shù)據(jù)，并通過一系列計(jì)算加工，產(chǎn)出頁面性能報(bào)表的。

百策，取名自歷史人物魏征。魏征，字玄成。唐太宗李世民的諫臣，因敢于直諫，被稱為諍臣。因多次指出唐太宗李世民的過錯(cuò)并能提出有效政策，因?yàn)楸环Q為 “魏百策”。

如何采集頁面性能數(shù)據(jù)

百策系統(tǒng)采用了上文提到的 “合成監(jiān)控” 的方案，得到了一組與宿主環(huán)境無關(guān)的性能數(shù)據(jù)。說到合成監(jiān)控方案，當(dāng)屬 Google Chrome 團(tuán)隊(duì)出品的開源自動(dòng)化分析工具 Lighthouse。

Lighthouse 的工作流程有幾個(gè)主要的步驟。部分步驟發(fā)生在瀏覽器中，其余的步驟由 Lighthouse 運(yùn)行器執(zhí)行。

Lighthouse 工作原理

下面是 Lighthouse 的組成部分：

• 驅(qū)動(dòng)和 Chrome Debugging Protocol 進(jìn)行交互。

• 收集器  使用驅(qū)動(dòng)程序收集網(wǎng)頁信息。最小化后處理。收集器的輸出結(jié)果被稱為  Artifact 。

• 審查器將  Artifact 作為輸入，審查器會(huì)對(duì)其運(yùn)行 1 個(gè)測(cè)試，然后分配通過/失敗/得分的結(jié)果。

• 類別  將審查的結(jié)果分組到面向用戶的報(bào)告中（如最佳實(shí)踐）。對(duì)該部分加權(quán)求和然后得出評(píng)分。

簡(jiǎn)單來說流程就是：建立連接 -> 收集日志 -> 分析 -> 生成報(bào)告。

而我們的百策系統(tǒng)是在 Lighthouse 的基礎(chǔ)上，進(jìn)行了部分功能的定制和創(chuàng)新。

區(qū)別于 Lighthouse 的功能

1）使用 Puppeteer

Puppeteer 是一個(gè) Node 庫(kù)，它提供了一個(gè)高級(jí) API 來通過 DevTools 協(xié)議控制 Chromium 或 Chrome。相比較 Selenium 或是  PhantomJs ，它最大的特點(diǎn)就是它的  DOM 操作可以完全在內(nèi)存中進(jìn)行模擬，即在  V8 引擎中處理而不打開瀏覽器，而且  V8 引擎 Chrome 團(tuán)隊(duì)在維護(hù)，會(huì)擁有更好的兼容性和前景。

運(yùn)行下面這段代碼就能獲取到視窗可視區(qū)域的寬高：

const puppeteer = require('puppeteer'); 
(async () => {  const browser = await puppeteer.launch();  const page = await browser.newPage();  await page.goto('https://example.com'); 
  const dimensions = await page.evaluate(() => {    return {      width: document.documentElement.clientWidth,      height: document.documentElement.clientHeight    };  }); 
  console.log('Dimensions:', dimensions); 
  await browser.close();})(); 

Lighthouse 的方案是使用更底層的 DevTools 協(xié)議和瀏覽器交互，我們選擇 Puppeteer 是因?yàn)槠涓?jiǎn)單，封裝的一些常用的接口足夠滿足我們的需求。

2）訪問頁面前模擬登錄

我們不僅需要檢測(cè)可匿名訪問的前臺(tái)頁面，也需要檢測(cè)登錄后才能操作的后臺(tái)頁面。所以在檢測(cè)前，我們需要增加一步登錄操作。當(dāng)然這個(gè)用戶名密碼也是可選的，當(dāng)檢測(cè)到這個(gè) URL 需要登錄時(shí)，才會(huì)提醒用戶輸入用戶名密碼。

3）收集到數(shù)據(jù)存入數(shù)據(jù)庫(kù)

我們將每一次的檢測(cè)數(shù)據(jù)保存入庫(kù)，對(duì)數(shù)據(jù)進(jìn)行整理，獲取頁面性能變化所呈現(xiàn)的趨勢(shì)，為支持后續(xù)的統(tǒng)計(jì)分析提供數(shù)據(jù)保證。

改造之后的流程是：建立連接 -> 登錄檢測(cè) -> 收集日志 ->  數(shù)據(jù)入庫(kù) -> 分析 -> 生成報(bào)告

如何分析頁面性能

定制各項(xiàng)指標(biāo)

系統(tǒng)設(shè)計(jì)初期，我們擬定了一系列性能指標(biāo)的權(quán)重和閾值：

Lighthouse 也制定了很多性能指標(biāo)，譬如：

• uses-webp-images：采用新一代格式提供圖片

• dom-size：DOM 節(jié)點(diǎn)總數(shù)

• network-requests：頁面加載完成時(shí)的請(qǐng)求數(shù)

• ……

除此之外我們定制了更多的特色指標(biāo)，譬如：OSS 圖片是否使用了壓縮后綴。

由于公司的圖片都是放在阿里云 OSS 上的，阿里云 OSS 提供了很方便的優(yōu)化圖片體積的方法，就是給圖片的末尾加上類似參數(shù) ?x-oss-process=image/resize,w_187/quality,Q_75/format,webp ，理論上放在 OSS 上的圖片都需要添加壓縮后綴。為什么說是理論上呢？因?yàn)槲覀儼l(fā)現(xiàn)如果圖片上傳 OSS 前，事先經(jīng)過了其他壓縮工具的壓縮，再添加壓縮后綴后，圖片的體積變化不大，甚至?xí)霈F(xiàn)負(fù)增長(zhǎng)。所以我們調(diào)整了評(píng)審算法，不再是簡(jiǎn)單地檢查圖片是否增加了 OSS 后綴，而是比較當(dāng)前圖片的體積與添加 OSS 壓縮后綴后體積的差值是否超出比例。

定制檢測(cè)模型

檢測(cè)系統(tǒng)試運(yùn)行一段時(shí)間后，我們發(fā)現(xiàn)并不是所有的指標(biāo)都適用于所有類型的頁面。譬如我們的前臺(tái)頁面加載圖片很多且對(duì)圖片分辨率要求較高、而后臺(tái)頁面圖片則比較少。我們既有傳統(tǒng)的后端渲染 + jQuery 類型的頁面、客戶端渲染 React 頁面、也有經(jīng)過預(yù)渲染的 Vue 頁面。

將所有類型的頁面按同一標(biāo)準(zhǔn)進(jìn)行檢測(cè)顯然不太合適，所以我們引入了 檢測(cè)模型 的概念。我們根據(jù)頁面所屬的類型，按照對(duì)應(yīng)檢測(cè)模型進(jìn)行性能檢測(cè)。一個(gè)檢測(cè)模型可以關(guān)聯(lián)多個(gè)指標(biāo)，并可以配置指標(biāo)權(quán)重和級(jí)別。

權(quán)重越大扣分越多，級(jí)別分為 error 和 warning，其中 warning 級(jí)別的扣分項(xiàng)不算入總分中，譬如請(qǐng)求是否使用 Gzip 就是，因?yàn)檫@一項(xiàng)是前端無法優(yōu)化的，需要推動(dòng)服務(wù)端去改進(jìn)。

計(jì)算頁面評(píng)分

提供優(yōu)化建議和趨勢(shì)

優(yōu)化建議

針對(duì)每項(xiàng)扣分的審查項(xiàng)，我們都提供了詳細(xì)的扣分原因，以及對(duì)應(yīng)的解決方案：

頁面性能趨勢(shì)變化圖

除了開發(fā)新的功能，我們還積極地對(duì)老頁面進(jìn)行重構(gòu)，為了分析重構(gòu)前后的收益，我們還提供了查詢歷史數(shù)據(jù)和變化趨勢(shì)的功能：

總結(jié)

百策系統(tǒng)為前端頁面提供性能優(yōu)化分析服務(wù)，結(jié)合行業(yè)方案及業(yè)務(wù)場(chǎng)景的差異性，完善符合公司業(yè)務(wù)情況的最佳實(shí)踐，百策系統(tǒng)制定了一套 Web 頁面性能的檢測(cè)標(biāo)準(zhǔn)，通過頁面檢測(cè)及模型分析，發(fā)現(xiàn)頁面中請(qǐng)求耗時(shí)過長(zhǎng)、請(qǐng)求資源過大、頁面結(jié)構(gòu)不合理等影響用戶體驗(yàn)的問題，并針對(duì)問題提供相應(yīng)的優(yōu)化建議，幫助開發(fā)者產(chǎn)出渲染速度更快、資源占有更少、體驗(yàn)更好的頁面。