Web前端性能優(yōu)化深度解讀
導讀： 用戶體驗是web產(chǎn)品非常重要的部分，核心是讓用戶使用舒服，幫助用戶流暢地得到所求，用戶體驗的優(yōu)劣甚至會影響到用戶的留存。體驗差的網(wǎng)站各有各的不同，但是體驗好的網(wǎng)站往往都有一些共性，這些優(yōu)秀的特征凝結(jié)了設計師、研發(fā)工程師和產(chǎn)品經(jīng)理的大量智慧。
訪問交互速度迅速
動畫效果順滑流暢
有用戶操作的反饋
簡單的操作步驟
整站體驗一致性
主體內(nèi)容在最顯眼的位置
無障礙訪問，不同的人群均可使用
在這些優(yōu)秀體驗的特性中，最容易讓人產(chǎn)生共鳴的往往是網(wǎng)站的性能問題，比如網(wǎng)站的訪問交互速度。如何發(fā)現(xiàn)性能問題？性能如何優(yōu)化（性能優(yōu)化的常規(guī)方法和框架方法）？如何衡量收益？本文根據(jù)多年在性能優(yōu)化方面的實踐，著重分享一下首屏性能優(yōu)化的一些經(jīng)驗。
01 性能采集
工欲利器事，必先利其器。我們所說的性能采集并不是性能分析Devtools，而是指在產(chǎn)品真實用戶訪問的大數(shù)據(jù)中進行抽樣，對于抽樣用戶進行性能數(shù)據(jù)采集，得到真實用戶環(huán)境下產(chǎn)品性能數(shù)據(jù)。各瀏覽器廠商都已認識到性能對于web開發(fā)的重要性，為了解決當前性能測試的困難，W3C推出了一套性能API標準，目的是簡化開發(fā)者對網(wǎng)站性能進行精確分析與控制的過程，方便開發(fā)者采取手段提高web性能。整套標準包含了10余種API，在下圖中可以看到它們當前在規(guī)范流程中的進展。
圖：性能API標準（摘錄51CTO圖片）
這套標準中提供了導航定時（Navigation Timing）、資源定時（Resource Timing）、用戶定時User Timing和性能時間線（Performance Timeline）規(guī)范可以幫助開發(fā)人員精確地測量文檔的導航時間，在頁面上獲取資源的情況，以及開發(fā)人員腳本執(zhí)行情況。
在這套API中，頁面加載Navigation Timing和頁面資源加載Resource Timing這兩個API可以幫助我們獲取頁面的Domready時間、onload時間、白屏時間以及單個頁面資源在從發(fā)送請求到獲取到response各階段例如帶寬、延遲或主頁的整體頁面加載時間的性能參數(shù)，這些都是基于真實用戶數(shù)據(jù)（RUM）。
圖：Navigation Timing關(guān)系圖（摘錄W3C）
在獲取用戶訪問Timing數(shù)據(jù)的前提下，我們可以結(jié)合具體業(yè)務場景定義訪問性能的核心指標，例如白屏時間、首屏時間FSP、用戶可交互時間TTI、頁面onload時間等作為核心優(yōu)化指標，其中首屏時間和用戶可交互時間需要單獨埋點自定義。
還可以通過獲取DNS查詢耗時、TCP鏈接耗時、request請求耗時、解析dom樹耗時、白屏時間、domready時間、onload時間等做性能分析，后續(xù)根據(jù)癥狀對這些細致階段做性能優(yōu)化，這些參數(shù)是通過上面的performance.timing各個屬性的差值組成的。
通過使用API對各個階段性能指標進行采集，等待到所有數(shù)據(jù)都獲取完成之后，通過網(wǎng)絡請求將數(shù)據(jù)發(fā)送到服務器用作后續(xù)數(shù)據(jù)分析使用。
02 性能優(yōu)化
快速加載、及時響應用戶反饋、提供流暢的動畫、以及擁有類似原生APP一般沉浸的用戶體驗是web應用在性能優(yōu)化上的目標，這主要關(guān)系到加載性能和渲染性能兩個方面，本章節(jié)介紹一些常規(guī)優(yōu)化方法和框架級優(yōu)化方案。
2.1 加載性能優(yōu)化
Web 頁面通常由 HTML、CSS、JavaScript 和其他多媒體資源組成，充斥著各種同步資源和異步資源。頁面加載時，必須從服務器獲取這些資源。
2.1.1 減小資源體積
壓縮文本內(nèi)容
優(yōu)化JavaScript第三方庫引入
壓縮雖然簡單，但十分有效，這也是最廣泛的優(yōu)化資源體積的操作。許多工具可以幫助我們完成HTML、CSS、JavaScript、圖片等壓縮。例如，TerserPlugin可以用于壓縮 JavaScript，PostCSS可以對 CSS 進行壓縮，以及完成前綴自動補全工作。除了壓縮單個文件外，在服務器上配置 Gzip 也十分重要。Gzip 對文本資源的壓縮效果非常明顯，通?？梢詫Ⅲw積再壓縮至原本的 30% 左右，但 Gzip 對已經(jīng)單獨壓縮的圖像等非文本資源來說，效果并不好。
如果我們只需要使用工具庫中少數(shù)幾個簡單函數(shù)，可以考慮使用原生 JavaScript 代替。不計后果地引入第三方庫，會迅速增大 JavaScript 資源的體積。
2.1.2 對資源進行緩存
緩存在優(yōu)化頁面加載性能的工作中有舉足輕重的作用，緩存無處不在，包括瀏覽器端、網(wǎng)絡代理、服務端緩存，往往能大幅加快響應速度。
圖：web全鏈路緩存
HTTP 緩存
Local Storage
Cache Storage
IndexedDB
CDN
現(xiàn)代瀏覽器都實現(xiàn)了 HTTP 緩存機制。瀏覽器在初次獲取資源后，會根據(jù) HTTP 響應頭部的Cache-Control和ETag字段，來決定該資源的強緩存策略或者協(xié)商緩存策略。
Local Storage主要是用來作為本地存儲來使用的，解決了cookie存儲空間不足的問題（cookie中每條cookie的存儲空間為4k），localStorage中一般瀏覽器支持的是5M大小。
Cache Storage它用來存儲 Response 對象的，也就是說用來對 HTTP響應做緩存的，通常在PWA技術(shù)中使用。
IndexedDB是一種在瀏覽器中持久存儲數(shù)據(jù)的方法，允許我們不考慮網(wǎng)絡可用性，創(chuàng)建具有豐富查詢能力的可離線web應用程序。
內(nèi)容緩存在CDN網(wǎng)絡節(jié)點，位于用戶接入點，是面向最終用戶的內(nèi)容提供設備，可緩存靜態(tài)Web內(nèi)容和流媒體內(nèi)容，實現(xiàn)內(nèi)容的邊緣傳播和存儲，以便用戶的就近訪問。
2.1.3 調(diào)整資源優(yōu)先級
通過調(diào)整資源加載優(yōu)先級，保證主體內(nèi)容能夠較快的被加載完成，通過預加載、懶加載等多種方式，調(diào)整資源加載的行為，優(yōu)化網(wǎng)頁加載性能。
預加載
預連接與 DNS 預解析
預取
懶加載
Service Worker
通過來提前聲明當前頁面所需的資源，以便瀏覽器能預加載這些資源。通過media屬性進行媒體查詢，根據(jù)響應式的情況選擇性地預加載資源。
預連接會提前完成 DNS 解析、TCP 握手和 TLS 協(xié)商的工作，但并不會提前加載資源。也可以考慮使用，提前與資源建立 socket 連接。
瀏覽器會在空閑時，使用最低優(yōu)先級下載預取的資源。預取通過聲明，通常用于點擊“下一頁”的頁面動作之前提前加載用戶接下來可能需要的html資源。
按需加載和延時加載都屬于懶加載的范疇，例如對圖像資源采用“懶加載”策略，即僅加載當前在視口內(nèi)的圖像，對于視口外未加載的圖像，在其即將滾動進入視口時才開始加載。
利用Service Worker 線程脫離在主線程之外來進行 Web 資源和請求的持久離線緩存。
2.1.4 合理拆分代碼
瀏覽器支持并行加載資源，合理拆分資源也是一種有效的優(yōu)化方法。為了更好的效果，我們往往不需要在首屏一次性加載所有 JavaScript 代碼，合理的拆分代碼、區(qū)分開發(fā)和生產(chǎn)環(huán)境使用少量主要代碼，將當前暫時不需要的代碼拆分出去可以有效加快首屏展現(xiàn)的速度。通過webpack區(qū)分開發(fā)環(huán)境和生產(chǎn)環(huán)境差異化配置打包資源可以有效優(yōu)化代碼，Tree shaking使得模塊間依賴可以通過靜態(tài)分析來更好地優(yōu)化剪枝（僅ES modules支持）。webpack-bundle-analyzer 是一個關(guān)于 webpack 構(gòu)建產(chǎn)物的可視化插件，可以清晰地看到構(gòu)建產(chǎn)物的體積，幫助分析后續(xù)的優(yōu)化方向。
2.1.5 HTTP/2
HTTP/2帶給WEB帶來了很大的性能提升，同時多路復用、頭部壓縮、Server Push等特點，使得可以在一個連接上同時打開多個流雙向傳輸數(shù)據(jù)，服務端可以在發(fā)送頁面 HTML 時主動推送其它資源，而不用等到瀏覽器解析到相應位置，發(fā)起請求再響應。
圖：http1 vs http2
2.2 渲染性能優(yōu)化
瀏覽器在渲染頁面前，首先會將 HTML 文本內(nèi)容解析為 DOM，將 CSS 解析為 CSSOM。DOM 和 CSSOM 都是樹狀數(shù)據(jù)結(jié)構(gòu)，兩者相互獨立，但又有相似之處。接著，瀏覽器會將 DOM 和 CSSOM 樹合并成渲染樹。從 DOM 樹的根節(jié)點開始遍歷，并在 CSSOM 樹中查找節(jié)點對應的樣式規(guī)則，合并成渲染樹中的節(jié)點。在遍歷的過程中，不可見的節(jié)點將會被忽略。渲染樹隨后會被用于布局，就是計算渲染樹節(jié)點在瀏覽器視口中確切的位置和大小。瀏覽器進行一次布局的性能開銷較大，我們需要小心地避免頻繁觸發(fā)頁面重新布局。得到渲染樹節(jié)點的幾何布局信息后，瀏覽器就可以將節(jié)點繪制到屏幕上了，包括繪制文本、顏色、邊框和陰影等。
繪制的過程，首先會根據(jù)布局和視覺相關(guān)的樣式信息生成一系列繪制操作，隨后執(zhí)行柵格化（柵格化是將向量圖形格式表示的圖像轉(zhuǎn)換成位圖以用于顯示器或者打印機輸出的過程），將待繪制項轉(zhuǎn)換為位圖存儲在 GPU 中，最終通過圖形庫將像素繪制在屏幕上。
圖：瀏覽器渲染過程
頁面不是一次性被繪制出來的。實際上，頁面被分成了多個圖層進行繪制，這些圖層會在另一個單獨的線程里繪制到屏幕上，這個過程被稱作合成。合成線程可以對圖層進行剪切、變換等處理，因此可以用于響應用戶基本的滾動、縮放等操作，又不會受到主線程阻塞的影響。
2.2.1 關(guān)鍵渲染路徑
由于渲染都是在主進程中執(zhí)行的，所以合理的利用主進程渲染非常重要。首屏渲染所必須的關(guān)鍵資源，共同組成了關(guān)鍵渲染路徑，減少非關(guān)鍵渲染路徑的資源消耗可以有效提升渲染速度。
延遲非關(guān)鍵 CSS 加載
async 和 defer
Web 應用中往往會有一些首屏渲染時用不到的 CSS，如彈框的樣式等。通過引用的 CSS 都會在加載時阻塞頁面渲染。為了使這些非關(guān)鍵 CSS 不阻塞頁面渲染，可以通過拆分資源的方式并延遲非關(guān)鍵資源加載。
由于渲染都是在主進程中執(zhí)行的，所以合理的利用主進程渲染非常重要。首屏渲染所必須的關(guān)鍵資源，共同組成了關(guān)鍵渲染路徑，減少非關(guān)鍵渲染路徑的資源消耗可以有效提升渲染速度。
2.2.2 非阻塞 JavaScript
用戶對于不流暢的滾動或動畫十分敏感，一般要求頁面幀率應達到每秒 60 幀。由于 JavaScript 一般是單線程執(zhí)行的，長時間執(zhí)行的任務會阻塞瀏覽器的主線程，使頁面失去響應，出現(xiàn)卡頓和假死的現(xiàn)象。
頁面滾動
requestAnimationFrame 任務在瀏覽器渲染下一幀之前執(zhí)行
requestIdleCallback 將任務安排在瀏覽器空閑時執(zhí)行
Web Workers
當我們監(jiān)聽 touchstart、touchmove 等事件時，由于合成線程并不知道我們是否會通過 event.preventDefault() 來阻止默認的滾動行為，從而在每次事件觸發(fā)時，都會等待事件處理函數(shù)執(zhí)行完畢后再進行頁面滾動。這通常會導致較明顯的延遲，影響頁面滾動的流暢性。通過在addEventListener()時聲明{passive: true}，來表明事件處理函數(shù)不會阻止頁面滾動，使得用戶的操作更快得到響應。
我們可以將一些耗性能的邏輯放在 worker 線程中進行處理，這樣主線程就能繼續(xù)響應用戶操作和渲染頁面了。
2.2.3 降低渲染樹計算復雜性
結(jié)構(gòu)越復雜的頁面往往性能越差，動畫多的頁面出現(xiàn)卡頓的幾率也越大。
減少查找與元素匹配成本
減少布局次數(shù)
優(yōu)化繪制與合成
渲染樹由 DOM 和 CSSOM 樹合并而成，對于每個 DOM 元素，需要查找與元素匹配的樣式規(guī)則。CSS Modules 是一種較為主流的 CSS-in-JS 解決方案，利用 webpack 等構(gòu)建工具，可以對類選擇器生成自定義格式的唯一類名，同樣能減少瀏覽器匹配 CSS 選擇器的開銷。
瀏覽器進行一次布局的開銷很大，所以我們需要盡可能避免直接修改這些屬性，尤其是不應將布局屬性用于動畫效果，否則會出現(xiàn)明顯的掉幀現(xiàn)象。
修改絕大多數(shù)樣式屬性都會導致頁面重繪，這很難避免。僅有的例外是transform和opacity，這是由于它們可以僅由合成器操作圖層來實現(xiàn)。transform和opacity非常適合用于實現(xiàn)動畫效果，但我們?nèi)孕枰ㄟ^will-change為它們創(chuàng)建獨立的圖層，避免影響其他圖層的繪制。
2.3 框架優(yōu)化方法
CSR、SSR、NSR、ESR、hybrid離線包、Big pipe、app cache等，都是不錯的方法。
2.3.1 CSR（Client Side Render）
瀏覽器渲染顧名思義就是所有的頁面渲染、邏輯處理、頁面路由、接口請求均是在瀏覽器中發(fā)生，也就是從服務端請求一個簡單HTML文件然后通過執(zhí)行JavaScript在HTML上進行內(nèi)容的添加。其實，現(xiàn)代主流的前端框架均是這種渲染方式，這種渲染方式的好處在于實現(xiàn)了前后端架構(gòu)分離，利于前后端職責分離，并且能夠首次渲染迅速有效減少白屏時間。同時，CSR可以通過在打包編譯階段進行預渲染或者骨架屏生成，可以進一步提升首次渲染的用戶體驗。
圖：CSR
2.3.2 SSR（Server Side Render）
服務端渲染則是在服務端完成頁面的渲染，在服務端完成頁面模板、數(shù)據(jù)填充、頁面渲染，然后將完整的HTML內(nèi)容返回給到瀏覽器。由于所有的渲染工作都在服務端完成，因此網(wǎng)站的首屏時間和TTI都會表現(xiàn)比較好。
圖：SSR
但是，渲染需要在服務端完成，并不能很好進行前后端職責分離，而且白屏時間也會比較長，同時，對于服務端的負載要求也會比較高。
2.3.3 NSR（Native Side Render）
GMTC2019 全球大前端技術(shù)上 UC 團隊提到了 0.3 秒的 “閃開” 方案。這種方案適用于混合開發(fā)，NSR本質(zhì)是分布式SSR，通過加載離線頁面模板，Ajax預加載頁面數(shù)據(jù)，Native渲染生成Html數(shù)據(jù)并且緩存在客戶端，將服務器的渲染工作放在了一個個獨立的移動設備中，實現(xiàn)了頁面的預加載，同時又不會增加額外的服務器壓力。核心思路是借助瀏覽器啟用一個 JS-Runtime，提前將下載好的 html 模板及預取的 feed 流數(shù)據(jù)進行渲染，然后將 html 設置到內(nèi)存級別的 MemoryCache 中，從而達到點開即看的效果。
圖：NSR
2.3.4 ESR（Edge Side Render）
邊緣渲染的核心思想是，借助邊緣計算的能力，將靜態(tài)內(nèi)容與動態(tài)內(nèi)容以流式的方式，先后返回給用戶。CDN 節(jié)點相比于Server距離用戶更近，有著更短的網(wǎng)絡延時。在 CDN 節(jié)點上將可緩存的頁面靜態(tài)部分先快速返回給用戶，同時在 CDN 節(jié)點上發(fā)起動態(tài)部分內(nèi)容請求，并將動態(tài)內(nèi)容在靜態(tài)部分的響應流后繼續(xù)返回給用戶。
圖：ESR
03、收益衡量
速度是應用性能最直接體現(xiàn)。做性能收益衡量也需要多維度全方位的進行分析與對比。通過等量實驗組和對照組在核心指標方面大量真實數(shù)據(jù)的分位值對比，可以得到性能方面的收益，也可以關(guān)聯(lián)到用戶PV、UV以及收入等方面是數(shù)據(jù)收益。
監(jiān)控網(wǎng)站真實用戶可感知的白屏、首屏、可交互等用戶體驗指標，從服務器端響應時間、網(wǎng)絡延時、DOM解析等細致指標的變化也可以做日常性能優(yōu)化。
統(tǒng)計核心指標不同分位數(shù)的占比數(shù)據(jù)。
統(tǒng)計不同版本瀏覽器和設備類型的核心指標數(shù)據(jù)，基于多平臺瀏覽器性能分析。
統(tǒng)計不同區(qū)域（包括國家、省份、城市）、不同運營商以及接入方式（包括2G/3G/4G/WiFi）下的各關(guān)鍵網(wǎng)絡性能指標。
圖：性能平臺
業(yè)內(nèi)不錯的性能監(jiān)控平臺包括ONEAPM、聽云、性能魔方等，各個大公司和云平臺也都提供不錯的相關(guān)監(jiān)控服務。
04 總結(jié)
你做事的時候不只是靠經(jīng)驗教訓的歷史積累，還有一套系統(tǒng)的流程或者模板。做性能優(yōu)化是一件需要具有閉環(huán)思維的事情，特別是這種端到端的優(yōu)化要注意事前規(guī)劃、事中執(zhí)行和事后總結(jié)三個階段，而且還要結(jié)合不同的業(yè)務場景進行優(yōu)化，有時候還要與客戶端相協(xié)同，并不是生拉硬套就可以完成的事情。
甚至很多大廠的業(yè)務前端還要一邊解決歷史包袱，一邊進行優(yōu)化，小心前行！隨著優(yōu)化后業(yè)務仍然在不斷的迭代和發(fā)展，如何鞏固性能優(yōu)化結(jié)果也是一件任重道遠持續(xù)投入的事情，掌握性能優(yōu)化基本原理結(jié)合具有優(yōu)秀性能結(jié)構(gòu)設計或許是一種智慧的方法。