導(dǎo)讀： 用戶體驗是web產(chǎn)品非常重要的部分，核心是讓用戶使用舒服，幫助用戶流暢地得到所求，用戶體驗的優(yōu)劣甚至?xí)绊懙接脩舻牧舸?。體驗差的網(wǎng)站各有各的不同，但是體驗好的網(wǎng)站往往都有一些共性，這些優(yōu)秀的特征凝結(jié)了設(shè)計師、研發(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)化方面的實(shí)踐，著重分享一下首屏性能優(yōu)化的一些經(jīng)驗。

01

性能采集

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

圖：性能API標(biāo)準(zhǔn)（摘錄51CTO圖片）

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

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

圖：Navigation Timing關(guān)系圖（摘錄W3C）

在獲取用戶訪問Timing數(shù)據(jù)的前提下，我們可以結(jié)合具體業(yè)務(wù)場景定義訪問性能的核心指標(biāo)，例如白屏?xí)r間、首屏?xí)r間FSP、用戶可交互時間TTI、頁面onload時間等作為核心優(yōu)化指標(biāo)，其中首屏?xí)r間和用戶可交互時間需要單獨(dú)埋點(diǎn)自定義。

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

通過使用API對各個階段性能指標(biāo)進(jìn)行采集，等待到所有數(shù)據(jù)都獲取完成之后，通過網(wǎng)絡(luò)請求將數(shù)據(jù)發(fā)送到服務(wù)器用作后續(xù)數(shù)據(jù)分析使用。

02

性能優(yōu)化

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

2.1 加載性能優(yōu)化

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

2.1.1 減小資源體積

• 壓縮文本內(nèi)容
• 優(yōu)化JavaScript第三方庫引入

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

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

2.1.2 對資源進(jìn)行緩存

緩存在優(yōu)化頁面加載性能的工作中有舉足輕重的作用，緩存無處不在，包括瀏覽器端、網(wǎng)絡(luò)代理、服務(wù)端緩存，往往能大幅加快響應(yīng)速度。

圖：web全鏈路緩存

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

現(xiàn)代瀏覽器都實(shí)現(xiàn)了 HTTP 緩存機(jī)制。瀏覽器在初次獲取資源后，會根據(jù) HTTP 響應(yīng)頭部的Cache-Control和ETag字段，來決定該資源的強(qiáng)緩存策略或者協(xié)商緩存策略。

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

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

IndexedDB是一種在瀏覽器中持久存儲數(shù)據(jù)的方法，允許我們不考慮網(wǎng)絡(luò)可用性，創(chuàng)建具有豐富查詢能力的可離線web應(yīng)用程序。

內(nèi)容緩存在CDN網(wǎng)絡(luò)節(jié)點(diǎn)，位于用戶接入點(diǎn)，是面向最終用戶的內(nèi)容提供設(shè)備，可緩存靜態(tài)Web內(nèi)容和流媒體內(nèi)容，實(shí)現(xiàn)內(nèi)容的邊緣傳播和存儲，以便用戶的就近訪問。

2.1.3 調(diào)整資源優(yōu)先級

通過調(diào)整資源加載優(yōu)先級，保證主體內(nèi)容能夠較快的被加載完成，通過預(yù)加載、懶加載等多種方式，調(diào)整資源加載的行為，優(yōu)化網(wǎng)頁加載性能。

• 預(yù)加載
• 預(yù)連接與 DNS 預(yù)解析
• 預(yù)取
• 懶加載
• Service Worker

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

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

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

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

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

2.1.4 合理拆分代碼

瀏覽器支持并行加載資源，合理拆分資源也是一種有效的優(yōu)化方法。為了更好的效果，我們往往不需要在首屏一次性加載所有 JavaScript 代碼，合理的拆分代碼、區(qū)分開發(fā)和生產(chǎn)環(huán)境使用少量主要代碼，將當(dāng)前暫時不需要的代碼拆分出去可以有效加快首屏展現(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帶來了很大的性能提升，同時多路復(fù)用、頭部壓縮、Server Push等特點(diǎn)，使得可以在一個連接上同時打開多個流雙向傳輸數(shù)據(jù)，服務(wù)端可以在發(fā)送頁面 HTML 時主動推送其它資源，而不用等到瀏覽器解析到相應(yīng)位置，發(fā)起請求再響應(yīng)。

圖：http1 vs http2

2.2 渲染性能優(yōu)化

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

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

圖：瀏覽器渲染過程

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

2.2.1 關(guān)鍵渲染路徑

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

• 延遲非關(guān)鍵 CSS 加載
• async 和 defer

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

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

2.2.2 非阻塞 JavaScript

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

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

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

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

2.2.3 降低渲染樹計算復(fù)雜性

結(jié)構(gòu)越復(fù)雜的頁面往往性能越差，動畫多的頁面出現(xiàn)卡頓的幾率也越大。

• 減少查找與元素匹配成本
• 減少布局次數(shù)
• 優(yōu)化繪制與合成

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

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

修改絕大多數(shù)樣式屬性都會導(dǎo)致頁面重繪，這很難避免。僅有的例外是transform和opacity，這是由于它們可以僅由合成器操作圖層來實(shí)現(xiàn)。transform和opacity非常適合用于實(shí)現(xiàn)動畫效果，但我們?nèi)孕枰ㄟ^will-change為它們創(chuàng)建獨(dú)立的圖層，避免影響其他圖層的繪制。

2.3 框架優(yōu)化方法

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

2.3.1 CSR（Client Side Render）

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

圖：CSR

2.3.2 SSR（Server Side Render）

服務(wù)端渲染則是在服務(wù)端完成頁面的渲染，在服務(wù)端完成頁面模板、數(shù)據(jù)填充、頁面渲染，然后將完整的HTML內(nèi)容返回給到瀏覽器。由于所有的渲染工作都在服務(wù)端完成，因此網(wǎng)站的首屏?xí)r間和TTI都會表現(xiàn)比較好。

圖：SSR

但是，渲染需要在服務(wù)端完成，并不能很好進(jìn)行前后端職責(zé)分離，而且白屏?xí)r間也會比較長，同時，對于服務(wù)端的負(fù)載要求也會比較高。

2.3.3 NSR（Native Side Render）

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

圖：NSR

2.3.4 ESR（Edge Side Render）

邊緣渲染的核心思想是，借助邊緣計算的能力，將靜態(tài)內(nèi)容與動態(tài)內(nèi)容以流式的方式，先后返回給用戶。CDN 節(jié)點(diǎn)相比于Server距離用戶更近，有著更短的網(wǎng)絡(luò)延時。在 CDN 節(jié)點(diǎn)上將可緩存的頁面靜態(tài)部分先快速返回給用戶，同時在 CDN 節(jié)點(diǎn)上發(fā)起動態(tài)部分內(nèi)容請求，并將動態(tài)內(nèi)容在靜態(tài)部分的響應(yīng)流后繼續(xù)返回給用戶。

圖：ESR

03

收益衡量

速度是應(yīng)用性能最直接體現(xiàn)。做性能收益衡量也需要多維度全方位的進(jìn)行分析與對比。通過等量實(shí)驗組和對照組在核心指標(biāo)方面大量真實(shí)數(shù)據(jù)的分位值對比，可以得到性能方面的收益，也可以關(guān)聯(lián)到用戶PV、UV以及收入等方面是數(shù)據(jù)收益。

監(jiān)控網(wǎng)站真實(shí)用戶可感知的白屏、首屏、可交互等用戶體驗指標(biāo)，從服務(wù)器端響應(yīng)時間、網(wǎng)絡(luò)延時、DOM解析等細(xì)致指標(biāo)的變化也可以做日常性能優(yōu)化。

• 統(tǒng)計核心指標(biāo)不同分位數(shù)的占比數(shù)據(jù)。
• 統(tǒng)計不同版本瀏覽器和設(shè)備類型的核心指標(biāo)數(shù)據(jù)，基于多平臺瀏覽器性能分析。
• 統(tǒng)計不同區(qū)域（包括國家、省份、城市）、不同運(yùn)營商以及接入方式（包括2G/3G/4G/WiFi）下的各關(guān)鍵網(wǎng)絡(luò)性能指標(biāo)。

圖：性能平臺

業(yè)內(nèi)不錯的性能監(jiān)控平臺包括ONEAPM、聽云、性能魔方等，各個大公司和云平臺也都提供不錯的相關(guān)監(jiān)控服務(wù)。

04

總結(jié)

你做事的時候不只是靠經(jīng)驗教訓(xùn)的歷史積累，還有一套系統(tǒng)的流程或者模板。做性能優(yōu)化是一件需要具有閉環(huán)思維的事情，特別是這種端到端的優(yōu)化要注意事前規(guī)劃、事中執(zhí)行和事后總結(jié)三個階段，而且還要結(jié)合不同的業(yè)務(wù)場景進(jìn)行優(yōu)化，有時候還要與客戶端相協(xié)同，并不是生拉硬套就可以完成的事情。

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

參考資料

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