原創不易，希望能關注下我們，再順手點個贊~~
本文首發於政採雲前端團隊部落格： 自動化 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