前言：

最近一直在做性能優(yōu)化和模塊化改造的工作，并完成了一次前端重構(gòu)。在這里總結(jié)出一些經(jīng)驗(yàn)和得失來(lái)幫助大家思考。共兩篇文章，第一篇討論性能優(yōu)化，第二篇討論模塊化框架。而之所以把這兩個(gè)話題放到一起，是因?yàn)檫@兩項(xiàng)工作都涉及到對(duì)前端代碼進(jìn)行不同程度的重構(gòu)，而且模塊化改造其實(shí)是我們?cè)趯?duì)性能優(yōu)化做到一定程度之后發(fā)現(xiàn)必須要做的一件事情。本篇是性能優(yōu)化的部分，下面我把我們的產(chǎn)品簡(jiǎn)稱為N頁(yè)面。

應(yīng)用場(chǎng)景分析：

N頁(yè)面作為一個(gè)入口頁(yè)面，對(duì)頁(yè)面加載速度有著極高的要求。同時(shí)，N頁(yè)面內(nèi)部卻又有著非常復(fù)雜的功能與交互。N頁(yè)面的第一版上線時(shí)，頁(yè)面引用的js文件有3個(gè)，一共40-50k（壓縮&Gzip之后）。頁(yè)面onload時(shí)間在1.3秒。

1.3秒的load時(shí)間，相比較絕大多數(shù)網(wǎng)站來(lái)說(shuō)都是一個(gè)不錯(cuò)的數(shù)值。但老板一句話“怎么這個(gè)頁(yè)面打開(kāi)這么慢”，立刻像是給我們的后背安了一枚定時(shí)炸彈。性能優(yōu)化成了N頁(yè)面下一步工作的重中之重。

老板重視頁(yè)面速度，對(duì)于Web前端開(kāi)發(fā)人員來(lái)說(shuō)其實(shí)是件幸事，這表明你將有更豐富的時(shí)間和資源去實(shí)踐Web性能優(yōu)化這一課題，不用被翻來(lái)覆去的產(chǎn)品升級(jí)需求所打擾。那么對(duì)于N頁(yè)面，我們做了哪些實(shí)踐：

常規(guī)優(yōu)化手段包括：

CSS置頂，JS置底。

靜態(tài)資源外聯(lián)、合并、壓縮。

圖片優(yōu)化。（Png使用pngcrush；Gif使用gifsicle；Jpeg使用jpegtran）

圖片延遲加載。（主要針對(duì)首屏外的圖片。）

使用CSS Sprite，首屏圖片全部合到一張圖上。

靜態(tài)文件上CDN。（靜態(tài)文件的下載能提速20%左右。）

靜態(tài)文件設(shè)置強(qiáng)緩存。（命中強(qiáng)緩存82.4%；命中若緩存3.4%；未命中緩存14.2%。）

HTML壓縮。（Gzip后減少%5。）

增強(qiáng)型手段：

基礎(chǔ)庫(kù)定制。（用代碼分析代碼，自動(dòng)打包被使用到的方法作為基礎(chǔ)庫(kù)，使基礎(chǔ)庫(kù)從原來(lái)的壓縮后25K減小為9.8K，減小了61%）

頁(yè)面數(shù)據(jù)存儲(chǔ)優(yōu)化。（從原來(lái)的直接寫(xiě)json形式的script，變?yōu)閷�json隱藏在textarea中，初始化或用到的時(shí)候才去提取并進(jìn)行解析。）

首屏CSS檢測(cè)。（對(duì)首屏用到的CSS進(jìn)行檢測(cè)，將不屬于首屏的CSS代碼單獨(dú)打包并移到首屏之外進(jìn)行延遲加載）

js按需加載。（在后面做重點(diǎn)介紹）

監(jiān)控& 測(cè)量

性能優(yōu)化最重要的工作不是優(yōu)化而是監(jiān)控。這個(gè)道理很簡(jiǎn)單：沒(méi)有監(jiān)控體系就沒(méi)辦法衡量性能優(yōu)化的效果，那么你所做的任何工作都是盲目的。

我們對(duì)性能的監(jiān)控是從多個(gè)維度展開(kāi)的，包括平均時(shí)間、時(shí)段分布、瀏覽器分布、省份、運(yùn)營(yíng)商等。便于發(fā)現(xiàn)和定位任何一個(gè)細(xì)節(jié)的問(wèn)題。

而在平均時(shí)間這一維度，我們又分為四個(gè)級(jí)別：

1.Head時(shí)間– head標(biāo)簽加載完成的時(shí)間

2.TTi時(shí)間– 頁(yè)面可交互時(shí)間（即首屏第一次渲染出來(lái)的時(shí)間）

3.Dom時(shí)間– Dom Ready的時(shí)間

4.Load 時(shí)間– 頁(yè)面完全加載完成的時(shí)間

這樣劃分的好處是，頁(yè)面加載每個(gè)環(huán)節(jié)的耗時(shí)一目了然：

Head ：CSS加載時(shí)間

TTI ：整體HTML加載和渲染時(shí)間

DOM 減TTI ： js文件網(wǎng)絡(luò)傳輸時(shí)間和在瀏覽器進(jìn)行解析的時(shí)間

Load 減Dom ： js初始化+ 圖片加載的時(shí)間

而且，我們通過(guò)移動(dòng)tti時(shí)間點(diǎn)的位置，發(fā)現(xiàn)了一個(gè)有趣的現(xiàn)象，如下圖

可以看出，頁(yè)面加載的性能瓶頸就在script的下載和解析時(shí)間。

為了進(jìn)一步定位性能瓶頸，我們?cè)陧?yè)面內(nèi)對(duì)用戶網(wǎng)速進(jìn)行了測(cè)試，結(jié)果很震驚：有2%的用戶網(wǎng)速小于2k/s，5%的用戶網(wǎng)速小于10k/s。（國(guó)內(nèi)的網(wǎng)絡(luò)狀況真是慘不忍睹�。�

那么，優(yōu)化方案就很明顯了：最大限度地減小js文件大小，以減小網(wǎng)絡(luò)傳輸時(shí)間，提升頁(yè)面性能。

通過(guò)后來(lái)的優(yōu)化工作我們發(fā)現(xiàn)：js代碼壓縮、Gzip后每減小1k，頁(yè)面加載時(shí)間就能減小10ms左右。

按需加載：

這是除了js壓縮外，你能想到的最有效減小js文件大小的辦法了。

按需加載，顧名思義，就是在頁(yè)面首次加載的時(shí)候只提供最需要的js給用戶，而剩余的js等用戶使用到了相關(guān)的功能再去加載。

按需加載適合哪種類型的網(wǎng)站：如果80%的用戶來(lái)到你的頁(yè)面只使用20%的功能，那么就有必要把這20%的js作為首屏加載，而剩余的js做按需加載。

從這個(gè)角度來(lái)講，幾乎所有網(wǎng)站都可以做按需加載，因?yàn)榭傆幸恍┕δ苁怯脩艉苌贂?huì)用到的。

那么，如何做按需加載：

按需加載需要有一套js模塊加載的框架。這個(gè)框架的作用是：保障在所需的js加載完成后才去執(zhí)行回調(diào)方法。

按需加載還需要有一套觸發(fā)條件。在我們的頁(yè)面中，對(duì)鼠標(biāo)移動(dòng)和鼠標(biāo)點(diǎn)擊都進(jìn)行了監(jiān)聽(tīng)，以保障在用戶想使用某個(gè)功能之前或進(jìn)行了相應(yīng)操作時(shí)，觸發(fā)js加載。

除此之外，我們還對(duì)js基礎(chǔ)庫(kù)進(jìn)行了進(jìn)一步拆分，分為首屏用到的基礎(chǔ)方法，和延遲加載的js所需的基礎(chǔ)方法。以最大限度地保證首屏js量的最小化。

通過(guò)按需加載的拆分，我們將首屏的js代碼從原來(lái)的gzip之后40-50k減小到了只有24k。

同時(shí)，我們對(duì)CSS的加載也進(jìn)行拆分，首屏不需要的CSS代碼也隨JS進(jìn)行延遲加載。

效果 & 總結(jié)

性能優(yōu)化是一個(gè)非常繁瑣的工作，頁(yè)面性能受很多因素的制約，不過(guò)相信一點(diǎn)：方法總比問(wèn)題多。我們通過(guò)優(yōu)化，最終將頁(yè)面加載時(shí)間降到了650ms，僅為優(yōu)化前的一半。所有優(yōu)化工作中，效果最明顯的就是js按需加載了。

不過(guò)按需加載也為我們的代碼結(jié)構(gòu)帶來(lái)了很大的沖擊，極大地改變了我們寫(xiě)代碼的方式，也制造了很多問(wèn)題，我會(huì)在下一篇《前端重構(gòu)——模塊化框架實(shí)踐》中進(jìn)行詳細(xì)介紹。

文章來(lái)源：百度搜索研發(fā)部官方博客

標(biāo)簽： 網(wǎng)站優(yōu)化 圖片優(yōu)化 頁(yè)面優(yōu)化 

版權(quán)申明：本站文章部分自網(wǎng)絡(luò)，如有侵權(quán)，請(qǐng)聯(lián)系：west999com@outlook.com
特別注意：本站所有轉(zhuǎn)載文章言論不代表本站觀點(diǎn)！
本站所提供的圖片等素材，版權(quán)歸原作者所有，如需使用，請(qǐng)與原作者聯(lián)系。