2020年618大促已經過去，作為淘系每年重要的大促活動，淘系前端在其中扮演着什麼樣的角色，如何保證大促的平穩進行？又在其中應用了哪些新技術？淘系前端團隊特此推出「618 系列|淘系前端技術分享」，為大家介紹 618 中的前端身影。
本篇的作者是來自于淘系技術部 前端營銷活動團隊的森郎，為大家介紹今年的618會場是如何做到順滑體驗。
001
《618 大促背後的淘系前端技術體系》002
《生産力再提速，618 互動項目進化之路》前言
作為一名前端工程師，更高的性能、更流暢的體驗是長久不變的追求目标。而作為大促鋒線，會場頁面的性能表現直接影響了億萬消費者的購買體驗。那麼在今年的天貓618，我們是如何讓消費者們在各個會場中能夠逛的知心、挑的稱心、買的開心呢？
本文将簡要介紹今年的618，我們是如何通過緩存優化、請求優化等方案來應對性能挑戰，并如何通過監控測試等手段來保障大規模的會場頁面的性能。
變化與挑戰
今年的618大促，在終端渲染方案上，淘系營銷活動團隊與終端架構團隊深入合作，第一次大規模在會場域落地了PHA（Progressive Hybrid App）方案，并在主會場使用了web方案。這一變化對頁面的資源加載、執行耗時都帶來了挑戰。而在業務玩法上，今年的會場在内容化、本地化等方向發力，短視訊、紅人直播等在H5頁面上同層播放，這對頁面的記憶體占用等提出了一定的要求。
說到挑戰，首先，新使用者、低端機、弱網絡等在大促期間的占比明顯增加，帶來了較大的劣化長尾影響。其次，天貓、淘寶的小二們在618期間建立了大量的會場頁面，如何在大規模的體量下仍然整體保持高性能水位，這對業務配套的檢測監控方案也提出了一定的要求。
方案詳解
在性能優化的落地過程中，我們根據會場頁面的前端時序（如下圖所示），将會場的性能優化拆分為了資源加載、資料請求、子產品渲染等環節。
目前的會場所使用的渲染方案是一套頁面、子產品、資料相分離的異步式方案。在資源請求上，可分為三個部分：一是HTML文檔（不同頁面之間相同），二是包含了rax、loader、render等在内的基礎JS（不同頁面之間相同），三是頁面所使用的各個UI子產品的JS+CSS資源（不同頁面之間不同）。資料請求由頁面的render統一發起，并在資料網關層将目前頁面的不同子產品的商品清單、店鋪資訊等資料在組裝後合并傳回。
結合上述的變化挑戰與實際線上的性能情況，今年618會場的性能保障方案可主要概括為上圖的三個環節。下面将簡要介紹各個環節的政策與實作。
▐ 資源請求優化
✎ 頁面預緩存
在手機淘寶、天貓等app内，我們利用了端側提供的靜态資源緩存方案，将HTML和基礎JS等資源，推送下發至用戶端。在用戶端的webview請求資源時，端側可根據域名來比對已下發的緩存包，在比對成功後直接從本地緩存中讀取對應的HTML和JS資源，而無需每次都請求網絡、大大縮短了頁面的初始化時間。例如，主會場的html加載耗時在推送緩存後可平均減少70+%、命中率可達到97%。
✎ 子產品資源緩存
子產品的JS+CSS資源，因為不同頁面所使用的子產品不同（例如男裝會場和家裝會場），并且總計有上百個子產品，無法做到全量的提前緩存。這裡我們通過撈取top流量頁面的方式，僅将首屏相關的核心子產品做了子產品緩存下發，較好的緩解了子產品請求的耗時。
✎ 子產品按需加載
除了剛提到的子產品緩存下發，今年的618會場還通過“子產品按需加載”的優化方式，最小化的控制了目前頁面的子產品數量，這對首屏的JS資源請求、資料請求都有一定的縮減。在實作方案上，通過在資料網關層先讀取服務端所緩存的定向投放條件，判斷目前通路的URL參數、用戶端資訊等是否滿足子產品的展示條件（例如，搜尋框子產品僅在手淘内才展示）。不滿足條件時，則直接從頁面中移除這一子產品。例如，在外部浏覽器裡打開618超酷數位會場時，頁面所加載的JS資源大小可是以減少40+%。
▐ 資料請求優化
為了給消費者們推薦最貼心的好物，現在的大促會場使用的更多是千人千面、個性化的算法推薦資料。但推薦所帶來的算法耗時增加，使得資料請求成為了目前會場性能的耗時最長闆。如果能夠降低目前會場的資料請求耗時，那麼首屏時間也會随之明顯減少。
是以在今年的618會場中，我們落地了一套基于線上實時埋點的請求優化方案，通過更精簡的首屏子產品數量來實作了對首屏接口耗時的直接優化。
在方案中，通過采樣上報的方式擷取到了子產品高度，并結合裝置資訊、頁面子產品排序、個性化資料等條件，個性化的控制了每次通路的首屏子產品加載數量。例如，小明在通路數位會場時隻需要加載5個子產品，而小強隻需要加載4個子產品。以線上RT情況為例，針對于單個會場，方案可使得首屏耗時平均減少100+ms。
▐ 監控檢測
這次的618使用了兩套檢測機制來保障會場性能。第一套是子產品級檢測，通過與H5自動化測試平台等打通，批量化的對所有大促子產品進行了性能檢測，從中發現了例如部分子產品的引用圖檔未壓縮、資源域名未收斂等問題。
第二套則是頁面級檢測，在小二們完成了會場頁面的配置填寫後，批量化的對所有的618會場進行了自動檢測，使得一些頁面加載、資料請求、子產品渲染等相關性能問題，可在上線前得以被發現和修複。
而性能監控上，與雙11整體保持一緻，今年618使用了一套接近于FMP的性能名額，以自定義采集上報的方式、關聯前端監控平台，實作了分鐘級的性能看闆，幫助我們更快的發現線上性能問題、并作出針對性的調整。
▐ 降級政策
同層播放元件的引入對會場頁面的記憶體占用提出了較高的要求，尤其是低端機、老系統等。針對這個問題，今年的618會場域統一接入了用戶端所提供的降級平台，可直接根據機型、系統版本、用戶端版本等條件動态的執行降級政策。例如，可設定在手淘版本≤9.5.0 + iOS版本≤10時不播放商品短視訊等等。
今年的618會場，線上整體穩定性良好，未出現因會場記憶體占用過高而導緻的用戶端crash飙高情況。
整體回顧
性能優化，功在平時，成在大促。在今年的618大促中，通過上述的優化方案和保障手段，最終達成了預期的體驗目标。
但在過程中，也發現了一些可繼續深挖的性能優化點。例如，可以結合端智能等用戶端的能力幫助大促主會場提前完成頁面資料、依賴資源的預加載，甚至是頁面的預渲染。我們會在後面的一場場大促中持續疊代優化，為消費者們提供沒有最好、隻有更好的購物體驗。
總結
618，這一場持續了20多天的年中促銷活動，對于億萬消費者們來說是一場狂歡盛宴，而對于在背後默默支撐這一場大促的所有工程師們，則更像是一場極客馬拉松，痛并快樂着。
淘系前端團隊
618雖然已經結束，但更大規模的雙11全球狂歡節馬上就要啟動。高複雜度、大規模的營銷活動業務場景持續推動着淘系前端技術體系朝着極緻方向疊代演進，期待更多的同學加入阿裡淘系前端團隊，一起來創造618、雙11的新曆史，此時此刻，非你莫屬！
履歷投遞📮：[email protected]
關注「淘系技術」微信公衆号，一個有溫度有内容的技術社群~