得物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

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