導讀： 用戶體驗是web產品非常重要的部分，核心是讓用戶使用舒服，幫助用戶流暢地得到所求，用戶體驗的優劣甚至會影響到用戶的留存。體驗差的網站各有各的不同，但是體驗好的網站往往都有一些共性，這些優秀的特征凝結了設計師、研發工程師和產品經理的大量智慧。

• 訪問交互速度迅速
• 動畫效果順滑流暢
• 有用戶操作的反饋
• 簡單的操作步驟
• 整站體驗一致性
• 主體內容在最顯眼的位置
• 無障礙訪問，不同的人群均可使用

在這些優秀體驗的特性中，最容易讓人產生共鳴的往往是網站的性能問題，比如網站的訪問交互速度。如何發現性能問題？性能如何優化（性能優化的常規方法和框架方法）？如何衡量收益？本文根據多年在性能優化方面的實踐，著重分享一下首屏性能優化的一些經驗。

01

性能采集

工欲利器事，必先利其器。我們所說的性能采集并不是性能分析Devtools，而是指在產品真實用戶訪問的大數據中進行抽樣，對于抽樣用戶進行性能數據采集，得到真實用戶環境下產品性能數據。各瀏覽器廠商都已認識到性能對于web開發的重要性，為了解決當前性能測試的困難，W3C推出了一套性能API標準，目的是簡化開發者對網站性能進行精確分析與控制的過程，方便開發者采取手段提高web性能。整套標準包含了10余種API，在下圖中可以看到它們當前在規范流程中的進展。

圖：性能API標準（摘錄51CTO圖片）

這套標準中提供了導航定時（Navigation Timing）、資源定時（Resource Timing）、用戶定時User Timing和性能時間線（Performance Timeline）規范可以幫助開發人員精確地測量文檔的導航時間，在頁面上獲取資源的情況，以及開發人員腳本執行情況。

在這套API中，頁面加載Navigation Timing和頁面資源加載Resource Timing這兩個API可以幫助我們獲取頁面的Domready時間、onload時間、白屏時間以及單個頁面資源在從發送請求到獲取到response各階段例如帶寬、延遲或主頁的整體頁面加載時間的性能參數，這些都是基于真實用戶數據（RUM）。

圖：Navigation Timing關系圖（摘錄W3C）

在獲取用戶訪問Timing數據的前提下，我們可以結合具體業務場景定義訪問性能的核心指標，例如白屏時間、首屏時間FSP、用戶可交互時間TTI、頁面onload時間等作為核心優化指標，其中首屏時間和用戶可交互時間需要單獨埋點自定義。

還可以通過獲取DNS查詢耗時、TCP鏈接耗時、request請求耗時、解析dom樹耗時、白屏時間、domready時間、onload時間等做性能分析，后續根據癥狀對這些細致階段做性能優化，這些參數是通過上面的performance.timing各個屬性的差值組成的。

通過使用API對各個階段性能指標進行采集，等待到所有數據都獲取完成之后，通過網絡請求將數據發送到服務器用作后續數據分析使用。

02

性能優化

快速加載、及時響應用戶反饋、提供流暢的動畫、以及擁有類似原生APP一般沉浸的用戶體驗是web應用在性能優化上的目標，這主要關系到加載性能和渲染性能兩個方面，本章節介紹一些常規優化方法和框架級優化方案。

2.1 加載性能優化

Web 頁面通常由 HTML、CSS、JavaScript 和其他多媒體資源組成，充斥著各種同步資源和異步資源。頁面加載時，必須從服務器獲取這些資源。

2.1.1 減小資源體積

• 壓縮文本內容
• 優化JavaScript第三方庫引入

壓縮雖然簡單，但十分有效，這也是最廣泛的優化資源體積的操作。許多工具可以幫助我們完成HTML、CSS、JavaScript、圖片等壓縮。例如，TerserPlugin可以用于壓縮 JavaScript，PostCSS可以對 CSS 進行壓縮，以及完成前綴自動補全工作。除了壓縮單個文件外，在服務器上配置 Gzip 也十分重要。Gzip 對文本資源的壓縮效果非常明顯，通常可以將體積再壓縮至原本的 30% 左右，但 Gzip 對已經單獨壓縮的圖像等非文本資源來說，效果并不好。

如果我們只需要使用工具庫中少數幾個簡單函數，可以考慮使用原生 JavaScript 代替。不計后果地引入第三方庫，會迅速增大 JavaScript 資源的體積。

2.1.2 對資源進行緩存

緩存在優化頁面加載性能的工作中有舉足輕重的作用，緩存無處不在，包括瀏覽器端、網絡代理、服務端緩存，往往能大幅加快響應速度。

圖：web全鏈路緩存

• HTTP 緩存
• Local Storage
• Cache Storage
• IndexedDB
• CDN

現代瀏覽器都實現了 HTTP 緩存機制。瀏覽器在初次獲取資源后，會根據 HTTP 響應頭部的Cache-Control和ETag字段，來決定該資源的強緩存策略或者協商緩存策略。

Local Storage主要是用來作為本地存儲來使用的，解決了cookie存儲空間不足的問題（cookie中每條cookie的存儲空間為4k），localStorage中一般瀏覽器支持的是5M大小。

Cache Storage它用來存儲 Response 對象的，也就是說用來對 HTTP響應做緩存的，通常在PWA技術中使用。

IndexedDB是一種在瀏覽器中持久存儲數據的方法，允許我們不考慮網絡可用性，創建具有豐富查詢能力的可離線web應用程序。

內容緩存在CDN網絡節點，位于用戶接入點，是面向最終用戶的內容提供設備，可緩存靜態Web內容和流媒體內容，實現內容的邊緣傳播和存儲，以便用戶的就近訪問。

2.1.3 調整資源優先級

通過調整資源加載優先級，保證主體內容能夠較快的被加載完成，通過預加載、懶加載等多種方式，調整資源加載的行為，優化網頁加載性能。

• 預加載
• 預連接與 DNS 預解析
• 預取
• 懶加載
• Service Worker

通過來提前聲明當前頁面所需的資源，以便瀏覽器能預加載這些資源。通過media屬性進行媒體查詢，根據響應式的情況選擇性地預加載資源。

預連接會提前完成 DNS 解析、TCP 握手和 TLS 協商的工作，但并不會提前加載資源。也可以考慮使用，提前與資源建立 socket 連接。

瀏覽器會在空閑時，使用最低優先級下載預取的資源。預取通過聲明，通常用于點擊“下一頁”的頁面動作之前提前加載用戶接下來可能需要的html資源。

按需加載和延時加載都屬于懶加載的范疇，例如對圖像資源采用“懶加載”策略，即僅加載當前在視口內的圖像，對于視口外未加載的圖像，在其即將滾動進入視口時才開始加載。

利用Service Worker 線程脫離在主線程之外來進行 Web 資源和請求的持久離線緩存。

2.1.4 合理拆分代碼

瀏覽器支持并行加載資源，合理拆分資源也是一種有效的優化方法。為了更好的效果，我們往往不需要在首屏一次性加載所有 JavaScript 代碼，合理的拆分代碼、區分開發和生產環境使用少量主要代碼，將當前暫時不需要的代碼拆分出去可以有效加快首屏展現的速度。通過webpack區分開發環境和生產環境差異化配置打包資源可以有效優化代碼，Tree shaking使得模塊間依賴可以通過靜態分析來更好地優化剪枝（僅ES modules支持）。webpack-bundle-analyzer 是一個關于 webpack 構建產物的可視化插件，可以清晰地看到構建產物的體積，幫助分析后續的優化方向。

2.1.5 HTTP/2

HTTP/2帶給WEB帶來了很大的性能提升，同時多路復用、頭部壓縮、Server Push等特點，使得可以在一個連接上同時打開多個流雙向傳輸數據，服務端可以在發送頁面 HTML 時主動推送其它資源，而不用等到瀏覽器解析到相應位置，發起請求再響應。

圖：http1 vs http2

2.2 渲染性能優化

瀏覽器在渲染頁面前，首先會將 HTML 文本內容解析為 DOM，將 CSS 解析為 CSSOM。DOM 和 CSSOM 都是樹狀數據結構，兩者相互獨立，但又有相似之處。接著，瀏覽器會將 DOM 和 CSSOM 樹合并成渲染樹。從 DOM 樹的根節點開始遍歷，并在 CSSOM 樹中查找節點對應的樣式規則，合并成渲染樹中的節點。在遍歷的過程中，不可見的節點將會被忽略。渲染樹隨后會被用于布局，就是計算渲染樹節點在瀏覽器視口中確切的位置和大小。瀏覽器進行一次布局的性能開銷較大，我們需要小心地避免頻繁觸發頁面重新布局。得到渲染樹節點的幾何布局信息后，瀏覽器就可以將節點繪制到屏幕上了，包括繪制文本、顏色、邊框和陰影等。

繪制的過程，首先會根據布局和視覺相關的樣式信息生成一系列繪制操作，隨后執行柵格化（柵格化是將向量圖形格式表示的圖像轉換成位圖以用于顯示器或者打印機輸出的過程），將待繪制項轉換為位圖存儲在 GPU 中，最終通過圖形庫將像素繪制在屏幕上。

圖：瀏覽器渲染過程

頁面不是一次性被繪制出來的。實際上，頁面被分成了多個圖層進行繪制，這些圖層會在另一個單獨的線程里繪制到屏幕上，這個過程被稱作合成。合成線程可以對圖層進行剪切、變換等處理，因此可以用于響應用戶基本的滾動、縮放等操作，又不會受到主線程阻塞的影響。

2.2.1 關鍵渲染路徑

由于渲染都是在主進程中執行的，所以合理的利用主進程渲染非常重要。首屏渲染所必須的關鍵資源，共同組成了關鍵渲染路徑，減少非關鍵渲染路徑的資源消耗可以有效提升渲染速度。

• 延遲非關鍵 CSS 加載
• async 和 defer

Web 應用中往往會有一些首屏渲染時用不到的 CSS，如彈框的樣式等。通過引用的 CSS 都會在加載時阻塞頁面渲染。為了使這些非關鍵 CSS 不阻塞頁面渲染，可以通過拆分資源的方式并延遲非關鍵資源加載。

由于渲染都是在主進程中執行的，所以合理的利用主進程渲染非常重要。首屏渲染所必須的關鍵資源，共同組成了關鍵渲染路徑，減少非關鍵渲染路徑的資源消耗可以有效提升渲染速度。

2.2.2 非阻塞 JavaScript

用戶對于不流暢的滾動或動畫十分敏感，一般要求頁面幀率應達到每秒 60 幀。由于 JavaScript 一般是單線程執行的，長時間執行的任務會阻塞瀏覽器的主線程，使頁面失去響應，出現卡頓和假死的現象。

• 頁面滾動
• requestAnimationFrame 任務在瀏覽器渲染下一幀之前執行
• requestIdleCallback 將任務安排在瀏覽器空閑時執行
• Web Workers

當我們監聽 touchstart、touchmove 等事件時，由于合成線程并不知道我們是否會通過 event.preventDefault() 來阻止默認的滾動行為，從而在每次事件觸發時，都會等待事件處理函數執行完畢后再進行頁面滾動。這通常會導致較明顯的延遲，影響頁面滾動的流暢性。通過在addEventListener()時聲明{passive: true}，來表明事件處理函數不會阻止頁面滾動，使得用戶的操作更快得到響應。

我們可以將一些耗性能的邏輯放在 worker 線程中進行處理，這樣主線程就能繼續響應用戶操作和渲染頁面了。

2.2.3 降低渲染樹計算復雜性

結構越復雜的頁面往往性能越差，動畫多的頁面出現卡頓的幾率也越大。

• 減少查找與元素匹配成本
• 減少布局次數
• 優化繪制與合成

渲染樹由 DOM 和 CSSOM 樹合并而成，對于每個 DOM 元素，需要查找與元素匹配的樣式規則。CSS Modules 是一種較為主流的 CSS-in-JS 解決方案，利用 webpack 等構建工具，可以對類選擇器生成自定義格式的唯一類名，同樣能減少瀏覽器匹配 CSS 選擇器的開銷。

瀏覽器進行一次布局的開銷很大，所以我們需要盡可能避免直接修改這些屬性，尤其是不應將布局屬性用于動畫效果，否則會出現明顯的掉幀現象。

修改絕大多數樣式屬性都會導致頁面重繪，這很難避免。僅有的例外是transform和opacity，這是由于它們可以僅由合成器操作圖層來實現。transform和opacity非常適合用于實現動畫效果，但我們仍需要通過will-change為它們創建獨立的圖層，避免影響其他圖層的繪制。

2.3 框架優化方法

CSR、SSR、NSR、ESR、hybrid離線包、Big pipe、app cache等，都是不錯的方法。

2.3.1 CSR（Client Side Render）

瀏覽器渲染顧名思義就是所有的頁面渲染、邏輯處理、頁面路由、接口請求均是在瀏覽器中發生，也就是從服務端請求一個簡單HTML文件然后通過執行JavaScript在HTML上進行內容的添加。其實，現代主流的前端框架均是這種渲染方式，這種渲染方式的好處在于實現了前后端架構分離，利于前后端職責分離，并且能夠首次渲染迅速有效減少白屏時間。同時，CSR可以通過在打包編譯階段進行預渲染或者骨架屏生成，可以進一步提升首次渲染的用戶體驗。

圖：CSR

2.3.2 SSR（Server Side Render）

服務端渲染則是在服務端完成頁面的渲染，在服務端完成頁面模板、數據填充、頁面渲染，然后將完整的HTML內容返回給到瀏覽器。由于所有的渲染工作都在服務端完成，因此網站的首屏時間和TTI都會表現比較好。

圖：SSR

但是，渲染需要在服務端完成，并不能很好進行前后端職責分離，而且白屏時間也會比較長，同時，對于服務端的負載要求也會比較高。

2.3.3 NSR（Native Side Render）

GMTC2019 全球大前端技術上 UC 團隊提到了 0.3 秒的 “閃開” 方案。這種方案適用于混合開發，NSR本質是分布式SSR，通過加載離線頁面模板，Ajax預加載頁面數據，Native渲染生成Html數據并且緩存在客戶端，將服務器的渲染工作放在了一個個獨立的移動設備中，實現了頁面的預加載，同時又不會增加額外的服務器壓力。核心思路是借助瀏覽器啟用一個 JS-Runtime，提前將下載好的 html 模板及預取的 feed 流數據進行渲染，然后將 html 設置到內存級別的 MemoryCache 中，從而達到點開即看的效果。

圖：NSR

2.3.4 ESR（Edge Side Render）

邊緣渲染的核心思想是，借助邊緣計算的能力，將靜態內容與動態內容以流式的方式，先后返回給用戶。CDN 節點相比于Server距離用戶更近，有著更短的網絡延時。在 CDN 節點上將可緩存的頁面靜態部分先快速返回給用戶，同時在 CDN 節點上發起動態部分內容請求，并將動態內容在靜態部分的響應流后繼續返回給用戶。

圖：ESR

03

收益衡量

速度是應用性能最直接體現。做性能收益衡量也需要多維度全方位的進行分析與對比。通過等量實驗組和對照組在核心指標方面大量真實數據的分位值對比，可以得到性能方面的收益，也可以關聯到用戶PV、UV以及收入等方面是數據收益。

監控網站真實用戶可感知的白屏、首屏、可交互等用戶體驗指標，從服務器端響應時間、網絡延時、DOM解析等細致指標的變化也可以做日常性能優化。

• 統計核心指標不同分位數的占比數據。
• 統計不同版本瀏覽器和設備類型的核心指標數據，基于多平臺瀏覽器性能分析。
• 統計不同區域（包括國家、省份、城市）、不同運營商以及接入方式（包括2G/3G/4G/WiFi）下的各關鍵網絡性能指標。

圖：性能平臺

業內不錯的性能監控平臺包括ONEAPM、聽云、性能魔方等，各個大公司和云平臺也都提供不錯的相關監控服務。

04

總結

你做事的時候不只是靠經驗教訓的歷史積累，還有一套系統的流程或者模板。做性能優化是一件需要具有閉環思維的事情，特別是這種端到端的優化要注意事前規劃、事中執行和事后總結三個階段，而且還要結合不同的業務場景進行優化，有時候還要與客戶端相協同，并不是生拉硬套就可以完成的事情。

甚至很多大廠的業務前端還要一邊解決歷史包袱，一邊進行優化，小心前行！隨著優化后業務仍然在不斷的迭代和發展，如何鞏固性能優化結果也是一件任重道遠持續投入的事情，掌握性能優化基本原理結合具有優秀性能結構設計或許是一種智慧的方法。

參考資料

• Web 性能優化資源合集（持續更新） | 微談 Web 前端性能優化-https://naluduo.vip/Web-Performance-Optimization/reference/#%E8%B0%83%E8%AF%95%E5%B7%A5%E5%85%B7
• 以用戶為中心的性能指標-https://web.dev/i18n/zh/user-centric-performance-metrics/
• 使用window.performance分析web前端性能 - 五藝 - 博客園-https://www.cnblogs.com/y896926473/articles/7466951.html
• HOME · PWA 應用實戰-https://lavas-project.github.io/pwa-book/
• 網頁渲染流程詳解-https://www.jianshu.com/p/7659d714a642
• 詳解web緩存-https://zhuanlan.zhihu.com/p/90507417