摘要：前言對于前端的性能話題，從來都沒有斷絕過。作為一個前端開發(fā)者，性能是我們關(guān)注的指標。前端發(fā)展以來，優(yōu)化方式，琳瑯滿目，有雅虎軍規(guī)等。所以，接下來我會從三個方面就前端性能進行總結(jié)網(wǎng)絡(luò)方面操作及渲染方面數(shù)據(jù)方面。

對于前端的性能話題，從來都沒有斷絕過。因為這個東西沒有最好，只有更好。而且往往也是業(yè)務(wù)的繁雜程度去決定優(yōu)化程度的。作為一個前端開發(fā)者，性能是我們關(guān)注的指標。它直接影響著我們的用戶，同時也影響著產(chǎn)品本身。前端發(fā)展以來，優(yōu)化方式，琳瑯滿目，有雅虎軍規(guī)等。這些內(nèi)容復(fù)雜繁多，往往容易被人遺忘。因此，本篇對于這些常用的優(yōu)化方式進行總結(jié)，或許，并不全面，見諒。如果你喜歡我的文章，歡迎評論，歡迎Star~。歡迎關(guān)注我的github博客

原文鏈接：https://juejin.im/post/59e1bbc9f265da430f311fb1

前端優(yōu)化層出不窮，移動端大行其道的現(xiàn)在，我們可以說優(yōu)化好移動端，PC端也將會更好。所以，我們可以綜合以下圖片進行一些分析，如圖：

圖中已經(jīng)對前端性能做了一些概括。但其實，我覺得我們可以將這個概括更加精準，扼要，豐富。所以，接下來我會從三個方面就前端性能進行總結(jié)：網(wǎng)絡(luò)方面、DOM操作及渲染方面、數(shù)據(jù)方面。

web應(yīng)用，總是會有一部分的時間浪費在網(wǎng)絡(luò)連接和資源下載方面。往往建立一次網(wǎng)絡(luò)連接是需要時間成本的。而且瀏覽器同一時間所發(fā)送的網(wǎng)絡(luò)請求數(shù)是有限的。所以，這個層面的優(yōu)化可以從「減少請求數(shù)目」開始：

減少http請求：在YUI35規(guī)則中也有提到，主要是優(yōu)化js、css和圖片資源三個方面，因為html是沒有辦法避免的。因此，我們可以做一下的幾項操作：

合并js文件

合并css文件

雪碧圖的使用(css sprite)

使用base64表示簡單的圖片

上述四個方法，前面兩者我們可以使用webpack之類的打包工具進行打包；雪碧圖的話，也有專門的制作工具；圖片的編碼是使用base64的，所以，對于一些簡單的圖片，例如空白圖等，可以使用base64直接寫入html中。

回到之前網(wǎng)絡(luò)層面的問題，除了減少請求數(shù)量來加快網(wǎng)絡(luò)加載速度，往往整個資源的體積也是，平時我們會關(guān)注的方面。

減小資源體積：可以通過以下幾個方面進行實施：

gzip壓縮

js混淆

css壓縮

圖片壓縮

gzip壓縮主要是針對html文件來說的，它可以將html中重復(fù)的部分進行一個打包，多次復(fù)用的過程。js的混淆可以有簡單的壓縮(將空白字符刪除)、丑化(丑化的方法，就是將一些變量縮小)、或者可以使用php對js進行混淆加密。css壓縮，就是進行簡單的壓縮。圖片的壓縮，主要也是減小體積，在不影響觀感的前提下，盡量壓縮圖片，使用png等圖片格式，減少矢量圖、高清圖等的使用。這樣子的做法不僅可以加快網(wǎng)頁顯示，也能減少流量的損耗。

除了以上兩部分的操作之外，在網(wǎng)絡(luò)層面我們還需要做好緩存工作。真正的性能優(yōu)化來說，緩存是效率最高的一種，往往縮短的加載時間也是最大的。

緩存：可以通過以下幾個方面來描述：

DNS緩存

CDN部署與緩存

http緩存

由于瀏覽器會在DNS解析步驟中消耗一定的時間，所以，對于一些高訪問量網(wǎng)站來說，做好DNS的緩存工作，就會一定程度上提升網(wǎng)站效率。CDN緩存，CDN作為靜態(tài)資源文件的分發(fā)網(wǎng)絡(luò)，本身就已經(jīng)提升了，網(wǎng)站靜態(tài)資源的獲取速度，加快網(wǎng)站的加載速度，同時也給靜態(tài)資源做好緩存工作，有效的利用已緩存的靜態(tài)資源，加快獲取速度。http緩存，也是給資源設(shè)定緩存時間，防止在有效的緩存時間內(nèi)對資源進行重復(fù)的下載，從而提升整體網(wǎng)頁的加載速度。

其實，網(wǎng)絡(luò)層面的優(yōu)化還有很多，特別是針對于移動端頁面來說。眾所周知，移動端對于網(wǎng)絡(luò)的敏感度更加的高，除了目前的4G和WIFI之外，其他的移動端網(wǎng)絡(luò)相當于弱網(wǎng)環(huán)境，在這種環(huán)境下，資源的緩存利用是相當重要的。而且，減少http的請求次數(shù)，也是至關(guān)重要的，移動端弱網(wǎng)環(huán)境下，對于http請求的時間也會增加。所以，我們可以看一下我們在移動端網(wǎng)絡(luò)方面可以做的優(yōu)化：

移動端優(yōu)化：使用以下幾種方式來加快移動端網(wǎng)絡(luò)方面的優(yōu)化：

使用長cache，減少重定向

首屏優(yōu)化，保證首屏加載數(shù)據(jù)小于14kb

不濫用web字體

「使用長cache」，可以使得移動端的部分資源設(shè)定長期緩存，這樣可以保證資源不用向服務(wù)器發(fā)送請求，來比較資源是否更新，從而避免304的情況。304重定向，在PC端或許并不會影響網(wǎng)頁的加載速度，但是，在移動端網(wǎng)絡(luò)不穩(wěn)定的前提下，多一次請求，就多了一部分加載時間。「首屏優(yōu)化」，對于移動端來說是至關(guān)重要的。2s時間是用戶的最佳體驗，一旦超出這個時間，將會導(dǎo)致用戶的流失。所以，針對移動端的網(wǎng)絡(luò)情況，不可能在這么短時間內(nèi)加載完成所有的網(wǎng)頁資源，所以我們必須保證首屏中的內(nèi)容被優(yōu)先顯示出來，而且基于TCP的慢啟動和擁塞控制，第一個14kb的數(shù)據(jù)是非常重要的，所以需要保證首部加載數(shù)據(jù)能夠小于14kb。「不濫用web字體」，web字體的好處就是，可以代替某些圖片資源，但是，在移動端過多的web字體的使用，會導(dǎo)致頁面資源加載的繁重，所以，慎用web字體

首先，簡單的聊一下優(yōu)化渲染的重要性。在網(wǎng)頁初步加載時，獲取到HTML文件之后，最初的工作是構(gòu)建DOM和構(gòu)建CSSOM兩個樹，之后將他們合并形成渲染樹，最后對其進行打印。我們可以通過圖片來看一下，簡單的過程：

這里整個過程拉出來寫，具體可以再寫一篇文章，恕我偷下懶，推薦一篇比較好的文章給大家吧。瀏覽器渲染過程與性能優(yōu)化

繼續(xù)我們的話題，我們可以如何去縮短這個過程呢？可以從以下幾個操作進行優(yōu)化。

優(yōu)化網(wǎng)頁渲染：

css的文件放在頭部，js文件放在尾部或者異步

盡量避免內(nèi)聯(lián)樣式

css文件放在「頭部加載」，可以保證解析DOM的同時，解析css文件。因為，CSS（外鏈或內(nèi)聯(lián)）會阻塞整個DOM的渲染，然而DOM解析會正常進行，所以將css文件放在頭部進行解析，可以加快網(wǎng)頁的構(gòu)建速度。假設(shè)將其放在尾部，那時DOM樹幾乎構(gòu)建，這時就得等到CSSOM樹構(gòu)建完成，才能夠繼續(xù)下面的步驟。「js放在尾部」：js文件不同，將js文件放在尾部或者異步加載的原因是JS（外鏈或內(nèi)聯(lián)）會阻塞后續(xù)DOM的解析，后續(xù)DOM的渲染也將被阻塞，而且一旦js中遇到DOM元素的操作，很可能會影響。這方面可以推薦一篇文章——異步腳本載入提高頁面性能。「避免使用內(nèi)聯(lián)樣式」，可以有效的減少html的體積，一般考慮內(nèi)聯(lián)樣式的時候，往往是樣式本身體積比較小，往往加載網(wǎng)絡(luò)資源的時間會大于它的時候。

除了頁面渲染層面的優(yōu)化，當然最重要的就是DOM操作方面的優(yōu)化，這部分的優(yōu)化應(yīng)該是最多的，而且也是平時開發(fā)可以注意的地方。如果開發(fā)前期明白這些原理，同時付諸實踐的話，就可以在后期的性能完善上面少下很多功夫。那么，接下來我們可以來看一下具體的操作：

DOM操作優(yōu)化：

避免在document上直接進行頻繁的DOM操作

使用classname代替大量的內(nèi)聯(lián)樣式修改

對于復(fù)雜的UI元素，設(shè)置position為absolute或fixed

盡量使用css動畫

使用requestAnimationFrame代替setInterval操作

適當使用canvas

盡量減少css表達式的使用

使用事件代理

前面三個操作，其實都是希望『減少回流和重繪』。其實，進行一次DOM操作的代價是非常之大的，以前可以通過網(wǎng)頁操作是否卡頓來進行判斷，但是，現(xiàn)代瀏覽器的進步已經(jīng)大大減少了這方面的影響。但是，我們還是需要清楚，如何去減少回流和重繪的問題。因為這里不想細說這方面的知識，想要了解的話，可以看這篇文章——回流與重繪：CSS性能讓JavaScript變慢？。這可是張鑫旭大大的一篇文章呦(^.^)。「盡量使用css動畫」，是因為本身css動畫比較簡單，而且相較于js的復(fù)雜動畫，瀏覽器本身對其進行了優(yōu)化，使用上面不會出現(xiàn)卡頓等問題。「使用requestAnimationFrame代替setInterval操作」，相信大家都有所耳聞，setInterval定時器會有一定的延時，對于變動性高的動畫來說，會出現(xiàn)卡頓現(xiàn)象。而requestAnimationFrame正好解決的整個問題。「適當使用canvas」，不得不說canvas是前端的一個進步，出現(xiàn)了它之后，前端界面的復(fù)雜性也隨之提升了。一些難以完成的動畫，都可以使用canvas進行輔助完成。但是，canvas使用頻繁的話，會加重瀏覽器渲染的壓力，同時導(dǎo)致性能的下降。所以，適當時候使用canvas是一個不錯的建議。「盡量減少css表達式的使用」，這個在YUI規(guī)則中也被提到過，往往css的表達式在設(shè)計之初都是美好的，但在使用過程中，由于其頻繁觸發(fā)的特性，會拖累網(wǎng)頁的性能，出現(xiàn)卡頓。因此在使用過程中盡量減少css表達式的使用，可以改換成js進行操作。「使用事件代理」：往往對于具備冒泡性質(zhì)的事件來說，使用事件代理不失為一種好的方法。舉個例子：一段列表都需要設(shè)定點擊事件，這時如果你給列表中的每一項設(shè)定監(jiān)聽，往往會導(dǎo)致整體的性能下降，但是如果你給整個列表設(shè)置一個事件，然后通過點擊定位目標來觸發(fā)相應(yīng)的操作，往往性能就會得到改善。

DOM操作的優(yōu)化，還有很多，當然也包括移動端的。這個會在之后移動端優(yōu)化部分被提及，此處先賣個關(guān)子。上面我們概述了開始渲染的時候和DOM操作的時候的一些注意事項。接下來要講的是一些小細節(jié)的注意，這些細節(jié)可能對于頁面影響不大，但是一旦堆積多了，性能也會有所影響。

操作細節(jié)注意：

避免圖片或者frame使用空src

在css屬性為0時，去掉單位

禁止圖像縮放

正確的css前綴的使用

移除空的css規(guī)則

對于css中可繼承的屬性，如font-size，盡量使用繼承，少一點設(shè)置

縮短css選擇器，多使用偽元素等幫助定位

上述的一些操作細節(jié)，是平時在開發(fā)中被要求的，更可以理解為開發(fā)規(guī)范。(基本操作，坐下^_^)

列舉完基本操作之后，我們再來聊一下移動端在DOM操作方面的一些優(yōu)化。

移動端優(yōu)化：

長列表滾動優(yōu)化

函數(shù)防抖和函數(shù)節(jié)流

使用touchstart、touchend代替click

HTML的viewport設(shè)置

開啟GPU渲染加速

首先，長列表滾動問題，是移動端需要面對的，IOS盡量使用局部滾動，android盡量使用全局滾動。同時，需要給body添加上-webkit-overflow-scrolling: touch來優(yōu)化移動段的滾動。如果有興趣的同學，可以去了解一下ios和android滾動操作上的區(qū)別以及優(yōu)化。「防抖和節(jié)流」，設(shè)計到滾動等會被頻繁觸發(fā)的DOM事件，需要做好防抖和節(jié)流的工作。它們都是為了限制函數(shù)的執(zhí)行頻次，以優(yōu)化函數(shù)觸發(fā)頻率過高導(dǎo)致的響應(yīng)速度跟不上觸發(fā)頻率，出現(xiàn)延遲，假死或卡頓的現(xiàn)象。

介紹：函數(shù)防抖，當調(diào)用動作過n毫秒后，才會執(zhí)行該動作，若在這n毫秒內(nèi)又調(diào)用此動作則將重新計算執(zhí)行時間；函數(shù)節(jié)流，預(yù)先設(shè)定一個執(zhí)行周期，當調(diào)用動作的時刻大于等于執(zhí)行周期則執(zhí)行該動作，然后進入下一個新周期。

「touchstart、touchend代替click」，也是移動端比較常用的操作。click在移動端會有300ms延時，這應(yīng)該是一個常識唄。(不知道的小伙伴該收藏一下呦)。這種方法會影響用戶的體驗。所以做優(yōu)化時，最簡單的方法就是使用touchstart或者touchend代替click。因為它們事件執(zhí)行順序是touchstart->touchmove->touchend->click。或者，使用fastclick或者zepto的tap事件代替click事件。「HTML的viewport設(shè)置」，可以防止頁面的縮放，來優(yōu)化性能。「開啟GPU渲染加速」，小伙伴們一定聽過CPU吧，但是這里的GPU不能和CPU混為一談呦。GPU的全名是Graphics Processing Unit，是一種硬件加速方式。一般的css渲染，瀏覽器的渲染引擎都不會使用到它。但是，在3D渲染時，計算量較大，繁重，瀏覽器會開啟顯卡的硬件加速來幫助完成這些操作。所以，我們這里可以使用css中的translateZ設(shè)定，來欺騙瀏覽器，讓其幫忙開啟GPU加速，加快渲染進程。

DOM部分的優(yōu)化，更多的是習慣。需要自己強制要求自己在開發(fā)過程中去注意這些規(guī)范。所以，這部分的內(nèi)容可以多關(guān)注一下，才能夠慢慢了解。同時，本人對于上述幾點的描述是概括性的。并沒有對其進行詳細的展開。因此，也要求你去細細的查閱Google呦。

數(shù)據(jù)，也可以說是前端優(yōu)化方面比較重要的一塊內(nèi)容。頁面與用戶的交互響應(yīng)，往往伴隨著數(shù)據(jù)交互，處理，以及ajax的異步請求等內(nèi)容。所以，我們也可以來聊聊這一塊的知識。首先是對于圖片數(shù)據(jù)的處理：

圖片加載處理：

圖片預(yù)加載

圖片懶加載

首屏加載時進度條的顯示

「圖片預(yù)加載」，預(yù)加載的寓意就是提前加載內(nèi)容。而圖片的預(yù)加載往往會被用在圖片資源比較大，即時加載時會導(dǎo)致很長的等待過程時，才會被使用的。常見場景：圖片漫畫展示時。往往會預(yù)加載一張到兩張的圖片。「圖片懶加載」，懶加載或許你是第一次聽說，但是，這種方式在開發(fā)中會被經(jīng)常使用。首先，我們需要明白一個道理：往往只有看到的資源是必須的，其他資源是可以隨著用戶的滾動，隨即顯示的。所以，特別是對于圖片資源特別多的網(wǎng)站來說，做好圖片的懶加載是可以大大提升網(wǎng)頁的載入速度的。

常見的圖片懶加載的方式就是：在最初給圖片的src設(shè)置一個比較簡單的圖片，然后將圖片的真實地址設(shè)置給自定義的屬性，做一個占位，然后給圖片設(shè)置監(jiān)聽事件，一旦圖片到達視口范圍，從圖片的自定義屬性中獲取出真是地址，然后賦值給src，讓其進行加載。

「首屏進度條的顯示」：往往對于首屏優(yōu)化后的數(shù)據(jù)量并不滿意的話，同時也不能進一步縮短首屏包的長度了，就可以使用進度條的方式，來提醒用戶進行等待。

講完了圖片這一塊數(shù)據(jù)資源的處理，往往我們需要去優(yōu)化一下異步請求這一部分的內(nèi)容。因為，異步的數(shù)據(jù)獲取也是前端不可分割的。這一部分我們也可以做一定的處理：

異步請求的優(yōu)化：

使用正常的json數(shù)據(jù)格式進行交互

部分常用數(shù)據(jù)的緩存

數(shù)據(jù)埋點和統(tǒng)計

「JSON交互」，JSON的數(shù)據(jù)格式輕巧，結(jié)構(gòu)簡單，往往可以大大優(yōu)化前后端的數(shù)據(jù)通信。「常用數(shù)據(jù)的緩存」，可以將一些用戶的基本信息等常用的信息做一個緩存，這樣可以保證ajax請求的減少。同時，HTML5新增的storage的內(nèi)容，也不用怕cookie暴露，引起的信息泄漏問題。「數(shù)據(jù)埋點和統(tǒng)計」，對于資深的程序員來說，比較了解。而且目前的大部分公司也會做這方面的處理。有心的小伙伴可以自行查閱。

最后，還有就是大量數(shù)據(jù)的運算。對于javascript語言來說，本身的單線程就限制了它并不能計算大量的數(shù)據(jù)，往往會造成頁面的卡頓。而可能業(yè)務(wù)中有些復(fù)雜的UI需要去運行大量的運算，所以，webWorker的使用是至關(guān)重要的。或許，前端標準普及的落后，會導(dǎo)致大家對于這些新生事物的短暫缺失吧。

本篇文章就前端性能這個話題做了一個總結(jié)。或許，并不全面，但是都是一些平時開發(fā)中會被經(jīng)常用到的知識。希望有心者能夠去親身的嘗試一下這些方面的優(yōu)化。本篇的概述了一下幾個知識點：

網(wǎng)絡(luò)層面的優(yōu)化

數(shù)據(jù)層面的優(yōu)化

DOM操作與渲染層面的優(yōu)化

如果你對我寫的有疑問，可以評論，如我寫的有錯誤，歡迎指正。你喜歡我的博客，請給我關(guān)注Star~呦。大家一起總結(jié)一起進步。歡迎關(guān)注我的github博客