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