移動 WEB 通用優化策略介紹（1）

在我去年的《AMP，來自 Google 的移動頁面優化方案》這篇文章裡，我給自己挖了個坑：

藉助客戶端所做的優化，如現在廣為流行的移動端 Webview 容器加速方案，優化效果侷限在指定 APP 內，甚至還會導致使用通用瀏覽器訪問速度更慢（這個話題很有意思，有機會以後再討論）。

現在過去快半年，我終於想起來把這個坑填上，今天先來寫這個系列第一篇。

我在標題裡用了「通用」二字，說明我要介紹的優化策略不是為特定的 Webview 容器定製，它面向的是所有主流的移動端瀏覽器，包括各種 APP 嵌入的通用 Webview。

藉助定製化的 Webview 容器，我們完全可以通過主動提前本地化資源包，使得移動 WEB 應用跟 Native 應用一樣，只需走網路獲取必要的資料。這種情況下的效能優化，更多需要關注程式碼執行效率，本地化資源包的推送流程和成功率。

而對於通用的移動 WEB 效能優化，首先要考慮的是網路傳輸效能。

我們知道，瀏覽器獲取一個資源，花在網路上的時間開銷至少有這幾塊：DNS 解析、建立 TCP 連線、傳送請求、等待響應、傳輸響應正文。相比 PC 的網路環境，移動端更為糟糕，集中在這幾點：高時延、高丟包、低速率、多劫持。

所以，在移動 WEB 上，引入外鏈資源的網路成本非常高。在我們最近的一次測試中，移動端同域名空圖片（使用 Nginx 的 empty_gif 指令構造）載入失敗率（我們對失敗的定義是觸發圖片的 error 事件，或者超過 9s 仍未觸發 load 事件）高達 2%，外域圖片失敗率還要高上幾個百分點。

我們還知道，頭部的外鏈 CSS、JS 會阻塞頁面渲染，通俗來講就是頭部的這些外鏈資源載入完之前，頁面會一直白屏。之前我們統計過，一個 GZip 後十幾 KB 的頭部 JS，會增加大概半秒的白屏時間。

基於上述原因，我的移動 WEB 通用優化策略第一要點：

重要的 CSS、JS 直接內聯在 HTML 中，頭部禁止出現任何外鏈資源。

需要注意的是，很多效能評估工具 / 文件都說 HTML 頭部不要有任何 JS。實際上這一點在實際專案中很難做到，至少大部分頁面效能監控就需要在頭部計時（Web Performance API 並不能解決所有效能監控問題）。對於頭部內聯 JS，我只有兩點要求：1）沒有耗時操作；2）只保留必要程式碼。

現在很多 WEB 應用，尤其是 SPA，服務端往往都只提供 RESTful 資料介面。這樣頁面 JS 程式碼執行過程中，還要非同步獲取資料，在資料載入完成之前，頁面一片空白或者只有 Loading。這麼做也違背了我提出的第一要點，要解決這個問題最簡單的做法是服務端直接將首屏資料以 JSON 變數的形式輸出到頁面上；高階點的方案是利用 JavaScript 同構框架，首屏直接輸出 HTML。

將重要 CSS、JS 甚至資料介面都內聯在頁面上，可以減少由於行動網路環境造成的頁面呈現慢或者不可用等情況，但是也帶來另外的問題：多次請求之間無法利用快取，浪費流量，也讓行動網路低速率的問題雪上加霜。

為了聚焦，本文不討論程式碼壓縮、傳輸壓縮以及清理無用程式碼等減少檔案體積等基礎優化專案。我們假設要載入的所有內容都是必須的且壓縮過。那麼，對於使用者首次訪問，內聯無疑是最優選擇，因為無論如何這些資源都要載入，能減少連線數就是最大的改進。那麼，如何解決使用者後續訪問，內聯導致的無法利用 HTTP 快取機制的問題呢？

我們引入了 localStorage 方案：使用者首次訪問時，服務端輸出包含內聯 CSS、JS 和 JSON 資料的頁面，並通過 JS 將這些資料存入 localStorage；使用者後續訪問時，服務端只需要輸出從 localStorage 讀取並執行程式碼的 JS 片段即可。這樣，後續訪問的頁面體積就小很多了。

可以看到，這個方案的難點在於：1）服務端如何得知使用者本地存有 localStorage；2）服務端如何得知使用者本地存的 localStorage 中的某個具體檔案的版本是否最新。有同學會說，把存入 localStorage 的檔案及對應版本都記在 Cookie 裡不就可以了？但別忘了往 Cookie 裡存太多資訊，本身就是一種錯誤的做法。況且，如果 Cookie 資訊完好，但 localStorage 卻被清除要怎麼處理？

為此，我們設計了一整套流程。首先，我們引入了由以下字元組成的 70 進位制：

它們會被用來在 Cookie 中存放檔案路徑及版本號，70 進位制意味著可以用單字元區分 70 種不同的檔案或版本。另外，這 70 個字元都無需編碼即可存入 Cookie。

然後，在編譯流程中，對全站程式碼裡所有需要存入 localStorage 的資源（我們通過外鏈標籤是否存在某個自定義屬性來判斷）進行分析，生成檔名及對應版本號的 Map 檔案。示意如下：

這份配置每次編譯都需要重新構建，但有兩點需要保證：1）相同檔案路徑對應的 70 進位制字元標記必須固定；2）檔案內容 md5 發生變化時，對應的版本號需要 +1。每個使用到本方案的頁面頭部都需要包含這份配置。

那麼對於下面這樣的原始 HTML 程式碼片段：

使用者首次訪問時，將以這樣的形式輸出：

這時，使用者本地將會新增 css_1、js_1、js_2 三份 localStorage 資料，以及取值為 001020 的一個 Cookie。

使用者再次訪問時，服務端會分析 Cookie，找出對應檔案在 Map 配置中的版本號，與 Cookie 中的版本進行比較，如果都沒有變化，則只會輸出這樣少量的程式碼：

這樣，瀏覽器就會從 localStorage 中取出之前儲存的內容，建立相應的標籤並執行。

如果之前的資源有改動，編譯後 Map 配置檔案就會更新。假設 js_1 已經迭代到版本 3，那麼服務端會輸出這樣的程式碼：

可以看到，只有本次更新的資源才會輸出全部內容。這份程式碼執行完之後，本地 js_1 這份 localStorage 會隨之更新，Cookie 也會更新為 001320。

看到這裡，大家應該明白這個方案的基本原理了，這個方案需要在服務端處理一系列複雜的分支判斷，具體實現程式碼我就不貼了。下面說幾個需要特別關注的點：

首先，移動端部分瀏覽器在隱私模式下，訪問 localStorage 物件會直接丟擲異常，必須把 localStorage 的幾個方法包裝一下，加上 try。

其次，如果 Cookie 中的標記存在，但是 localStorage 內容丟失如何處理？我們來看這行程式碼：

它執行的具體操作是：查詢 localStorage 中名為 css_1 的變數，建立 style 標籤插入頁面中。第三個引數值 cookie_name 是為了在讀取 localStorage 失敗時，能夠清掉這個 Cookie 標記，並且重新整理頁面。這時，服務端發現 Cookie 標記不存在，就會全量輸出內聯內容，等同於首次訪問。

另外，我們用單字元標記檔名和版本，容量只有 70。每個專案中，允許同時有 70 個不同的檔案存入 localStorage，完全夠用。假設一個檔案每週修改兩次版本，那麼 70 個版本號會在大半年後迴圈到起點。假設使用者瀏覽器存在某個檔案的版本 0，大半年期間一直沒來訪問，直到這個檔案的版本號迴圈到 0 他再訪問一次，這時候服務端會認為他本地的檔案已經是最新的。這種極端情況我們評估後認為完全可以接受。如果實在不放心，可以將檔案或版本擴充為兩位來表示，就能應對 4900 種不同情況。

有些 Webview 沒有開啟 localStorage 功能，如果我們檢測到這種情況，就額外記一個 Cookie 標記，服務端看到這個標記，每次直接全量輸出內聯。同樣，如果 Webview 連 Cookie 也不支援，那麼最終效果也是每次都全量內聯，至少不比優化前差。

實際上，還可以採用類似於購物車的做法實施這套方案：在使用者瀏覽器存一個 Cookie 標識，然後服務端通過 Redis 這樣的 KV 服務來找出曾經給他傳送過哪些資源及各自版本。這樣做的好處是程式碼邏輯簡單，但需要引入外部服務。

資源內聯可以緩解移動端網路的高時延、高丟包等問題；而資源 localStorage 化可以應對低速率；二者結合使用，才能有最好的效果。也就是說，我前面提出的移動 WEB 通用優化策略第一要點需要完善下：

重要的 CSS、JS、JSON 資料直接內聯在 HTML 中，頭部禁止出現任何外鏈資源。同時，儘可能減少頁面傳輸體積。

好了，這個系列的開篇先就寫這麼多。還是老規矩，如果有任何問題和疑問歡迎留言，我會及時回覆。

打賞支援我寫出更多好文章，謝謝！

任選一種支付方式