前言
自JavaScript誕生以來，前端技術發展非常迅速。移動端白屏優化是前端介面體驗的一個重要優化方向，Web 前端誕生了 SSR 、CSR、預渲染等技術。在美團支付的前端技術體系裡，通過預渲染提升網頁首幀優化，從而優化了白屏問題，提升使用者體驗，並形成了最佳實踐。
在前端渲染領域，主要有以下幾種方式可供選擇：
| CSR | 預渲染 | SSR | 同構 | |
|---|---|---|---|---|
| 優點 | ||||
| 缺點 |
通過對比，同構方案集合 CSR 與 SSR 的優點，可以適用於大部分業務場景。但由於在同構的系統架構中，連線前後端的 Node 中間層處於核心鏈路，系統可用性的瓶頸就依賴於 Node ，一旦作為短板的 Node 掛了，整個服務都不可用。
結合到我們團隊負責的支付業務場景裡，由於支付業務追求極致的系統穩定性，服務不可用直接影響到客訴和資損，因此我們採用瀏覽器端渲染的架構。在保證系統穩定性的前提下，還需要保障使用者體驗，所以採用了預渲染的方式。
那麼究竟什麼是預渲染呢？什麼是 FCP/FMP 呢？我們先從最常見的 CSR 開始說起。
以 Vue 舉例，常見的 CSR 形式如下：
一切看似很美好。然而，作為以使用者體驗為首要目標的我們發現了一個體驗問題：首屏白屏問題。
為什麼會首屏白屏
瀏覽器渲染包含 HTML 解析、DOM 樹構建、CSSOM 構建、JavaScript 解析、佈局、繪製等等，大致如下圖所示：
要搞清楚為什麼會有白屏，就需要利用這個理論基礎來對實際專案進行具體分析。通過 DevTools 進行分析：
- 等待 HTML 文件返回，此時處於白屏狀態。
- 對 HTML 文件解析完成後進行首屏渲染，因為專案中對加了灰色的背景色，因此呈現出灰屏。
- 進行檔案載入、JS 解析等過程，導致介面長時間出於灰屏中。
- 當 Vue 例項觸發了 mounted 後，介面顯示出大體框架。
- 呼叫 API 獲取到時機業務資料後才能展示出最終的頁面內容。
由此得出結論，因為要等待檔案載入、CSSOM 構建、JS 解析等過程，而這些過程比較耗時，導致使用者會長時間出於不可互動的首屏灰白屏狀態，從而給使用者一種網頁很“慢”的感覺。那麼一個網頁太“慢”，會造成什麼影響呢？
“慢”的影響
Global Web Performance Matters for ecommerce的報告中指出：
- 57%的使用者更在乎網頁在3秒內是否完成載入。
- 52%的線上使用者認為網頁開啟速度影響到他們對網站的忠實度。
- 每慢1秒造成頁面 PV 降低11%，使用者滿意度也隨之降低降低16%。
- 近半數移動使用者因為在10秒內仍未開啟頁面從而放棄。
我們團隊主要負責美團支付相關的業務，如果網站太慢會影響使用者的支付體驗，會造成客訴或資損。既然網站太“慢”會造成如此重要的影響，那要如何優化呢？
優化思路
在User-centric Performance Metrics一文中，共提到了4個頁面渲染的關鍵指標：
基於這個理論基礎，再回過頭來看看之前專案的實際表現：
可見在 FP 的灰白屏介面停留了很長時間，使用者不清楚網站是否有在正常載入，使用者體驗很差。
試想：如果我們可以將 FCP 或 FMP 完整的 HTML 文件提前到 FP 時機預渲染，使用者看到頁面框架，能感受到頁面正在載入而不是冷冰冰的灰白屏，那麼使用者更願意等待頁面載入完成，從而降低了流失率。並且這種改觀在弱網環境下更明顯。
通過對比 FP、FCP、FMP 這三個時期 DOM 的差異，發現區別在於：
- FP：僅有一個 div 根節點。
- FCP：包含頁面的基本框架，但沒有資料內容。
- FMP：包含頁面所有元素及資料。
仍然以 Vue 為例， 在其生命週期中，mounted 對應的是 FCP，updated 對應的是 FMP。那麼具體應該使用哪個生命週期的 HTML 結構呢？
| mounted (FCP) | updated (FMP) | |
|---|---|---|
| 缺點 | ||
| 優點 |
通過以上的對比，最終選擇在 mounted 時觸發構建時預渲染。由於我們採用的是 CSR 的架構，沒有 Node 作為中間層，因此要實現 DOM 內容的預渲染，就需要在專案構建編譯時完成對原始模板的更新替換。
至此，我們明確了構建時預渲染的大體方案。
構建時預渲染方案
構建時預渲染流程：
配置讀取
由於 SPA 可以由多個路由構成，需要根據業務場景決定哪些路由需要用到預渲染。因此這裡的配置檔案主要是用於告知編譯器需要進行預渲染的路由。
在我們的系統架構裡，腳手架是基於 Webpack 自研的，在此基礎上可以自定義自動化構建任務和配置。
觸發構建
專案中主要是使用 TypeScript，利用 TS 的裝飾器，我們封裝了統一的預渲染構建的鉤子方法，從而只用一行程式碼即可完成構建時預渲染的觸發。
裝飾器：
使用：
構建編譯
從流程圖上，需要在釋出機上啟動模擬的瀏覽器環境，並通過預渲染的事件鉤子獲取當前的頁面內容，生成最終的 HTML 檔案。
由於我們在預渲染上的嘗試比較早，當時還沒有 Headless Chrome 、 Puppeteer、Prerender SPA Plugin等，因此在選型上使用的是 phantomjs-prebuilt（Prerender SPA Plugin 早期版本也是基於 phantomjs-prebuilt 實現的）。
通過 phantom 提供的 API 可獲得當前 HTML，示例如下：
為了提高構建效率，並行對配置的多個頁面或路由進行預渲染構建，保證在 5S 內即可完成構建，流程圖如下：
方案優化
理想很豐滿，現實很骨感。在實際投產中，構建時預渲染方案遇到了一個問題。
我們梳理一下簡化後的專案上線過程：
開發 -> 編譯 -> 上線
假設本次修改了靜態檔案中的一個 JS 檔案，這個檔案會通過 CDN 方式在 HTML 裡引用，那麼最終在 HTML 文件中的引用方式是 <script src="http://cdn.com/index.js"></script>。然而由於專案還沒有上線，所以其實通過完整 URL 的方式是獲取不到這個檔案的；而預渲染的構建又是在上線動作之前，所以問題就產生了：
構建時預渲染無法正常獲取檔案，導致編譯報錯
怎麼辦？
請求劫持
因為在做預渲染時，我們使用啟動了一個模擬的瀏覽器環境，根據 phantom 提供的 API，可以對發出的請求加以劫持，將獲取 CDN 檔案的請求劫持到本地，從而在根本上解決了這個問題。示例程式碼如下：
構建時預渲染研發流程及效果
最終，構建時預渲染研發流程如下：
開發階段：
- 通過 TypeScript 的裝飾器單行引入預渲染構建觸發的方法。
- 釋出前修改編譯構建的配置檔案。
釋出階段：
- 先進行常規的專案構建。
- 若有預渲染相關配置，則觸發預渲染構建。
- 通過預渲染得到最終的檔案，並完成釋出上線動作。
完整的使用者請求路徑如下：
通過構建時預渲染在專案中的使用，FCP 的時間相比之前減少了 75%。
作者簡介
寒陽，美團資深研發工程師，多年前端研發經歷，負責美團支付錢包團隊和美團支付前端基礎技術。