簡介： 雙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?
版權聲明： 本文内容由阿裡雲實名注冊使用者自發貢獻，版權歸原作者所有，阿裡雲開發者社群不擁有其著作權，亦不承擔相應法律責任。具體規則請檢視《阿裡雲開發者社群使用者服務協定》和《阿裡雲開發者社群知識産權保護指引》。如果您發現本社群中有涉嫌抄襲的内容，填寫侵權投訴表單進行舉報，一經查實，本社群将立刻删除涉嫌侵權内容。