怎樣讓H5頁麵啟動更快？H5首屏秒開方案探討

 越來越多的APP內業務使用H5的方式實現，怎樣讓H5頁麵啟動更快是很多人在探索的技術點，本文梳理了啟動過程中的各個點，分別從前端和客戶端角度去探討有哪些優化方案，供大家參考。

隨著移動設備性能不斷增強，web 頁麵的性能體驗逐漸變得可以接受，又因為 web 開發模式的諸多好處(跨平台，動態更新，減體積，無限擴展)，APP 客戶端裏出現越來越多內嵌 web 頁麵（為了配上當前流行的說法，以下把所有網頁都稱為 H5 頁麵，雖然可能跟 H5 沒關係），很多 APP 把一些功能模塊改成用 H5 實現。

雖然說 H5 頁麵性能變好了，但如果沒針對性地做一些優化，體驗還是很糟糕的，主要兩部分體驗：

1.頁麵啟動白屏時間：打開一個 H5 頁麵需要做一係列處理，會有一段白屏時間，體驗糟糕。

2.響應流暢度：由於 webkit 的渲染機製，單線程，曆史包袱等原因，頁麵刷新/交互的性能體驗不如原生。

本文先不討論第二點，隻討論第一點，怎樣減少白屏時間。對 APP 裏的一些使用 H5 實現的功能模塊，怎樣加快它們的啟動速度，讓它們啟動的體驗接近原生。

過程

為什麼打開一個 H5 頁麵會有一長段白屏時間？因為它做了很多事情，大概是：

初始化 webview -> 請求頁麵 -> 下載數據 -> 解析HTML -> 請求 js/css 資源 -> dom 渲染 -> 解析 JS 執行 -> JS 請求數據 -> 解析渲染 -> 下載渲染圖片

一些簡單的頁麵可能沒有 JS 請求數據 這一步，但大部分功能模塊應該是有的，根據當前用戶信息，JS 向後台請求相關數據再渲染，是常規開發方式。

一般頁麵在 dom 渲染後能顯示雛形，在這之前用戶看到的都是白屏，等到下載渲染圖片後整個頁麵才完整顯示，首屏秒開優化就是要減少這個過程的耗時。

前端優化

上述打開一個頁麵的過程有很多優化點，包括前端和客戶端，常規的前端和後端的性能優化在 PC 時代已經有最佳實踐，主要的是：

1.降低請求量：合並資源，減少 HTTP 請求數，minify / gzip 壓縮，webP，lazyLoad。

2.加快請求速度：預解析DNS，減少域名數，並行加載，CDN 分發。

3.緩存：HTTP 協議緩存請求，離線緩存 manifest，離線數據緩存localStorage。

4.渲染：JS/CSS優化，加載順序，服務端渲染，pipeline。

其中對首屏啟動速度影響最大的就是網絡請求，所以優化的重點就是緩存，這裏著重說一下前端對請求的緩存策略。我們再細分一下，分成 HTML 的緩存，JS/CSS/image 資源的緩存，以及 json 數據的緩存。

HTML 和 JS/CSS/image 資源都屬於靜態文件，HTTP 本身提供了緩存協議，瀏覽器實現了這些協議，可以做到靜態文件的緩存。

總的來說，就是兩種緩存：

1.詢問是否有更新：根據 If-Modified-Since / ETag 等協議向後端請求詢問是否有更新，沒有更新返回304，瀏覽器使用本地緩存。

2.直接使用本地緩存：根據協議裏的 Cache-Control / Expires 字段去確定多長時間內可以不去發請求詢問更新，直接使用本地緩存。

前端能做的最大限度的緩存策略是：HTML 文件每次都向服務器詢問是否有更新，JS/CSS/Image資源文件則不請求更新，直接使用本地緩存。那 JS/CSS 資源文件如何更新？常見做法是在在構建過程中給每個資源文件一個版本號或hash值，若資源文件有更新，版本號和 hash 值變化，這個資源請求的 URL 就變化了，同時對應的 HTML 頁麵更新，變成請求新的資源URL，資源也就更新了。

json 數據的緩存可以用 localStorage 緩存請求下來的數據，可以在首次顯示時先用本地數據，再請求更新，這都由前端 JS 控製。

這些緩存策略可以實現 JS/CSS 等資源文件以及用戶數據的緩存的全緩存，可以做到每次都直接使用本地緩存數據，不用等待網絡請求。但 HTML 文件的緩存做不到，對於 HTML 文件，如果把 Expires / max-age 時間設長了，長時間隻使用本地緩存，那更新就不及時，如果設短了，每次打開頁麵都要發網絡請求詢問是否有更新，再確定是否使用本地資源，一般前端在這裏的策略是每次都請求，這在弱網情況下用戶感受到的白屏時間仍然會很長。所以 HTML 文件的“緩存”和跟“更新”間存在矛盾。

客戶端優化

接著輪到客戶端出場了，桌麵時代受限於瀏覽器，H5 頁麵無法做更多的優化，現在 H5 頁麵是內嵌在客戶端 APP 上，客戶端有更多的權限，於是客戶端上可以超出瀏覽器的範圍，做更多的優化。

HTML 緩存

先接著緩存說，在客戶端有更自由的緩存策略，客戶端可以攔截 H5 頁麵的所有請求，由自己管理緩存，針對上述 HTML 文件的“緩存”和“更新”之間的矛盾，我們可以用這樣的策略解決：

1.在客戶端攔截請求，首次請求 HTML 文件後緩存數據，第二次不發請求，直接使用緩存數據。

2.什麼時候去請求更新？這個更新請求可以客戶端自由控製策略，可以在使用本地緩存打開本地頁麵後再在後台發起請求詢問更新緩存，下次打開時生效；也可以在 APP 啟動時或某個時機在後台去發起請求預更新，提升用戶訪問最新代碼的幾率。

這樣看起來已經比較完美了，HTML 文件在用客戶端的策略緩存，其餘資源和數據沿用上述前端的緩存方式，這樣一個 H5 頁麵第二次訪問從 HTML 到 JS/CSS/Image 資源，再到數據，都可以直接從本地讀取，無需等待網絡請求，同時又能保持盡可能的實時更新，解決了緩存問題，大大提升 H5 頁麵首屏啟動速度。

問題

上述方案似乎已完整解決緩存問題，但實際上還有很多問題：

1.沒有預加載：第一次打開的體驗很差，所有數據都要從網絡請求。

2.緩存不可控：緩存的存取由係統 webview 控製，無法控製它的緩存邏輯，帶來的問題包括：

清理邏輯不可控，緩存空間有限，可能緩存幾張大圖片後，重要的 HTML/JS/CSS 緩存就被清除了。

磁盤 IO 無法控製，無法從磁盤預加載數據到內存。

更新體驗差：後台 HTML/JS/CSS 更新時全量下載，數據量大，弱網下載耗時長。

無法防劫持：若 HTML 頁麵被運營商或其他第三方劫持，將長時間緩存劫持的頁麵。

這些問題在客戶端上都是可以被解決的，隻不過有點麻煩，簡單描述下：

1.可以配置一個預加載列表，在APP啟動或某些時機時提前去請求，這個預加載列表需要包含所需 H5 模塊的頁麵和資源，還需要考慮到一個H5模塊有多個頁麵的情況，這個列表可能會很大，也需要工具生成和管理這個預加載列表。

2.客戶端可以接管所有請求的緩存，不走 webview 默認緩存邏輯，自行實現緩存機製，可以分緩存優先級以及緩存預加載。

3.可以針對每個 HTML 和資源文件做增量更新，隻是實現和管理起來比較麻煩。

4.在客戶端使用 httpdns + https 防劫持。

上麵的解決方案實現起來十分繁瑣，原因就是各個 HTML 和資源文件很多很分散，管理困難，有個較好的方案可以解決這些問題，就是離線包。

離線包

既然很多問題都是文件分散管理困難引起，而我們這裏的使用場景是使用 H5 開發功能模塊，那很容易想到把一個個功能模塊的所有相關頁麵和資源打包下發，這個壓縮包可以稱為功能模塊的離線包。使用離線包的方案，可以相對較簡單地解決上述幾個問題：

1.可以預先下載整個離線包，隻需要按業務模塊配置，不需要按文件配置，離線包包含業務模塊相關的所有頁麵，可以一次性預加載。

2.離線包核心文件和頁麵動態的圖片資源文件緩存分離，可以更方便地管理緩存，離線包也可以整體提前加載進內存，減少磁盤 IO 耗時。

3.離線包可以很方便地根據版本做增量更新。

4.離線包以壓縮包的方式下發，同時會經過加密和校驗，運營商和第三方無法對其劫持篡改。

到這裏，對於使用 H5 開發功能模塊，離線包是一個挺不錯的方案了，簡單複述一下離線包的方案：

1.後端使用構建工具把同一個業務模塊相關的頁麵和資源打包成一個文件，同時對文件加密/簽名。

2.客戶端根據配置表，在自定義時機去把離線包拉下來，做解壓/解密/校驗等工作。

3.根據配置表，打開某個業務時轉接到打開離線包的入口頁麵。

4.攔截網絡請求，對於離線包已經有的文件，直接讀取

5.離線包數據返回，否則走 HTTP 協議緩存邏輯。

離線包更新時，根據版本號後台下發兩個版本間的 diff 數據，客戶端合並，增量更新。

更多優化

離線包方案在緩存上已經做得差不多了，還可以再配上一些細節優化：

公共資源包

每個包都會使用相同的 JS 框架和 CSS 全局樣式，這些資源重複在每一個離線包出現太浪費，可以做一個公共資源包提供這些全局文件。

預加載 webview

無論是 iOS 還是 Android，本地 webview 初始化都要不少時間，可以預先初始化好 webview。這裏分兩種預加載：

1.首次預加載：在一個進程內首次初始化 webview 與第二次初始化不同，首次會比第二次慢很多。原因預計是 webview 首次初始化後，即使 webview 已經釋放，但一些多 webview 共用的全局服務或資源對象仍沒有釋放，第二次初始化時不需要再生成這些對象從而變快。我們可以在 APP 啟動時預先初始化一個 webview 然後釋放，這樣等用戶真正走到 H5 模塊去加載 webview時就變快了。

2.webview 池：可以用兩個或多個 webview 重複使用，而不是每次打開 H5 都新建 webview。不過這種方式要解決頁麵跳轉時清空上一個頁麵，另外若一個 H5 頁麵上 JS 出現內存泄漏，就影響到其他頁麵，在 APP 運行期間都無法釋放了。

預加載數據

理想情況下離線包的方案第一次打開時所有 HTML/JS/CSS 都使用本地緩存，無需等待網絡請求，但頁麵上的用戶數據還是需要實時拉，這裏可以做個優化，在 webview 初始化的同時並行去請求數據，webview 初始化是需要一些時間的，這段時間沒有任何網絡請求，在這個時機並行請求可以節省不少時間。

具體實現上，首先可以在配置表注明某個離線包需要預加載的 URL，客戶端在 webview 初始化同時發起請求，請求由一個管理器管理，請求完成時緩存結果，然後 webview 在初始化完畢後開始請求剛才預加載的 URL，客戶端攔截到請求，轉接到剛才提到的請求管理器，若預加載已完成就直接返回內容，若未完成則等待。

Fallback

如果用戶訪問某個離線包模塊時，這個離線包還沒有下載，或配置表檢測到已有新版本但本地是舊版本的情況如何處理？幾種方案：

1.簡單的方案是如果本地離線包沒有或不是最新，就同步阻塞等待下載最新離線包。這種用戶打開的體驗更差了，因為離線包體積相對較大。

2.也可以是如果本地有舊包，用戶本次就直接使用舊包，如果沒有再同步阻塞等待，這種會導致更新不及時，無法確保用戶使用最新版本。

3.還可以對離線包做一個線上版本，離線包裏的文件在服務端有一一對應的訪問地址，在本地沒有離線包時，直接訪問對應的線上地址，跟傳統打開一個在線頁麵一樣，這種體驗相對等待下載整個離線包較好，也能保證用戶訪問到最新。

第三種 Fallback 的方式還帶來兜底的好處，在一些意外情況離線包出錯的時候可以直接訪問線上版本，功能不受影響，此外像公共資源包更新不及時導致版本沒有對應上時也可以直接訪問線上版本，是個不錯的兜底方案。

上述幾種方案策略也可以混著使用，看業務需求。

使用客戶端接口

網路和存儲接口如果使用 webkit 的 ajax 和 localStorage 會有不少限製，難以優化，可以在客戶端提供這些接口給 JS，客戶端可以在網絡請求上做像 DNS 預解析/IP直連/長連接/並行請求等更細致的優化，存儲也使用客戶端接口也能做讀寫並發/用戶隔離等針對性優化。

服務端渲染

早期 web 頁麵裏，JS 隻是負責交互，所有內容都是直接在 HTML 裏，到現代 H5 頁麵，很多內容已經依賴 JS 邏輯去決定渲染什麼，例如等待 JS 請求 JSON 數據，再拚接成 HTML 生成 DOM 渲染到頁麵上，於是頁麵的渲染展現就要等待這一整個過程，這裏有一個耗時，減少這裏的耗時也是白屏優化的範圍之內。

優化方法可以是人為減少 JS 渲染邏輯，也可以是更徹底地，回歸到原始，所有內容都由服務端返回的 HTML 決定，無需等待 JS 邏輯，稱之為服務端渲染。是否做這種優化視業務情況而定，畢竟這種會帶來開發模式變化/流量增大/服務端開銷增大這些負麵影響。手Q的部分頁麵就是使用服務端渲染的方式，稱為動態直出。

最後

從前端優化，到客戶端緩存，到離線包，到更多的細節優化，做到上述這些點，H5 頁麵在啟動上差不多可以媲美原生的體驗了。

總結起來，大體優化思路就是：緩存/預加載/並行，緩存一切網絡請求，盡量在用戶打開之前就加載好所有內容，能並行做的事不串行做。這裏有些優化手段需要做好一整套工具和流程支持，需要跟開發效率權衡，視實際需求優化。

另外上述討論的是針對功能模塊類的 H5 頁麵秒開的優化方案，客戶端 APP 上除了功能模塊，其他一些像營銷活動/外部接入的 H5 頁麵可能有些優化點就不適用，還需要視實際情況和需求而定。另外微信小程序就是屬於功能模塊的類別，差不多是這個套路。

這裏討論了 H5 頁麵首屏啟動時間的優化，上述優化過後，基本上耗時隻剩 webview 本身的啟動/渲染機製問題了，這個問題跟後續的響應流暢度的問題一起屬於另一個優化範圍，就是類 RN / Weex 這樣的方案，有機會再探討。

作者：螞蟻金服高級無線開發專家 bang

轉自知乎 阿裏巴巴官方技術號