京東PLUS前端H5性能優化實踐
?前言
隨著移動互聯網的發展，用戶對產品的使用體驗要求越來越高。H5 作為業務的重要載體，應用非常廣泛，如何把控好 H5 的性能是一門重要的工作。因此 H5 頁面性能是一個非常核心的用戶體驗指標。
研究表明一個網頁加載的快慢會直接影響用戶在這個頁面逗留的時長，用戶在發現頁面有內容呈現的時候，如果在頁面進行了點擊但是頁面沒有立即響應，用戶通常會認為頁面加載出現了延遲；如果頁面在加載過程中某些元素發生了大幅度的偏移，這對于用戶來說體驗是相當糟糕的。
因此提高用戶體驗應從頁面的渲染速度、響應能力及頁面的抖動情況考慮，目前比較主流的衡量頁面指標的參數是谷歌 lighthouse 提出的幾個指標， 主要包括 FCP（First Contentful Paint）, LCP（Largest Contentful Paint）, CLS（Cumulative Layout Shift）, TTI（Time To Interactive）, TBT（Total Blocking Time）等。下面我們將從FCP、LCP、CLS、TTI、TBT五個指標來進行一一介紹。
FCP
FCP（First Contentful Paint）是指頁面從開始加載到頁面內容的任何部分在屏幕上完成渲染的時間，也就是我們通常所說的首次內容繪制時間，它是測量感知加載速度的一個重要指標。那么什么“內容”才算FCP的呢，其中包含了文本、圖像（包括背景圖像）、<svg>元素或非白色的<canvas>元素。
LCP
LCP（Largest Contentful Paint）是根據頁面首次開始加載的時間點來報告可視區域內最大圖像或文本塊完成渲染的相對時間。最大內容繪制表示著頁面的主要內容已經加載完成，它的檢測是通過Element Timming API來提供支持，使用的也是通過性能監聽事件的一個方式。那哪些元素在LCP的計算之內呢？除了常見的<img>元素，<video>元素、通過url元素加載的背景圖像以及包含文本節點或其他行內級文本元素子元素的塊級元素都在計算范圍之內。需要注意的是LCP的計算是一個動態的過程。
CLS
CLS（Cumulative Layout Shift）是指整個頁面中所有意外布局偏移中最大一連串的布局偏移分數，即我們通常所說的累計布局偏移，其中一連串的布局偏移，也叫會話窗口，是指一個或多個連續發生的單次布局偏移，每次偏移相隔的時間少于1秒，且整個窗口的最大持續時長為5秒。就像下圖中的灰色文字區域在頁面加載時如果發生了位移，那么它的位移就會被計入CLS的分數。
TTI
TTI（Time To Interactive）是指頁面從開始加載到主要子資源完成渲染，并且能夠快速、可靠的響應用戶輸入的時間，通常我們也叫可交互時間。那么TTI是如何計算的呢，如下圖首先沿時間軸正向搜索時長至少為5秒的安靜窗口（安靜窗口是指沒有長任務且不超過兩個正在處理的網絡get請求），然后沿時間軸反向搜索安靜窗口之前的最后一個長任務，如果沒有找到長任務，則在FCP步驟停止執行，TTI就是安靜窗口之前最后一個長任務的結束時間，如果沒有找到長任務的話，則與FCP值相同。
TBT
TBT（Total Blocking Time）是測量FCP與TTI之間的總時間，這期間，主線程被阻塞的時間過長，無法作出輸入響應。我們通常把任務時間超過50毫秒的任務稱之為長任務，那么一個頁面的總阻塞時間其實就是FCP和TTI之間發生每個長任務的阻塞時間總和。如下圖淡紅色區域的時間總和就是這個頁面的TBT分數。
如何檢測頁面性能？
在介紹了相關的指標之后，如何知道一個頁面性能的好壞呢？我們PLUS團隊聯合燭龍團隊在基于lighthouse的基礎上，結合我們京東實際的業務情況，共同開發了一套性能監控的SDK，在其中明確的提出了H5和PC兩套性能評分標準，并且給出了性能良好與較差的閾值。
如何做性能優化？
在深入了解各項指標之后，我們來看一下如何對頁面進行性能優化。一個頁面從輸入URL到頁面最后在瀏覽器的渲染流程大致如下：
- URL解析 => DNS解析 => 建立TCP連接 => 客戶端發送請求 => 服務器處理和響應請求 => 瀏覽器解析并渲染響應內容 => 斷開TCP鏈接
可以看到其中從URL解析開始到服務器響應請求的過程都是屬于網絡層面，瀏覽器解析渲染相應內容屬于渲染層面，接下來我們就將從網絡層面和渲染層面這兩個大方向來看一下如何去做性能優化。
我們都知道，在網絡層面其實對于前端工程師來講可優化的點并不多，但是通過網絡層面的優化，可以極大程度上降低TTFB的等待時間，從而提高FCP、LCP、TTI、TBT這些指標的分數，下面是一些常見優化方式：
- 緩存技術：我們可以合理的使用緩存，如CDN緩存、瀏覽器緩存以及應用離線包，來減少資源的請求。除了這些，還可以在接口中設置Expires 和 Cache-Control 利用http緩存來減少接口的請求時間。
- 服務端還可以使用http2/http3、減少重定向等方式來保證我們的接口響應速度。
在了解了網絡層面的一些優化方式之后，我們主要來看下在渲染層面如何進行優化，首先，我們來看一下瀏覽器的渲染機制，大概分為以下幾個步驟：
- 解析HTML，生成DOM樹，解析CSS，生成CSSOM樹。
- 將DOM樹和CSSOM樹結合，生成渲染樹。
- 計算圖層布局。
- 繪制圖層。
- 合成圖層，顯示頁面。
在解析HTML的過程中會去請求頁面所需的js/css等靜態資源，對于資源請求這部分，我們可以進行一些特定的優化，讓我們的資源能夠更快速的進行加載，減少TTFB等待時間，從而提高FCP、LCP、TTI以及TBT的分數，比如：
- 可以通過添加preconnect和dns-prefetch屬性預鏈接所需要的源，其中preconnect可以提前建立連接，但是如果在10秒內沒有使用連接，瀏覽器會關閉它，從而浪費一些早期的連接占用CPU的時間，dns-prefetch會在請求資源時提前進行域名解析。
- 如果我們想要提前加載資源，可以添加preload屬性來預先加載一些關鍵的資源，幫助頁面更快的進行渲染。
- 還可以將不重要的script腳本添加async和defer屬性，然后提取重要的css，多余的css分割成不同的文件，將不重要的文件添加media屬性來消除阻塞渲染。
如果想更快的完成資源的請求，我們也可以對資源進行優化，使產出的文件體積更小，文件請求耗時更短，這也能使我們的FCP和LCP分數得以提高：
- 移除未使用的css/js，如何能夠快速檢查出哪些代碼我們有用到呢，可以打開Chrome => 開發者工具 => shift + alt + p 搜索Coverage Tab，點擊刷新可以看到資源的請求狀況以及可用代碼覆蓋率，然后點擊打開每個資源，可以查看具體內容有沒有被使用，其中綠色部分為關鍵代碼，紅色部分為非關鍵代碼，可以通過刪除紅色部分代碼來減小靜態資源的體積。
- 通過webpack/rollup/gulp等構建工具對代碼進行打包壓縮
- 對資源進行gzip壓縮
- 將資源進行拆分（包括css、js），并按需引用，并且延遲加載優先級較低的js
- 對于圖片我們可以使用工具進行圖像壓縮，也可以使用圖像cdn，格式最好使用webp，將大大減少圖片的大小，對于大型的gif可以轉為視頻
在解析完html之后，瀏覽器會識別并加載所有的 CSS 樣式信息與 DOM 樹合并，最終生成頁面渲染樹，我們在寫css的時候，需要注意以下幾點，這樣可以使我們的頁面能夠更快速的渲染出來。
- 減少css選擇器的層級，避免多層嵌套
- 避免使用較多的css表達式
- 對于css動畫，盡量使用 transform（transform可開啟硬件加速）
- 對于一些特定的動畫，可以選擇使用requestAnimationFrame 代替
當瀏覽器生成渲染樹以后，就會根據渲染樹來進行布局，然后圖層會進行計算和繪制，最后合成圖層在頁面顯示出來。在這個渲染的過程中，我們可以進行以下的優化：
- 避免DOM過大或者多層嵌套
- 避免批量的對DOM進行修改
除了對網絡和渲染兩個層面優化之外，我們也可以針對特定的指標進行優化。
1. 對于FCP和LCP，還可以在HTML中增加骨架屏，或者使用服務端渲染的方式進行優化，同時也可以提升用戶體驗。
2. 對于CLS該如何進行優化呢？我們首先來分析一下CLS偏移較大產生的原因，常見的原因主要有：無尺寸的頭像、廣告，動態注入的內容，在更新 DOM 之前等待網絡響應的操作等。那么如何解決呢？我們可以給圖像設置長寬比，增加占位符，給動態注入的元素留出預留空間，有些情況下雖然不能完全避免位移偏差，但會盡可能減少CLS。
3. 對于TTI和TBT，影響這兩個指標的其實最多的就是長任務的執行，長任務可以在瀏覽器performance面板查看（如下圖），我們點擊圖中紅色長任務可以看到這個任務中執行的內容，從而去分析做一些優化，這里也提供幾點對與長任務優化的建議：
- 頁面首屏的數據最好聚合到一個接口中，這樣既能保證在接口返回之后首屏可以直接渲染，還能避免多個接口請求引起的長任務。
- 減少頁面的重復渲染，如使用react hooks中的 useMemo、useCallback，加入鉤子依賴來避免組件的重復渲染。
- 降低不重要接口請求的優先級，如埋點上報，可以利用requestIdleCallback api在瀏覽器空閑時再進行上報。
PLUS性能優化實踐
我們在分析了如何對頁面進行性能優化之后，來看一下PLUS團隊在性能優化方面做的一些實踐。我們選用了PLUS流量比較大的兩個頁面作為實驗，由于這兩個頁面在線上已經迭代了很多年并且頁面中之前老邏輯設計的比較復雜，所以導致這兩個頁面各項性能指標相對較低。未試用首頁分數、會員店分數都較低。我們在分析了相關的代碼之后，對各項指標做了專門的優化。
拿未試用首頁來講：
1. 在FCP和LCP方面，添加了DNS預熱并且對骨架屏做了調整。
- 首先給頁面中的靜態資源、圖片地址設置了DNS預解析。通過 dns-prefetch 提前建立域名解析。當瀏覽網頁時，瀏覽器會在加載過程中對網頁中的域名進行解析緩存，這樣在點擊當前網頁連接時無需進行DNS解析，從而減少等待時間。
- 還對骨架屏也進行了調整，通過在HTML里設置骨架屏，在頁面數據尚未加載前，先給用戶展示出大致結構，直到請求返回后再補充需要顯示的數據內容，既降低了用戶的焦灼情緒，又能使頁面加載過程變得自然通暢，不會造成長時間的白屏或閃爍，同時也提高了FCP的分數。
2. CLS方面，我們通過分析得知，影響CLS的主要原因是如果在APP內使用沉浸式頭的話，由于沉浸式頭部是異步調用獲取的，就導致它會造成頭部高度偏移，頁面抖動。我們通過判斷不同機型給定不同的沉浸式初始高度，等待沉浸式異步返回后再重新設置，從而減少了頁面抖動及布局偏移。優化前后CLS對比如下圖：
3. 在TTI和TBT方面，我們做了如下優化：
- 首先對接口優先級做了調整，針對業務本身，評估接口調用優先級。優先請求首屏核心接口，針對可能出現的造成網頁偏移的數據字段優先處理，統一返回，從而減少位移。
- 在打包優化上，通過webpack對業務包和公用包進行抽離，從而降低單個包體積過大的問題。
- 利用瀏覽器空閑時間進行埋點上報和低優先級接口請求，在頁面中有許多的權益Icon圖標的埋點，我們把這些埋點上報的請求利用瀏覽器requestIdleCallback Api使請求在瀏覽器空閑時再進行上報，從而減少主線程的繁忙程度，更快的完成首屏渲染，以下是封裝的requestIdleCallback的部分代碼：
?
- 樓層懶渲染：樓層內容不在首屏展示，因此初始化樓層填充 loading 進行占位，通過 observe 監聽樓層出現在可視區再進行真實接口請求及渲染。這樣的話大大減少了首屏要請求的接口數量。
經過以上的優化，我們可以看一下未試用首頁的最終成果。從視頻的加載效果來看明顯是比之前好的。PLUS會員店優化后性能也獲得了大幅度提升。
未試用首頁-優化前后對比視頻：
結語
在前端的領域中，性能優化是個永久的話題，性能優化的經驗既需要對技術極致的追求，也需要持續的積累沉淀。未來我們將做更深入的探索，如使用webWorker，Hybrid等技術持續優化前端H5頁面，以給到用戶更好的體驗。
