自動化 Web 性能優化分析方案

原創不易，但願能關注下咱們，再順手點個贊~~

本文首發於政採雲前端團隊博客： 自動化 Web 性能優化分析方案

在構建 Web 站點的過程當中，任何一個細節都有可能影響網站的訪問速度。若是開發人員不瞭解前端性能相關知識，不少不利網站訪問速度的因素會在線上造成累加，從而嚴重影響網站的性能，致使網站訪問速度變慢、用戶體驗低下，最終致使用戶流失。頁面性能對網頁而言，可謂舉足輕重。所以，對頁面的性能進行檢測分析，是開發者不可忽視的課題。那麼咱們如何對頁面進行監控分析及性能評判？對性能評判的規則又是什麼樣的呢？

從技術方面來說，前端性能監控主要分爲兩種方式，一種叫作合成監控（Synthetic Monitoring，SYN），另外一種是真實用戶監控（Real User Monitoring，RUM）。

• 合成監控，就是在一個模擬場景裏，去提交一個須要作性能檢測的頁面，經過一系列的工具、規則去運行你的頁面，提取一些性能指標，得出一個性能報告。

• 真實用戶監控，就是用戶在咱們的頁面上瀏覽，瀏覽過程就會產生各類各樣的性能數據，咱們把這些性能數據上傳到咱們的日誌服務器上，進行數據的提取清洗加工，最後在咱們的監控平臺上進行展現的一個過程。

前者注重 」檢測「，後者注重」監控「。

下文將從多個方面，向你們介紹政採雲前端 ZooTeam 的 Web 性能優化分析系統—— 「百策」，是如何採集頁面性能數據，並經過一系列計算加工，產出頁面性能報表的。

百策，取名自歷史人物魏徵。魏徵，字玄成。唐太宗李世民的諫臣，因勇於直諫，被稱爲諍臣。因屢次指出唐太宗李世民的過錯並能提出有效政策，由於被稱爲 「魏百策」。

如何採集頁面性能數據

百策系統採用了上文提到的 「合成監控」 的方案，獲得了一組與宿主環境無關的性能數據。說到合成監控方案，當屬 Google Chrome 團隊出品的開源自動化分析工具 Lighthouse。

Lighthouse 的工做流程有幾個主要的步驟。部分步驟發生在瀏覽器中，其他的步驟由 Lighthouse 運行器執行。

Lighthouse 工做原理

下面是 Lighthouse 的組成部分：

• 驅動 和 Chrome Debugging Protocol 進行交互。
• 收集器  使用驅動程序收集網頁信息。最小化後處理。收集器的輸出結果被稱爲 Artifact。
• 審查器 將 Artifact 做爲輸入，審查器會對其運行 1 個測試，而後分配經過/失敗/得分的結果。
• 類別   將審查的結果分組到面向用戶的報告中（如最佳實踐）。對該部分加權求和而後得出評分。

簡單來講流程就是：創建鏈接 -> 收集日誌 -> 分析 -> 生成報告。

而咱們的百策系統是在 Lighthouse 的基礎上，進行了部分功能的定製和創新。

區別於 Lighthouse 的功能

1）使用 Puppeteer

Puppeteer 是一個 Node 庫，它提供了一個高級 API 來經過 DevTools 協議控制 Chromium 或 Chrome。相比較 Selenium 或是 PhantomJs ，它最大的特色就是它的 DOM 操做能夠徹底在內存中進行模擬，即在 V8 引擎中處理而不打開瀏覽器，並且 V8 引擎 Chrome 團隊在維護，會擁有更好的兼容性和前景。

運行下面這段代碼就能獲取到視窗可視區域的寬高：

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 協議和瀏覽器交互，咱們選擇 Puppeteer 是由於其更簡單，封裝的一些經常使用的接口足夠知足咱們的需求。

2）訪問頁面前模擬登陸

咱們不只須要檢測可匿名訪問的前臺頁面，也須要檢測登陸後才能操做的後臺頁面。因此在檢測前，咱們須要增長一步登陸操做。固然這個用戶名密碼也是可選的，當檢測到這個 URL 須要登陸時，纔會提醒用戶輸入用戶名密碼。

3）收集到數據存入數據庫

咱們將每一次的檢測數據保存入庫，對數據進行整理，獲取頁面性能變化所呈現的趨勢，爲支持後續的統計分析提供數據保證。

改造以後的流程是：創建鏈接 -> 登陸檢測 -> 收集日誌 -> 數據入庫 -> 分析 -> 生成報告

如何分析頁面性能

定製各項指標

系統設計初期，咱們擬定了一系列性能指標的權重和閾值：

Lighthouse 也制定了不少性能指標，譬如：

• uses-webp-images：採用新一代格式提供圖片
• dom-size：DOM 節點總數
• network-requests：頁面加載完成時的請求數
• …...

除此以外咱們定製了更多的特點指標，譬如：OSS 圖片是否使用了壓縮後綴。

因爲公司的圖片都是放在阿里雲 OSS 上的，阿里雲 OSS 提供了很方便的優化圖片體積的方法，就是給圖片的末尾加上相似參數 ?x-oss-process=image/resize,w_187/quality,Q_75/format,webp，理論上放在 OSS 上的圖片都須要添加壓縮後綴。爲何說是理論上呢？由於咱們發現若是圖片上傳 OSS 前，事先通過了其餘壓縮工具的壓縮，再添加壓縮後綴後，圖片的體積變化不大，甚至會出現負增加。因此咱們調整了評審算法，再也不是簡單地檢查圖片是否增長了 OSS 後綴，而是比較當前圖片的體積與添加 OSS 壓縮後綴後體積的差值是否超出比例。

定製檢測模型

檢測系統試運行一段時間後，咱們發現並非全部的指標都適用於全部類型的頁面。譬如咱們的前臺頁面加載圖片不少且對圖片分辨率要求較高、然後臺頁面圖片則比較少。咱們既有傳統的後端渲染 + jQuery 類型的頁面、客戶端渲染 React 頁面、也有通過預渲染的 Vue 頁面。

將全部類型的頁面按同一標準進行檢測顯然不太合適，因此咱們引入了 檢測模型 的概念。咱們根據頁面所屬的類型，按照對應檢測模型進行性能檢測。一個檢測模型能夠關聯多個指標，並能夠配置指標權重和級別。

權重越大扣分越多，級別分爲 error 和 warning，其中 warning 級別的扣分項不算入總分中，譬如請求是否使用 Gzip 就是，由於這一項是前端沒法優化的，須要推進服務端去改進。

計算頁面評分

提供優化建議和趨勢

優化建議

針對每項扣分的審查項，咱們都提供了詳細的扣分緣由，以及對應的解決方案：

頁面性能趨勢變化圖

除了開發新的功能，咱們還積極地對老頁面進行重構，爲了分析重構先後的收益，咱們還提供了查詢歷史數據和變化趨勢的功能：

總結

百策系統爲前端頁面提供性能優化分析服務，結合行業方案及業務場景的差別性，完善符合公司業務狀況的最佳實踐，百策系統制定了一套 Web 頁面性能的檢測標準，經過頁面檢測及模型分析，發現頁面中請求耗時過長、請求資源過大、頁面結構不合理等影響用戶體驗的問題，並針對問題提供相應的優化建議，幫助開發者產出渲染速度更快、資源佔有更少、體驗更好的頁面。

後續，咱們還會對 「百策系統」 進行系列分享，歡迎你們先關注微信公衆號 「政採雲前端團隊」，或者掘金上關注 「政採雲前端團隊」，以便第一時間獲取最新信息。分享預告：

• 《爬蟲實戰：模擬用戶登陸抓取頁面性能數據》
• 《初識 NestJS：不用寫 SQL 我也能開發後臺》
• 《文檔站點：不用 Gitlab CI 搭建持續集成的文檔站點》
• 《圖片體積優化：四捨五入我爲公司節省一個億》
• 《Node 性能優化：我是如何懵逼應對 Node 定時批量任務爆棧的》

招賢納士

招人，前端，隸屬政採雲前端大團隊（ZooTeam），50 餘個小夥伴正等你加入一塊兒浪。若是你想改變一直被事折騰，但願開始能折騰事；若是你想改變一直被告誡須要多些想法，卻無從破局；若是你想改變你有能力去作成那個結果，卻不須要你；若是你想改變你想作成的事須要一個團隊去支撐，但沒你帶人的位置；若是你想改變既定的節奏，將會是「5年工做時間3年工做經驗」；若是你想改變原本悟性不錯，但老是有那一層窗戶紙的模糊… 若是你相信相信的力量，相信平凡人能成就非凡事，相信能遇到更好的本身。若是你但願參與到隨着業務騰飛的過程，親手參與一個有着深刻的業務理解、完善的技術體系、技術創造價值、影響力外溢的前端團隊的成長曆程，我以爲咱們該聊聊。任什麼時候間，等着你寫點什麼，發給 ZooTeam@cai-inc.com

推薦閱讀

看完這篇，你也能把 React Hooks 玩出花

Vue 組件數據通訊方案總結

CSS 層疊上下文（Stacking Context）