這份文字是根據(jù)近期團隊做來問丁香醫(yī)生 SPA 和 丁香醫(yī)生小程序 加載速度優(yōu)化的經歷整理而成。

效果

古人有一句話叫做：治感冒看療效。既然是關于速度優(yōu)化的，我們就先來看一下優(yōu)化的效果。

來問丁香醫(yī)生

Chrome Network

選取了訪問量較大的首頁和我的頁面進行隨機取樣，通過下圖可以看到首頁的加載時間從 5.1s 下降到 1.67s，我的頁面從 2.92s 下降到 1.82s。

 

mta

2018.01.02 早上的頁面響應速度數(shù)據(jù)，目前國內各省份平均加載速度在 0.99~2s（雖然沒有達到 1s 內加載，但是以目前業(yè)務量級，這樣的速度是可以被接受的）：

前者這是 Google 的一個評分工具，最開始做優(yōu)化時用它測了一些頁面的分數(shù)。后來發(fā)現(xiàn)了后面這些 Chrome 插件。讓我困惑的是同樣的頁面這幾個工具給出的結果分數(shù)都不一樣。手淘 的首屏加載速度挺快的，但是跑出來的分數(shù)也不高。最終我只是選擇性的參考一下工具給出來的建議，忽視了其給出的評分。

丁香醫(yī)生小程序

對于小程序，做了優(yōu)化后得到部門同學的反饋是這樣的：

具體的數(shù)據(jù)指標如何呢？雖然目前沒有特別好用的性能檢測方式（包括官方提供的性能檢測工具在內），最終我們組的舒哲同學還是利用官方提供的工具做了一下簡單的數(shù)據(jù)對比，數(shù)據(jù)如下：

在不影響產品需求正常迭代的前提下，兩個項目的優(yōu)化斷斷續(xù)續(xù)持續(xù)了兩周。整體上來說，本次優(yōu)化的性價比還是較高的。

為什么做加載速度優(yōu)化？

直接原因很簡單：慢。雖然說頁面加載速度并沒有達到慢的讓人無法忍受，但至少沒辦法讓人說加載很快。

既然明知道加載速度不快，那之前在干什么？為什么不早早的去做優(yōu)化呢？

這是一個好問題，我曾經在深夜中問過自己多次。我給自己的答案是：首先，要承認自身技術水平和經驗的限制，如果是一個在前端戰(zhàn)場上身經百戰(zhàn)的人一直在負責項目的迭代，或許情況會比優(yōu)化前好一些。 其次，之前整個產品線的項目一直處于探索和快速迭代中，前端研發(fā)資源基本上總是處在被需求排滿的狀態(tài)下，產品需求快速上線的優(yōu)先級是最高的。正是因為產品的整體節(jié)奏稍微放緩了一些，才讓研發(fā)資源有精力來做一些優(yōu)化。

為什么說是前端響應速度優(yōu)化，而不是前后端？

因為我是親眼看著這兩個項目逐漸長大的，單從前端工程的角度來審視，在自己的認知范圍內，早就認為項目中有一些地方是需要優(yōu)化的。堅定了先從前端動手的想法，是因為讀了《高性能網(wǎng)站建設指南》這本書，書中提到了一個性能黃金法則（Performance Golden Rule）：只有 10% ~ 20% 的最終用戶響應時間是花在下載 HTML 文檔上。話說到這個份上，還猶豫什么呢，先從前端項目開始擼起袖子加油干吧。

之前去 Qcon 等技術大會上，聽過幾次關于加載速度的分享。比如：使用 HTTP2，整站級別的前后端優(yōu)化等。方案確實是好的方案，但具體是否要應用到自己團隊實際項目中，還得根據(jù)執(zhí)行成本、團隊技術儲備等維度從長計議。

為什么說是初級？

因為深感自己在前端性能優(yōu)化這個領域還有很長的路要走。

如何做的？

前戲這么長，終于可以開始了。

來問丁香醫(yī)生 SPA

先看圖（綠色部分為已在項目中應用的方法）：

實現(xiàn)游客機制

最初來問丁香醫(yī)生是基于微信服務號做的，當時的設計是用戶通過服務號菜單進入應用時，會自動幫他進行跳轉登錄，登錄成功后服務端再重定向回到應用。登錄這個環(huán)節(jié)，雖然與項目代碼層面的加載優(yōu)化關系不大，但是從用戶體驗的角度這樣的流程是不好的。因為相比于直接打開頁面，用戶需要等更長的時間，并且會看到兩次頁面加載的進度條。從產品的角度，一些頁面是不需要用戶登錄即可訪問的。綜上，將登錄流程后置，讓用戶可以直接進入應用這件事情，于情于理都是必須要做的。

改造流程大致為：梳理產品現(xiàn)有流程 -> 用戶進入應用時取消強制登錄 -> 在產品流程核心環(huán)節(jié)進行用戶登錄狀態(tài)判斷并引導登錄。具體實現(xiàn)細節(jié)不再贅述。

減小資源包體積

實現(xiàn)了游客機制后，接下來就是對應用的資源包動手了。因為通過 Chrome 開發(fā)者工具的 Network 可以看出，下載 CSS、JS 資源還是占用了不少時間的。下圖是減小資源包體積之前的情況：

優(yōu)化前包體積大小-Gzipped

精簡第三方依賴

想要減少資源體積大小，首先需要知道哪些資源時應該/可以被刪除的。由于項目是基于 Webpack 構建的，因此可以使用 Webpack Bundle Analyzer 進行分析Webpack 生成的包體組成。然后根據(jù)實際情況進行移除就好。

精簡了第三方依賴后，啟動應用時需要下載的資源體積還是挺大的。此時就需要使用 Webpack 的代碼分離和懶加載進行進一步的優(yōu)化。

代碼分離

代碼分離的思想就是化整為零，將代碼分離到不同的 bundle 中，然后可以按需加載或并行加載這些小的 bundle 文件。

代碼分離主要是利用 Webpack 的動態(tài)導入

Webpack 目前有三種常用的代碼分離方法：

• 入口起點：使用 entry 配置手動地分離代碼。（優(yōu)勢：簡單、直觀。劣勢：配置繁瑣、同一份代碼可能會被引入到各個 bundle 中、不靈活，并不能將核心應用程序邏輯進行動態(tài)拆分代碼）
• 防止重復：使用 CommonsChunkPlugin 去重和分離 chunk。
• 動態(tài)導入：通過模塊的內聯(lián)函數(shù)調用來分離代碼。

經過對比之后，最終選擇了動態(tài)導入的方式。

動態(tài)導入(dynamic imports)

webpack 提供了兩個類似的技術：

• import() 語法（推薦，符合 ECMAScript 提案）
• require.ensure（webpack 欽定）

示例

// 分離 lodash
async function getComponent() {
    const _ = await import(/* webpackChunkName: "lodash" */ 'lodash');
}

懶加載

懶加載是在代碼分離的基礎上更近了一步。

雖然我們可以將代碼進行代碼分離，但代碼分離后的 bundle 只是加載的優(yōu)先級會不同，最終還是會加載，但實際情況是某些代碼在用戶進行某項操作之前是不需要加載的。比如：個人信息編輯頁面有一個用戶修改頭像功能，對于用戶來說，即使他進入了個人信息編輯頁面，在他未點擊上傳按鈕之前，用于上傳頭像的代碼是沒必要加載的。

Vue-Router 結合 Vue 的異步組件和 Webpack 的代碼分割功能，實現(xiàn)了路由組件的懶加載。

在經過精簡依賴、代碼分離和懶加載之后，項目的資源包體積大小如下圖：

Gzipped：

用戶進入首頁需要加載的 js 資源從 vendor.js 、 main.js 和 chunks 共 672.84kb 變?yōu)橹恍枰虞d一個 186kb 的 main.js 。

復用 Store 數(shù)據(jù)以減少網(wǎng)絡請求數(shù)量

來問丁香醫(yī)生是基于Vue.js 全家桶實現(xiàn)的，狀態(tài)管理用的是Vuex。

之前的實現(xiàn)中，有些功能實現(xiàn)沒有很在意 Store 數(shù)據(jù)的復用。比如：從 A 頁面進入 B 頁面后再返回 A 頁面時，會再去獲取端獲取一次 A 頁面需要的數(shù)據(jù)。這種處理不僅僅是多發(fā)了不必要的請求，如果在請求過程中做了一些頁面級別加載中的處理，那么每次切換頁面時都會讓用戶看到 loading 效果，這也會讓人覺得加載慢。既然用了狀態(tài)管理，那么就應該把他利用好才是。

本次優(yōu)化過程中的數(shù)據(jù)復用，主要是在部分請求 action 之前增加邏輯判斷，如果 Store 中有當前操作需要的數(shù)據(jù)，則不再調用 action 。

前后端徹底分離

關于這一點會再寫一篇文章進行闡述。

丁香醫(yī)生小程序

老規(guī)矩，先看圖：

圖片資源

最開始做小程序時，是把所有圖片資源 base64 后進行使用的，這導致了所有圖片資源最終都被打包到小程序的安裝包中。所以做小程序的加載速度優(yōu)化的第一步，就是把一些體積較大的圖片資源改為使用線上資源。具體做法是將素材先上傳到 cdn，然后在小程序中直接使用線上圖片地址。

登錄鑒權優(yōu)化

原本小程序的登錄是我們自己實現(xiàn)的一套登錄方案，核心是前后端一起維護一個類似于 SessionId 的 ID。服務端對于這個 ID 是設置了有效期的，而之前前端的實現(xiàn)是每次用戶啟動小程序，都直接去請求公司的 SSO 獲取一個新的 ID，沒有在意本地的 ID 是否過期。

優(yōu)化的點在于在應用啟動時，增加對 ID 有效期的判斷，從而避免每次用戶啟動都需要發(fā)請求獲取新的 ID。

預渲染

之前在小程序所有需要從服務端獲取數(shù)據(jù)的頁面，都實現(xiàn)了一個加載中的效果，即請求未返回結果時，整個頁面用戶只會看到一個加載中的菊花。如果某頁面只有服務端提供的元數(shù)據(jù)級別接口，沒有業(yè)務接口，并且接口返回的數(shù)據(jù)是有依賴關系的，那么用戶等待的時間會大大加長。

仔細思考會發(fā)現(xiàn)，其實是沒有必要等所有接口數(shù)據(jù)回來后再給用戶呈現(xiàn)完整頁面的。

最終的優(yōu)化方案分為兩種：一種是取消加載中效果，先給用戶呈現(xiàn)完整的利用本地數(shù)據(jù)渲染好的頁面，等接口返回數(shù)據(jù)后在進行頁面視圖的更新；另外一種方案是取消加載中效果，但是不做本地數(shù)據(jù)渲染，而是直接給用戶看到部分靜態(tài)頁面。

分包加載

關于分包加載，就老老實實的按照官方文檔做就好了。進行分包后的效果還是很不錯的。具體效果可以參考文章開頭的數(shù)據(jù)統(tǒng)計。

目前上述方案中，效果比較明顯的是預渲染和分包加載。一個是視覺上讓用戶覺得快了，一個是真真切切的把首次加載的資源包變小了。