出處:https://mp.weixin.qq.com/s?__biz=MzIzOTU0NTQ0MA==&mid=2247501388&idx=1&sn=3050b1d6a8f84642fd4af5e1f79731eb

導讀：雙11如絲般順滑的服務體驗背後，是技術團隊對效能最佳化不斷地探索嘗試、升級迭代。今年飛豬會場實現了主會場直出、重點會場秒開、整體會場體感優秀。飛豬前端技術太吾分享飛豬在前端效能最佳化上面臨的挑戰及最佳化方向，詳解在端側預渲染、SSR、SnapShot、SPA、資源和資料預快取及監控和診斷上的最佳化細節。

沒有最快，只有更快！在前端開發領域，效能是一個永恆的話題。它不僅僅代表著使用者體驗，更直接影響業務效果，業界就流傳著一個共識：頁面載入時長每增加1秒，使用者就流失10%。

與去年雙11相比，今年飛豬會場的最大區別是從Rax0.6 on Weex到Rax1.0 on Web。因為在上半年，基於開發成本、可維護性等一系列的考慮，我們將前端渲染引擎迴歸到WebView，頁面開啟在強網路環境和資源離線這兩種情況下，雖然載入體感幾乎一致，但Web首屏效能資料還有提升空間。且在Web端通用手段已用盡，需要重新探索最佳化方向。但專案組最終透過多職能協同，完成主會場直出、重點會場秒開、整體會場體感優秀。

今年雙11前端的目標之一就是，在效能方面，體感要超過Weex，資料也要超過Weex。

一 面臨的挑戰

為Follow阿里集團的主推方案，使用Rax1.0統一DSL，一碼多端支援H5、小程式和未來的Flutter，飛豬從618大促開始，就將會場渲染側全量切換到 Rax 1.0 Web 渲染，當時對於效能方面的優先順序不是那麼高。之後，效能最佳化專項重啟，開始著手進行Web方面的最佳化研究，力爭提升雙11的使用者體驗。

飛豬的會場模組複雜，包括影片、動畫、多Tab、長列表；介面RT高，且服務端已無最佳化空間；旅行行業特點，頁面依賴定位資訊、使用者資訊，拖慢首屏時間。所以如何保證會場可以更快地呈現給使用者是個嚴峻的考驗。

與此同時，雙11專案組對效能方面提出一個近乎苛刻的目標：比日常會場效能提高25%。在前端最佳化手段日趨穩定的情況下，還要進行幾百毫秒的最佳化，只能進入深水區。

二 最佳化方向

面對這個目標，傳統意義的前端方面最佳化已經不足以支撐，於是我們聯合客戶端、服務端以及其他BU同學，進行了一場協同戰役。我們主要面向三個方向進行最佳化：

一是，與客戶端團隊合作，進行預渲染、離線包、Data-Prefetch等手段的落地和最佳化。二是，順應Serverless大潮，重啟營銷域SSR方案，將原本端側的壓力轉移到服務端上去完成。三是，在兼顧資料的同時，兼顧使用者的體感，做了兩種Snapshot的方案（介面快取、HTML快取）以及SPA方案。

下圖展示了所有會場所使用的最佳化手段：

所有會場所使用的最佳化手段

主會場：為了保證主會場的最佳體驗，使用客戶端提供的終極大招——預渲染。主要會場：對於首屏沒有非同步模組的場景，使用SSR配合Data-Prefetch，提升使用者可見頁面時間。全部會場：因為模組基本沒有變化，全部會場使用HTML快取型別的Snapshot方案，使用者可以更快瀏覽該頁面。底部重要會場：採用介面快取型別的Snapshot方案，提升使用者瀏覽體驗。所有會場均透過統一渲染頁推送離線包和Data-Prefetch。為保證分會場分別運營和頁面之間切換的流暢性，底部Tab五頁面之間使用類SPA方案，使頁面切換起來無縫銜接。

整體最佳化思路分析從整個渲染流程分析觸發，針對每個節點進行細緻的分析最佳化：

1 技術實施詳解：端側預渲染

如果不考慮可能帶來的Crash風險，這應該是提升最大的方案了。

在雙11大促的場景下，透過端控制開關，將下發的配置URL以“離屏”的方式初始化好容器並loadUrl，在上屏之前完成頁面的Rasterization（柵格化）。當用戶點選頁面入口時，客戶端會直接將“準備好的Webview”推到前臺展示，頁面FCP從1~2s直接降到100ms以下，形成幾乎無感的開啟效果。

效果對比

開啟預渲染（左）未開啟預渲染（右）

方案流程圖

在客戶端透過配置下發的方式初始化WebView，並透過記憶體管控保證APP的穩定性，同時在展示邏輯上和前端配合，保證資料的一致性，最終透過釋放後續的一系列處理管理多次訪問的情況。

2 技術實施詳解：SSR（Server-side render or Serverless-side render）

披荊斬棘的戰士，帶著榮光歸來。

SSR中文名：服務端渲染，是將渲染的工作放在服務端進行，在 Ajax出現之前全部是這種方式，由服務端返回給瀏覽器完整的 HTML 內容。在傳統BFF架構時期，這種方式逐漸消失。但藉著Serverless大潮，當Faas遇上SSR，又迸發出新的火花。

今年3月，狼叔在《前端新思路：元件即函式和Serverless SSR實踐》中，將SSR的概念升級，從傳統意義上的Server-side render 升級為 Serverless side render，基於FaaS環境，提供端側頁面渲染能力。

專案組透過兩個月的調研和開發除錯，在國慶大促一個會場預演，在雙11的五個重點會場使用SSR，使機票會場效能提升50%，首屏可見時間減少1000ms+。

效果描述

SSR代表首屏即可視，相比CSR減少模組載入以及頁面渲染，將可視時間大幅提前。

方案流程圖

整體方案保證效能優勢以及改造成本小的前提，採取非同步SSR方案，即將HTML放在介面中返回，在規避高低端機容器影響的同時，又可同時複用客戶端的離線以及資料預載入能力，還保證CSR到SSR的平滑切換。

3 技術實施詳解：SnapShot（頁面快照）

將使用者體感頁面可見時間繼續提前。

最初設計SnapShot是在非千人千面的場景下，多次訪問，更快的可見頁面。原理是將上一次訪問的 HTML 直接快取在本地，使用者下一次進入頁面時，首先展示快取的頁面。但後來發現，在雙11會場這種幾乎每天都會變陣的場景下，模組的刪減以及順序的調整，都會使得從“快取頁面”到“真實頁面”的過程中發生不可避免的閃動，而這種閃動是難以接受的。於是我們重新設計出介面快取的方式，配合模組快取，實現與之前效果相同，但避免閃動的方案。

同時，我們發現 HTML 快取的方式也並非毫無用武之地。雙11會場上線前，針對所有會場進行 Review 最佳化手段，發現在全部會場場景下，會場基本無變化，使用HTML快取的方式簡直再合適不過，於是我們將使用Snapshot 的頁面分為兩類，達到所有頁面都快且完美地呈現給使用者。

效果描述

開啟Snapshot後，整體頁面無Loading，基本達到頁面的直出效果。

4 技術實施詳解：SPA

完成使用者體感的“最後一公里”，多頁面間跳轉實現無感知。

各分會場需要進行分別運營，透過底部Tab包框將多頁面聚合，展示成一個頁面，透過點選Tab進行切換，但頁面之間的跳轉造成的割裂體感一直被詬病。本次升級完成了類SPA的方案，將Tab中的頁面資料請求後，直接渲染成真實的Dom，切換透過Display的方式，基本在高階機上實現了將多頁面聚合成單頁面，多頁面間跳轉無感知，給予使用者最好的體驗。

效果描述

方案流程圖

搭建頁面框架共用一套渲染引擎，且每個頁面的所有模組透過Fetch獲取，每個模組獨立釋出，且支援模組拆combo後單獨快取，非常適合SPA方案。同時專案組針對高低端機做了不同處理，在高階機上請求單Tab資料完成後，預載入其他幾個Tab資料，切換時直接取用，提供更好的體驗。

5 技術實施詳解：資源&資料預快取

最快的請求是不發請求。

利用飛豬端側的Fcache/DataPrefetch機制，結合總控配置下發通道，將頁面內的靜態資源主動下發到客戶端進行快取，使使用者訪問頁面時無需請求靜態資源。此外，在頁面發起跳轉時，在端側提前觸發頁面的資料請求，減少介面請求等待時間。

Fcache方案 (資源快取)

會場的離線方案採用url+package的方式，在配置後臺錄入url後，後臺透過puppeteer去跑這個URL，把請求的資源快取下來，其中還包括一些滾屏操作，把懶載入的資源也抓下來，最後透過透過讀配置去匹配資源快取。

DataPrefetch方案 (資料預載入)

資料預載入擁有三個狀態：Memory、Ongoing、Miss。我們認為將請求放在客戶端發出一定會減少真實的請求時間，所以即使真實請求發出時，客戶端還未完成請求，只要key匹配，會等待客戶端資料，而不是重新進行一次請求傳送。

6 技術實施詳解：監控&診斷

最佳化手段之餘，也需要對會場頁面的效能趨勢進行持續監控，對於異常Case進行排查。為此，我們開發了實時的效能穩定性實時大盤、雙11會場小時級效能大盤平臺、耗時異常長的慢會話跟蹤小工具。

效能穩定性實時大盤

三 成果

飛豬端內雙11所有會場首屏可見時間達成既定目標，較日常會場首屏耗時環比降低 25%，較618以及國慶會場首屏耗時環比降低 20%。

雙11分組整體效能耗時趨勢圖

命中SSR的情況下首屏可見時間更是被拉入1s內，開啟SSR的會場在使用 Web後也可以重提秒開率，在業務頻繁變陣影響首屏模組的基礎上，達到周整體秒開率 60%以上，機票會場秒開率75% 以上。

四 技術規劃

本次技術上有著很多新嘗試和迭代升級，在經過雙11的磨練之後，需要朝著更加易用和通用的方向發展，主要分為以下幾個部分：

1 SSR方案最佳化

SSR在端內提供了巨大提升，首先需要完善同步方案，實現端外場景的提升。其次，在現有基礎上增加AbTest，來支援更有說服力的業務效果對比；最後最佳化SSR在服務端的執行速度以及彈性擴容能力。

2 客戶端最佳化

接下來會嘗試多Webview的Tab切換，接入PHA方案。並將更多的喚端情況列入最佳化方向，如冷啟動場景的專項最佳化。

3 配套設施

最佳化的背後離不開配套設施的支援，在現有基礎上支援卡口、巡檢、監控等功能，實現效能問題及時治理。

五 總結

作為一位前端開發工程師，擔任雙11會場效能PM，特別是對於今年從Weex到Web，效能水位重新被拉高，是挑戰也是機會。

在保障業務不受影響的前提下，確保使用者開啟會場可以得到更快體驗。從頁面各階段的耗時分析，到藉助兄弟團隊能力，最終支撐雙11會場圓滿結束。

最佳化思路從整個渲染流程出發，秉承著快取優先、壓力轉移、階段並行、端側深挖、體感最佳化五項原則，對各節點應用不同手段達成最終結果。

在整個過程中，透過應用大量的最佳化手段和創新方案，提高使用者的秒開率來側面幫助業務轉化提升；將預渲染、SSR逐漸落入更多場景，為之後的全面性能提升做鋪墊；聯合客戶端、服務端，打破前端能力和邊界，進而探索效能深水區；提升效能資料提升的同時，兼顧效能資料監控，實時把控異常情況。

這種種最佳化手段肯定還不夠，之後首先會從單業務場景推廣到多業務場景，從單容器到多容器相容，各業務、容器間進行方案的落地與反哺，最終期望可以完成全端效能標準統一。

最後，為明年雙11立個Flag：明年不再需要效能保障，而是在頁面生產出來的時候，就是滿足效能標準的！

出處:https://mp.weixin.qq.com/s?__biz=MzIzOTU0NTQ0MA==&mid=2247501388&idx=1&sn=3050b1d6a8f84642fd4af5e1f79731eb