從Weex到Web，性能逆勢如何破局？

簡介：雙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的方式，基本在高端機上實作了將多頁面聚合成單頁面，多頁面間跳轉無感知，給予用戶最好的體驗，

效果描述

從多頁面之前的replace操作，頁面跳轉中出現白屏，到目前頁面中DOM的替換，用戶體感大幅提升，也取消了用戶點擊Tab卻跳頁面割裂的感覺，

方案流程圖

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

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

最快的請求是不發請求，

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

Fcache方案 (資源快取)

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://developer.aliyun.com/article/780011?

著作權宣告：本文內容由阿里云實名注冊用戶自發貢獻，著作權歸原作者所有，阿里云開發者社區不擁有其著作權，亦不承擔相應法律責任，具體規則請查看《阿里云開發者社區用戶服務協議》和《阿里云開發者社區知識產權保護指引》，如果您發現本社區中有涉嫌抄襲的內容，填寫侵權投訴表單進行舉報，一經查實，本社區將立刻洗掉涉嫌侵權內容，