摘要：在美團(tuán)支付的前端技術(shù)體系里，通過預(yù)渲染提升網(wǎng)頁首幀優(yōu)化，從而優(yōu)化了白屏問題，提升用戶體驗(yàn)，并形成了最佳實(shí)踐。我們團(tuán)隊(duì)主要負(fù)責(zé)美團(tuán)支付相關(guān)的業(yè)務(wù)，如果網(wǎng)站太慢會影響用戶的支付體驗(yàn)，會造成客訴或資損。

自JavaScript誕生以來，前端技術(shù)發(fā)展非常迅速。移動端白屏優(yōu)化是前端界面體驗(yàn)的一個重要優(yōu)化方向，Web 前端誕生了 SSR 、CSR、預(yù)渲染等技術(shù)。在美團(tuán)支付的前端技術(shù)體系里，通過預(yù)渲染提升網(wǎng)頁首幀優(yōu)化，從而優(yōu)化了白屏問題，提升用戶體驗(yàn)，并形成了最佳實(shí)踐。

在前端渲染領(lǐng)域，主要有以下幾種方式可供選擇：

通過對比，同構(gòu)方案集合 CSR 與 SSR 的優(yōu)點(diǎn)，可以適用于大部分業(yè)務(wù)場景。但由于在同構(gòu)的系統(tǒng)架構(gòu)中，連接前后端的 Node 中間層處于核心鏈路，系統(tǒng)可用性的瓶頸就依賴于 Node ，一旦作為短板的 Node 掛了，整個服務(wù)都不可用。

結(jié)合到我們團(tuán)隊(duì)負(fù)責(zé)的支付業(yè)務(wù)場景里，由于支付業(yè)務(wù)追求極致的系統(tǒng)穩(wěn)定性，服務(wù)不可用直接影響到客訴和資損，因此我們采用瀏覽器端渲染的架構(gòu)。在保證系統(tǒng)穩(wěn)定性的前提下，還需要保障用戶體驗(yàn)，所以采用了預(yù)渲染的方式。

那么究竟什么是預(yù)渲染呢？什么是 FCP/FMP 呢？我們先從最常見的 CSR 開始說起。

以 Vue 舉例，常見的 CSR 形式如下：

一切看似很美好。然而，作為以用戶體驗(yàn)為首要目標(biāo)的我們發(fā)現(xiàn)了一個體驗(yàn)問題：首屏白屏問題。

瀏覽器渲染包含 HTML 解析、DOM 樹構(gòu)建、CSSOM 構(gòu)建、JavaScript 解析、布局、繪制等等，大致如下圖所示：

要搞清楚為什么會有白屏，就需要利用這個理論基礎(chǔ)來對實(shí)際項(xiàng)目進(jìn)行具體分析。通過 DevTools 進(jìn)行分析：

等待 HTML 文檔返回，此時處于白屏狀態(tài)。

對 HTML 文檔解析完成后進(jìn)行首屏渲染，因?yàn)轫?xiàng)目中對 id="app加了灰色的背景色，因此呈現(xiàn)出灰屏。

進(jìn)行文件加載、JS 解析等過程，導(dǎo)致界面長時間出于灰屏中。

當(dāng) Vue 實(shí)例觸發(fā)了 mounted 后，界面顯示出大體框架。

調(diào)用 API 獲取到時機(jī)業(yè)務(wù)數(shù)據(jù)后才能展示出最終的頁面內(nèi)容。

由此得出結(jié)論，因?yàn)橐却募虞d、CSSOM 構(gòu)建、JS 解析等過程，而這些過程比較耗時，導(dǎo)致用戶會長時間出于不可交互的首屏灰白屏狀態(tài)，從而給用戶一種網(wǎng)頁很“慢”的感覺。那么一個網(wǎng)頁太“慢”，會造成什么影響呢？

Global Web Performance Matters for ecommerce的報告中指出：

57%的用戶更在乎網(wǎng)頁在3秒內(nèi)是否完成加載。

52%的在線用戶認(rèn)為網(wǎng)頁打開速度影響到他們對網(wǎng)站的忠實(shí)度。

每慢1秒造成頁面 PV 降低11%，用戶滿意度也隨之降低降低16%。

近半數(shù)移動用戶因?yàn)樵?0秒內(nèi)仍未打開頁面從而放棄。

我們團(tuán)隊(duì)主要負(fù)責(zé)美團(tuán)支付相關(guān)的業(yè)務(wù)，如果網(wǎng)站太慢會影響用戶的支付體驗(yàn)，會造成客訴或資損。既然網(wǎng)站太“慢”會造成如此重要的影響，那要如何優(yōu)化呢？

在User-centric Performance Metrics一文中，共提到了4個頁面渲染的關(guān)鍵指標(biāo)：

基于這個理論基礎(chǔ)，再回過頭來看看之前項(xiàng)目的實(shí)際表現(xiàn)：

可見在 FP 的灰白屏界面停留了很長時間，用戶不清楚網(wǎng)站是否有在正常加載，用戶體驗(yàn)很差。

試想：如果我們可以將 FCP 或 FMP 完整的 HTML 文檔提前到 FP 時機(jī)預(yù)渲染，用戶看到頁面框架，能感受到頁面正在加載而不是冷冰冰的灰白屏，那么用戶更愿意等待頁面加載完成，從而降低了流失率。并且這種改觀在弱網(wǎng)環(huán)境下更明顯。

通過對比 FP、FCP、FMP 這三個時期 DOM 的差異，發(fā)現(xiàn)區(qū)別在于：

FP：僅有一個 div 根節(jié)點(diǎn)。

FCP：包含頁面的基本框架，但沒有數(shù)據(jù)內(nèi)容。

FMP：包含頁面所有元素及數(shù)據(jù)。

仍然以 Vue 為例， 在其生命周期中，mounted 對應(yīng)的是 FCP，updated 對應(yīng)的是 FMP。那么具體應(yīng)該使用哪個生命周期的 HTML 結(jié)構(gòu)呢？

通過以上的對比，最終選擇在 mounted 時觸發(fā)構(gòu)建時預(yù)渲染。由于我們采用的是 CSR 的架構(gòu)，沒有 Node 作為中間層，因此要實(shí)現(xiàn) DOM 內(nèi)容的預(yù)渲染，就需要在項(xiàng)目構(gòu)建編譯時完成對原始模板的更新替換。

至此，我們明確了構(gòu)建時預(yù)渲染的大體方案。

構(gòu)建時預(yù)渲染流程：

由于 SPA 可以由多個路由構(gòu)成，需要根據(jù)業(yè)務(wù)場景決定哪些路由需要用到預(yù)渲染。因此這里的配置文件主要是用于告知編譯器需要進(jìn)行預(yù)渲染的路由。

在我們的系統(tǒng)架構(gòu)里，腳手架是基于 Webpack 自研的，在此基礎(chǔ)上可以自定義自動化構(gòu)建任務(wù)和配置。

項(xiàng)目中主要是使用 TypeScript，利用 TS 的裝飾器，我們封裝了統(tǒng)一的預(yù)渲染構(gòu)建的鉤子方法，從而只用一行代碼即可完成構(gòu)建時預(yù)渲染的觸發(fā)。

裝飾器：

使用：

從流程圖上，需要在發(fā)布機(jī)上啟動模擬的瀏覽器環(huán)境，并通過預(yù)渲染的事件鉤子獲取當(dāng)前的頁面內(nèi)容，生成最終的 HTML 文件。

由于我們在預(yù)渲染上的嘗試比較早，當(dāng)時還沒有 Headless Chrome 、 Puppeteer、Prerender SPA Plugin等，因此在選型上使用的是 phantomjs-prebuilt（Prerender SPA Plugin 早期版本也是基于 phantomjs-prebuilt 實(shí)現(xiàn)的）。

通過 phantom 提供的 API 可獲得當(dāng)前 HTML，示例如下：

為了提高構(gòu)建效率，并行對配置的多個頁面或路由進(jìn)行預(yù)渲染構(gòu)建，保證在 5S 內(nèi)即可完成構(gòu)建，流程圖如下：

理想很豐滿，現(xiàn)實(shí)很骨感。在實(shí)際投產(chǎn)中，構(gòu)建時預(yù)渲染方案遇到了一個問題。

我們梳理一下簡化后的項(xiàng)目上線過程：

開發(fā) -> 編譯 -> 上線

假設(shè)本次修改了靜態(tài)文件中的一個 JS 文件，這個文件會通過 CDN 方式在 HTML 里引用，那么最終在 HTML 文檔中的引用方式是 。然而由于項(xiàng)目還沒有上線，所以其實(shí)通過完整 URL 的方式是獲取不到這個文件的；而預(yù)渲染的構(gòu)建又是在上線動作之前，所以問題就產(chǎn)生了：

構(gòu)建時預(yù)渲染無法正常獲取文件，導(dǎo)致編譯報錯

怎么辦？

請求劫持

因?yàn)樵谧鲱A(yù)渲染時，我們使用啟動了一個模擬的瀏覽器環(huán)境，根據(jù) phantom 提供的 API，可以對發(fā)出的請求加以劫持，將獲取 CDN 文件的請求劫持到本地，從而在根本上解決了這個問題。示例代碼如下：

最終，構(gòu)建時預(yù)渲染研發(fā)流程如下：

開發(fā)階段：

通過 TypeScript 的裝飾器單行引入預(yù)渲染構(gòu)建觸發(fā)的方法。

發(fā)布前修改編譯構(gòu)建的配置文件。

發(fā)布階段：

先進(jìn)行常規(guī)的項(xiàng)目構(gòu)建。

若有預(yù)渲染相關(guān)配置，則觸發(fā)預(yù)渲染構(gòu)建。

通過預(yù)渲染得到最終的文件，并完成發(fā)布上線動作。

完整的用戶請求路徑如下：

通過構(gòu)建時預(yù)渲染在項(xiàng)目中的使用，F(xiàn)CP 的時間相比之前減少了 75%。

寒陽，美團(tuán)資深研發(fā)工程師，多年前端研發(fā)經(jīng)歷，負(fù)責(zé)美團(tuán)支付錢包團(tuán)隊(duì)和美團(tuán)支付前端基礎(chǔ)技術(shù)。

我們美團(tuán)金融服務(wù)平臺大前端研發(fā)組在高速成長中，我們歡迎更多優(yōu)秀的 Web 前端研發(fā)工程師加入，感興趣的朋友可以將簡歷發(fā)送到郵箱：shanghanyang@meituan.com。