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

效果

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

來問丁香醫(yī)生

Chrome Network

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

 

mta

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

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

丁香醫(yī)生小程序

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

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

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

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

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

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

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

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

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

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

為什么說是初級？

因?yàn)樯罡凶约涸谇岸诵阅軆?yōu)化這個(gè)領(lǐng)域還有很長的路要走。

如何做的？

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

來問丁香醫(yī)生 SPA

先看圖（綠色部分為已在項(xiàng)目中應(yīng)用的方法）：

實(shí)現(xiàn)游客機(jī)制

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

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

減小資源包體積

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

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

精簡第三方依賴

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

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

代碼分離

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

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

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

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

經(jīng)過對比之后，最終選擇了動(dòng)態(tài)導(dǎo)入的方式。

動(dòng)態(tài)導(dǎo)入(dynamic imports)

webpack 提供了兩個(gè)類似的技術(shù)：

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

示例

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

懶加載

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

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

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

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

Gzipped：

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

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

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

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

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

前后端徹底分離

關(guān)于這一點(diǎn)會(huì)再寫一篇文章進(jìn)行闡述。

丁香醫(yī)生小程序

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

圖片資源

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

登錄鑒權(quán)優(yōu)化

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

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

預(yù)渲染

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

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

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

分包加載

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

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