得物技術在搭建會場下的頁面性能優化

得物App內h5的項目都是經過webview打開。對於webview的性能你們廣泛的印象就是打開速度比native慢。

對於SPA應用，一個用戶打開webveiw訪問h5須要通過以下過程：

1. 點擊App入口（例如banner等）
2. 到達新頁面，頁面白屏。
3. 頁面基本框架出現（骨架屏），可是沒有數據，頁面處於loading狀態。
4. 出現全部數據，頁面徹底呈現。

從程序執行的角度，咱們來看一個沒有優化過的webview加載h5的過程：

壓縮每個階段的時間，是性能優化的關鍵點。

WEBVIEW

結合App的webview咱們採用了兩個優化手段：

• 靜態資源內置：js，css等靜態資源內置在App。App經過攔截請求直接返回本地文件，固然涉及到一系列的刷新緩存的策略。離線文件命中率當下在40%多。
  

• html預加載：App冷啓動會主動拉取關鍵入口的html作緩存。

以下圖秒開率有15%的提升。

H5優化

SPA與SSR

SPA會場下頁面渲染整個流程：

SSR會場下頁面渲染整個流程：

SPA與SSR在FMP上的表現，中間的凹槽是線上切到SPA的狀況，可見SSR對於秒開有平均15%的提高。

加載時序優化

分析頁面的html，咱們發現一些js腳本 block了html的加載。

減小三個block的script的加載。

資源體積

圖片優化

webp

webp可以達到90%壓縮率，其重要性不言而喻。

現有方案在ssr直出的組件沒有webp的能力。即便端上支持webp也加載了jpg或者png的圖片，致使資源太大。而在ios的14版本後ios有了支持webp的能力，諮詢了IOS同窗，14版本的佔比至少百分之七八十。

方案

node端直出全部圖片都爲webp。在端上作一次webp的check，不支持則降級到原jpg或者png。

效果

不支持webp的手機：注意頭圖。

無損壓縮服務

從圖片源頭上解決圖片過大的問題，使用了開源方案imagemin/imagemin。
會場傳圖統一收口交互，避免同一張圖屢次上傳的狀況。平均壓縮率60%。

包體積

• 無用自定義組件的刪除 -33k
• 按需lodash的大小 -24K
• 神策SDK 經過JS建立script加載。且解決神策sdk的命名空間前置訪問。76 k
• koa-router的依賴。 -21 k

• 組件按需加載。
  

  總資源優化數據

  上線後第一天優化數據

  Lighthouse 打分維度分析結論

  Lighthouse 綜合打分

  優化前

第一期優化後

結論：Lighthouse 相應提高了 20%+。

瀏覽器資源維度數據分析結論

優化前數據：

第一期優化後：

結論：transferred 提高了 20%。

綜合分析結論

第一期優化根據各類數據彙總，性能總體提高 10%。

SSR組件體驗專項優化

現狀

有些組件在node端沒有直出，且沒有圖片懶加載的能力。

方案

node端直出組件，且屏外的圖片使用懶加載的功能。

效果

涉及以一鍵領券，分會場入口等組件
前：

後：

FMP總效果

通過一系列的努力，App端優化與h5端的優化。咱們把頁面的秒開率提升到了40%左右。

文｜問問en

關注得物技術，攜手走向技術的雲端