美團(tuán)支付前端團(tuán)隊(duì)支持著美團(tuán)錢包及支付業(yè)務(wù)，涉及項(xiàng)目眾多，并且項(xiàng)目迭代很快，挑戰(zhàn)巨大。在總結(jié)經(jīng)驗(yàn)之后，我們舉辦了第40期美團(tuán)技術(shù)沙龍，與大家分享我們的實(shí)戰(zhàn)經(jīng)驗(yàn)。
（圖片來自寒陽(yáng)分享現(xiàn)場(chǎng)）
自JavaScript誕生以來，前端技術(shù)發(fā)展非常迅速。移動(dòng)端白屏優(yōu)化是前端界面體驗(yàn)的一個(gè)重要優(yōu)化方向，Web 前端誕生了 SSR 、CSR、預(yù)渲染等技術(shù)。在美團(tuán)支付的前端技術(shù)體系里，通過預(yù)渲染提升網(wǎng)頁(yè)首幀優(yōu)化，從而優(yōu)化了白屏問題，提升用戶體驗(yàn)，并形成了最佳實(shí)踐。
在前端渲染領(lǐng)域，主要有以下幾種方式可供選擇：
通過對(duì)比，同構(gòu)方案集合 CSR 與 SSR 的優(yōu)點(diǎn)，可以適用于大部分業(yè)務(wù)場(chǎng)景。但由于在同構(gòu)的系統(tǒng)架構(gòu)中，連接前后端的 Node 中間層處于核心鏈路，系統(tǒng)可用性的瓶頸就依賴于 Node ，一旦作為短板的 Node 掛了，整個(gè)服務(wù)都不可用。
結(jié)合到我們團(tuán)隊(duì)負(fù)責(zé)的支付業(yè)務(wù)場(chǎng)景里，由于支付業(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)了一個(gè)體驗(yàn)問題：首屏白屏問題。
瀏覽器渲染包含 HTML 解析、DOM 樹構(gòu)建、CSSOM 構(gòu)建、JavaScript 解析、布局、繪制等等，大致如下圖所示：
要搞清楚為什么會(huì)有白屏，就需要利用這個(gè)理論基礎(chǔ)來對(duì)實(shí)際項(xiàng)目進(jìn)行具體分析。通過 DevTools 進(jìn)行分析：
等待 HTML 文檔返回，此時(shí)處于白屏狀態(tài)。
對(duì) HTML 文檔解析完成后進(jìn)行首屏渲染，因?yàn)轫?xiàng)目中對(duì)加了灰色的背景色，因此呈現(xiàn)出灰屏。
進(jìn)行文件加載、JS 解析等過程，導(dǎo)致界面長(zhǎng)時(shí)間出于灰屏中。
當(dāng) Vue 實(shí)例觸發(fā)了 mounted 后，界面顯示出大體框架。
調(diào)用 API 獲取到時(shí)機(jī)業(yè)務(wù)數(shù)據(jù)后才能展示出最終的頁(yè)面內(nèi)容。
由此得出結(jié)論，因?yàn)橐却募虞d、CSSOM 構(gòu)建、JS 解析等過程，而這些過程比較耗時(shí)，導(dǎo)致用戶會(huì)長(zhǎng)時(shí)間出于不可交互的首屏灰白屏狀態(tài)，從而給用戶一種網(wǎng)頁(yè)很“慢”的感覺。那么一個(gè)網(wǎng)頁(yè)太“慢”，會(huì)造成什么影響呢？
Global Web Performance Matters for ecommerce的報(bào)告中指出：
57%的用戶更在乎網(wǎng)頁(yè)在3秒內(nèi)是否完成加載。
52%的在線用戶認(rèn)為網(wǎng)頁(yè)打開速度影響到他們對(duì)網(wǎng)站的忠實(shí)度。
每慢1秒造成頁(yè)面 PV 降低11%，用戶滿意度也隨之降低降低16%。
近半數(shù)移動(dòng)用戶因?yàn)樵?0秒內(nèi)仍未打開頁(yè)面從而放棄。
我們團(tuán)隊(duì)主要負(fù)責(zé)美團(tuán)支付相關(guān)的業(yè)務(wù)，如果網(wǎng)站太慢會(huì)影響用戶的支付體驗(yàn)，會(huì)造成客訴或資損。既然網(wǎng)站太“慢”會(huì)造成如此重要的影響，那要如何優(yōu)化呢？
在User-centric Performance Metrics一文中，共提到了4個(gè)頁(yè)面渲染的關(guān)鍵指標(biāo)：
基于這個(gè)理論基礎(chǔ)，再回過頭來看看之前項(xiàng)目的實(shí)際表現(xiàn)：
可見在 FP 的灰白屏界面停留了很長(zhǎng)時(shí)間，用戶不清楚網(wǎng)站是否有在正常加載，用戶體驗(yàn)很差。
試想：如果我們可以將 FCP 或 FMP 完整的 HTML 文檔提前到 FP 時(shí)機(jī)預(yù)渲染，用戶看到頁(yè)面框架，能感受到頁(yè)面正在加載而不是冷冰冰的灰白屏，那么用戶更愿意等待頁(yè)面加載完成，從而降低了流失率。并且這種改觀在弱網(wǎng)環(huán)境下更明顯。
通過對(duì)比 FP、FCP、FMP 這三個(gè)時(shí)期 DOM 的差異，發(fā)現(xiàn)區(qū)別在于：
FP：僅有一個(gè) div 根節(jié)點(diǎn)。
FCP：包含頁(yè)面的基本框架，但沒有數(shù)據(jù)內(nèi)容。
FMP：包含頁(yè)面所有元素及數(shù)據(jù)。
仍然以 Vue 為例， 在其生命周期中，mounted 對(duì)應(yīng)的是 FCP，updated 對(duì)應(yīng)的是 FMP。那么具體應(yīng)該使用哪個(gè)生命周期的 HTML 結(jié)構(gòu)呢？
通過以上的對(duì)比，最終選擇在 mounted 時(shí)觸發(fā)構(gòu)建時(shí)預(yù)渲染。由于我們采用的是 CSR 的架構(gòu)，沒有 Node 作為中間層，因此要實(shí)現(xiàn) DOM 內(nèi)容的預(yù)渲染，就需要在項(xiàng)目構(gòu)建編譯時(shí)完成對(duì)原始模板的更新替換。
至此，我們明確了構(gòu)建時(shí)預(yù)渲染的大體方案。
構(gòu)建時(shí)預(yù)渲染流程：
由于 SPA 可以由多個(gè)路由構(gòu)成，需要根據(jù)業(yè)務(wù)場(chǎng)景決定哪些路由需要用到預(yù)渲染。因此這里的配置文件主要是用于告知編譯器需要進(jìn)行預(yù)渲染的路由。
在我們的系統(tǒng)架構(gòu)里，腳手架是基于 Webpack 自研的，在此基礎(chǔ)上可以自定義自動(dòng)化構(gòu)建任務(wù)和配置。
項(xiàng)目中主要是使用 TypeScript，利用 TS 的裝飾器，我們封裝了統(tǒng)一的預(yù)渲染構(gòu)建的鉤子方法，從而只用一行代碼即可完成構(gòu)建時(shí)預(yù)渲染的觸發(fā)。
裝飾器：
使用：
構(gòu)建編譯
從流程圖上，需要在發(fā)布機(jī)上啟動(dòng)模擬的瀏覽器環(huán)境，并通過預(yù)渲染的事件鉤子獲取當(dāng)前的頁(yè)面內(nèi)容，生成最終的 HTML 文件。
由于我們?cè)陬A(yù)渲染上的嘗試比較早，當(dāng)時(shí)還沒有 Headless Chrome 、 Puppeteer、Prerender SPA Plugin等，因此在選型上使用的是 phantomjs-prebuilt（Prerender SPA Plugin 早期版本也是基于 phantomjs-prebuilt 實(shí)現(xiàn)的）。
通過 phantom 提供的 API 可獲得當(dāng)前 HTML，示例如下：
為了提高構(gòu)建效率，并行對(duì)配置的多個(gè)頁(yè)面或路由進(jìn)行預(yù)渲染構(gòu)建，保證在 5S 內(nèi)即可完成構(gòu)建，流程圖如下：
理想很豐滿，現(xiàn)實(shí)很骨感。在實(shí)際投產(chǎn)中，構(gòu)建時(shí)預(yù)渲染方案遇到了一個(gè)問題。
我們梳理一下簡(jiǎn)化后的項(xiàng)目上線過程：
開發(fā) -> 編譯 -> 上線
假設(shè)本次修改了靜態(tài)文件中的一個(gè) JS 文件，這個(gè)文件會(huì)通過 CDN 方式在 HTML 里引用，那么最終在 HTML 文檔中的引用方式是 。然而由于項(xiàng)目還沒有上線，所以其實(shí)通過完整 URL 的方式是獲取不到這個(gè)文件的；而預(yù)渲染的構(gòu)建又是在上線動(dòng)作之前，所以問題就產(chǎn)生了：
構(gòu)建時(shí)預(yù)渲染無法正常獲取文件，導(dǎo)致編譯報(bào)錯(cuò)
怎么辦？
請(qǐng)求劫持
因?yàn)樵谧鲱A(yù)渲染時(shí)，我們使用啟動(dòng)了一個(gè)模擬的瀏覽器環(huán)境，根據(jù) phantom 提供的 API，可以對(duì)發(fā)出的請(qǐng)求加以劫持，將獲取 CDN 文件的請(qǐng)求劫持到本地，從而在根本上解決了這個(gè)問題。示例代碼如下：
最終，構(gòu)建時(shí)預(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ā)布上線動(dòng)作。
完整的用戶請(qǐng)求路徑如下：
通過構(gòu)建時(shí)預(yù)渲染在項(xiàng)目中的使用，F(xiàn)CP 的時(shí)間相比之前減少了 75%。
寒陽(yáng)，美團(tuán)資深研發(fā)工程師，多年前端研發(fā)經(jīng)歷，負(fù)責(zé)美團(tuán)支付錢包團(tuán)隊(duì)和美團(tuán)支付前端基礎(chǔ)技術(shù)。
原文鏈接：https://mp.weixin.qq.com/s/20yJV3D8SeI-cM0PCqTDAQ
重慶分公司
重慶分公司
