摘要：前端性能優化總結資源優化緩存最好的資源優化就是不加載資源。緩存主要分為強制緩存和協商緩存。的值為服務端返回的數據到期時間。的使用教程為了保證正常的，有些渲染性能優化還是有必要的。

最好的資源優化就是不加載資源。緩存也是最見效的優化手段。說實話，雖然說客戶端緩存發生在瀏覽器端，但緩存主要還是服務端來控制，與我們前端關系并不是很大。但還是有必要了解一下。

緩存包括服務端緩存和客戶端緩存，本文只談客戶端緩存。所謂客戶端緩存主要是http緩存。http緩存主要分為強制緩存和協商緩存。

Expires（http1.0）

在http1.0中使用Expires來做強制緩存。Exprires的值為服務端返回的數據到期時間。當再次請求時的請求時間小于返回的此時間，則直接使用緩存數據。但由于服務端時間和客戶端時間可能有誤差，這也將導致緩存命中的誤差。

Cache-Control

Cache-Control有很多屬性，不同的屬性代表的意義也不同。

private：客戶端可以緩存

public：客戶端和代理服務器都可以緩存

max-age=t：緩存內容將在t秒后失效

no-cache：需要使用協商緩存來驗證緩存數據

no-store：所有內容都不會緩存。

瀏覽器第一次請求數據時，服務器會將緩存標識與數據一起響應給客戶端，客戶端將它們備份至緩存中。再次請求時，客戶端會將緩存中的標識發送給服務器，服務器根據此標識判斷。若未失效，返回304狀態碼，瀏覽器拿到此狀態碼就可以直接使用緩存數據了。

Last-Modified

服務器在響應請求時，會告訴瀏覽器資源的最后修改時間

if-Modified-Since

瀏覽器再次請求服務器的時候，請求頭會包含此字段，后面跟著在緩存中獲得的Last-Modified（最后修改時間）。服務端收到此請求頭發現有if-Modified-Since，則與被請求資源的最后修改時間進行對比，如果大于被請求資源最后修改時間則返回304，瀏覽器從緩存獲取資源。如果小于被請求資源最后修改時間，則返回200，并返回最新資源，瀏覽器從服務端獲取最新的資源，并緩存。

Etag

由服務器生成的每個資源的唯一標識字符串

If-None-Match

再次請求服務器時，瀏覽器的請求報文頭部會包含此字段，后面的值為在緩存中獲取的標識。服務器接收到次報文后發現If-None-Match則與被請求資源的唯一標識進行對比。如果相同，說明資源沒有被修改過，返回304，瀏覽器從緩存獲取資源，如果不同說明資源被修改過，則返回200，并返回最新資源，瀏覽器從服務端獲取最新資源，并緩存。

Last-Modified與ETag是可以一起使用的，服務器會優先驗證ETag，一致的情況下，才會繼續比對Last-Modified，最后才決定是否返回304。

如果使用前端打包工具，可以在打包文件時候在給文件添加版本號或者hash值，同樣可以區分資源是否過期。

使用CDN托管靜態資源

可以借助gulp、webpack等打包工具對js、css等文件合并與壓縮

圖片懶加載、按需加載，當滾動到圖片可視區域才去加載圖片

小圖片并且基本不會改動的圖片使用base64編碼傳輸。base64不要濫用，即使小圖片經過base64編碼之后也會生成很長的字符串，如果濫用base64反而會適得其反

雪碧圖，這個也是針對基本不會更改的圖片才使用雪碧圖，因為如果一張圖片修改，會導致整個雪碧圖重新生成，如果亂用也會適得其反。

借助webpack、gulp等工具壓縮資源

服務端開啟gzip壓縮（壓縮率非常可觀，一般都在30%之上）

如果有用打包工具，打包優化要做好，公共資源、提取第三方代碼、不需要打包的庫...

讀過前面js運行機制的應該知道，從瀏覽器輸入url，到頁面出現在屏幕上，都發生了哪些事（tcp握手、dns解析等不在認知范圍）。

FPS 16ms 小于10ms完成最好 Google devtool 查看幀率

如果瀏覽器FPS到達60，就會顯得比較流暢，大多數顯示器的刷新頻率是60Hz，瀏覽器會自動按照這個頻率刷新動畫。
按照FPS等于60來計算，平均一幀的時間為1000ms/60 = 16.7ms，所以每次渲染時間不能超過16ms，如果超過這個時間就會出現丟幀、卡頓現象。

可以在chrome瀏覽器開發者工具中的Timeline中查看刷新率，可以查看所有幀率耗時情況以及某一幀的執行情況。Timeline的使用教程：https://segmentfault.com/a/11...

為了保證正常的FPS，有些渲染性能優化還是有必要的。下面所介紹的都是有關渲染優化的策略。

盡量使用css3來做動畫

總所周知，css的性能要比js快，所以能使用css，盡量不用js來實現

避免使用setTimeout或setInterval，盡量使用requestAnimationFrame來做動畫或者高頻Dom操作。

因為setTimeout和setInterval無法保證callback函數的執行時機，很可能在幀結束的時候執行，從而導致丟幀，但是requestAnimationFrame可以保證callback函數在每幀動畫開始的時候執行
requestAnimationFrame的中文MDN地址：https://developer.mozilla.org...

復雜的計算操作使用Web Workers

如果有需要復雜的數據操作，比如對一個有一個個元素的數組遍歷求和，那么Web Workers在適合不過了。

Web Workers可以讓JavaScript腳本運行在后臺線程（類似于創建一個子線程），而后臺線程不會影響到主線程中的頁面。不過，使用Web Workers創建的線程是不能操作DOM樹。
有關Web Workers的更多可以查看MDN詳解：https://developer.mozilla.org...

css放在頭部，js放在尾部。

讀過前面js運行機制的應該知道頁面渲染是怎樣一個過程，不再贅述了。css放在頭部會避免生成html樹之后重新布局的閃屏現象，js一般對頁面的影響較大，一般放在尾部最后執行。

事件防抖（debounce）與節流（throttle）

針對高頻觸發的事件（mousemove、scroll）等事件，如果不加以控制會在短時間內觸發很多事件。

函數防抖是指頻繁觸發的情況下，只有足夠的空閑時間，才執行代碼一次。場景：注冊時郵箱的輸入框，隨著用戶的輸入，實時判斷郵箱格式是否正確，當第一次輸入事件觸發，設置定時：在800ms之后執行檢查。假如只過了100ms，上次的定時還沒執行，此時清除定時，重新定時800ms。直到最近一次的輸入，后面沒有緊鄰的輸入了，這最近一次的輸入定時計時結束，終于執行了檢查代碼。

const filter  = /^([a-zA-Z0-9_.-])+@(([a-zA-Z0-9-])+.)+([a-zA-Z0-9]{2,4})+$/;  
$("#email").on("keyup",checkEmail());  
function checkEmail(){  
    let timer=null;  
    return function (){  
        clearTimeout(timer);  
        timer=setTimeout(function(){  
            console.log("執行檢查");  
        },800);  
    }  
}  

函數節流是指一定時間內js方法只跑一次。就是本來一秒要執行100次的變成一秒執行10次。
場景：函數節流應用的實際場景，多數在監聽頁面元素滾動事件的時候會用到。

var canRun = true;
document.getElementById("throttle").onscroll = function(){
    if(!canRun){
        // 判斷是否已空閑，如果在執行中，則直接return
        return;
    }

    canRun = false;
    setTimeout(function(){
        console.log("函數節流");
        canRun = true;
    }, 300);
};

Dom操作

前端開發人員都知道Do操作是非常耗時的（曾親測過30*30的表格遍歷添加樣式）。所以盡量避免頻繁的Dom操作，如果避免不了就盡量對DOm操作做優化。

1.：緩存Dom查詢，比如通過getElementByTagName("div")獲取Dom集，而不是逐個獲取。

2： 合并Dom操作，使用createDocumentFragment()

    var frag = document.createDocumentFragment()
    for (i<10) {
        var li = document.createElement("li")
        frag.appendChild(li)
    }
    document.body.appendChild(frag)

 3： 使用React、Vue等框架的虛擬dom（原理目前還不明白），可以更快的實現dom操作。

盡量避免重繪（rePaint）和回流（reFlow）

如果使用js修改元素的顏色或者背景色就會觸發重繪，重繪的開銷還是比較昂貴的，因為瀏覽器會在某一個DOM元素的視覺效果改變后去check這個DOM元素內的所有節點。

如果修改元素的尺寸和位置就會發生回流，回流開銷更大，它會在某一個DOM元素的位置發生改變后觸發，而且它會重新計算所有元素的位置和在頁面中的占有的面積，這樣的話將會引起頁面某一個部分甚至整個頁面的重新渲染。

css3硬件加速

瀏覽器渲染時，會分為兩個圖層：普通圖層和復合圖層。

普通文檔流內可以理解為一個復合圖層，absolute、fixed布局雖然可以脫離普通文檔流，但它仍然屬于普通圖層，不會啟動硬件加速。上面說的重繪（rePaint）和回流（reFlow）說的就是普通圖層上的重繪和回流。

復合圖層會啟動硬件加速。和普通圖層不在同一個圖層，所以復合圖層不會影響普通圖層，如果一個元素被提升到復合圖層，再操作該元素時，就不會引起普通圖層的重繪和回流，從而提升渲染性能。

如何啟動硬件加速：

1.使用translate3d和translateZ

webkit-transform: translateZ(0);
-moz-transform: translateZ(0);
-ms-transform: translateZ(0);
-o-transform: translateZ(0);
transform: translateZ(0);

webkit-transform: translate3d(0,0,0);
-moz-transform: translate3d(0,0,0);
-ms-transform: translate3d(0,0,0);
-o-transform: translate3d(0,0,0);
transform: translate3d(0,0,0);

2.使用opacity
需要動畫執行的過程中才會創建合成層，動畫沒有開始或結束后元素還會回到之前的狀態

3.使用will-chang屬性
這個屬性比較不常用，一般配合opacity與translate使用

針對webkit瀏覽器，啟用硬件加速有些時候可能會導致瀏覽器頻繁閃爍或抖動，可以使用下面方法消除：

-webkit-backface-visibility:hidden;
-webkit-perspective:1000;

如果使用硬件加速，請使用z-index配合使用， 因為如果這個元素添加了硬件加速，并且index層級比較低， 那么在這個元素的后面其它元素（層級比這個元素高的，或者相同的，并且releative或absolute屬性相同的）， 會默認變為復合層渲染，如果處理不當會極大的影響性能

避免強制同步布局和布局抖動

瀏覽器渲染過程為：js/css(javascript) > 計算樣式(style) > 布局(layout) > 繪制(paint) > 渲染合并圖層（Composite）

JavaScript：JavaScript實現動畫效果，DOM元素操作等。
Style（計算樣式）：確定每個DOM元素應該應用什么CSS規則。
Layout（布局）：計算每個DOM元素在最終屏幕上顯示的大小和位置。
Paint（繪制）：在多個層上繪制DOM元素的的文字、顏色、圖像、邊框和陰影等。
Composite（渲染層合并）：按照合理的順序合并圖層然后顯示到屏幕上。

在js中如果讀取style屬性的某些值就會讓瀏覽器強行進行一次布局、計算，然后再返回值，比如：

offsetTop, offsetLeft, offsetWidth, offsetHeight

scrollTop/Left/Width/Height

clientTop/Left/Width/Height

width,height

請求了getComputedStyle(), 或者 IE的 currentStyle

所以，如果強制瀏覽器在執行JavaScript腳本之前先執行布局過程，這就是所謂的強制同步布局。
比如下面代碼：

requestAnimationFrame(logBoxHeight);

// 先寫后讀，觸發強制布局
function logBoxHeight() {
    // 更新box樣式
    box.classList.add("super-big");

    // 為了返回box的offersetHeight值
    // 瀏覽器必須先應用屬性修改，接著執行布局過程
    console.log(box.offsetHeight);
}

// 先讀后寫，避免強制布局
function logBoxHeight() {
    // 獲取box.offsetHeight
    console.log(box.offsetHeight);

    // 更新box樣式
    box.classList.add("super-big");
}

在JavaScript腳本運行的時候，它能獲取到的元素樣式屬性值都是上一幀畫面的，都是舊的值。因此，如果你在當前幀獲取屬性之前又對元素節點有改動，那就會導致瀏覽器必須先應用屬性修改，結果執行布局過程，最后再執行JavaScript邏輯。

如果連續多次強制同步布局，就會導致布局抖動
比如下面代碼：

function resizeAllParagraphsToMatchBlockWidth() {
  for (var i = 0; i < paragraphs.length; i++) {
    paragraphs[i].style.width = box.offsetWidth + "px";
  }
}

作者：SylvanasSun
鏈接：https://juejin.im/post/59da456951882525ed2b706d
來源：掘金
著作權歸作者所有。商業轉載請聯系作者獲得授權，非商業轉載請注明出處。

我們知道瀏覽器是一幀一幀的刷新頁面的，對于每一幀，上一幀的布局信息都是已知的。
強制布局就是使用js強制瀏覽器提前布局，比如下面代碼：

// bed  每次循環都要去獲取left ，就會發生一次回流
function logBoxHeight() {
  box.style.left += 10
  console.log(box.style.left)
}

// goog 
var width = box.offsetWidth;

function resizeAllParagraphsToMatchBlockWidth() {
  for (var i = 0; i < paragraphs.length; i++) {
    // Now write.
    paragraphs[i].style.width = width + "px";
  }
}

DOMContentLoaded與Load

DOMContentLoaded 事件觸發時，僅當DOM加載完成才觸發DOMContentLoaded，此時樣式表，圖片，外部引入資源都還沒加載。而load是等所有的資源加載完畢才會觸發。

1. 解析HTML結構。
2. 加載外部腳本和樣式表文件。
3. 解析并執行腳本代碼。
4. DOM樹構建完成。//DOMContentLoaded
5. 加載圖片等外部文件。
頁面加載完畢。//load

視覺優化

等待加載時間可以合理使用loading gif動圖一定程度上消除用戶等待時間的煩躁感

代碼對性能的影響可大可小，但是養成一個良好的寫代碼習慣和高質量的代碼，會潛移默化的提高性能，同時也能提高自己的水平。廢話不多說，直接看我總結的部分要點（因為這一部分知識點太多，需要大家寫代碼的時候多多總結）。

避免全局查找

訪問局部變量會比訪問全局變量快，因為js查找變量的時候現在局部作用局查找，找不到在逐級向上找。

// bad
function f () {
    for (...){
        console.log(window.location.href)
    }
}

//good
function f () {
    var href = window.location.href
    for (...){
        console.log(href)
    }
}

循環技巧

// bed 
for(var i = 0; i < array.length; i++){
    ....
}
// good
for(var i = 0, len = array.length; i < len; i++){
    ....
}
// 不用每次查詢長度

不要使用for in 遍歷數組

for in是最慢的，其他的都差不多，其中直接使用for循環是最快的。for in只是適合用來遍歷對象。

使用+""代替String()吧變量轉化為字符串

var a = 12
//bad
a = String(a)

// good
var a = 12
a = a + ""

這個還有很多類似的，比如使用*1代替parseInt()等都是利用js的弱類型，其實這樣對性能提升不是很大，網上有人測試過，進行十幾萬次變量轉換，才快了零點幾秒。

刪除dom

刪除dom元素要刪除注冊在該節點上的事件，否則就會產生無法回收的內存，在選擇removeChild和innerHTML=""二者之間盡量選擇后者，據說removeChild有時候無法有效的釋放節點（具體原因不明）

使用事件代理處理事件

任何可以冒泡的事件都可以在節點的祖先節點上處理，這樣對于子節點需要綁定相同事件的情況就不用分別給每個子節點添加事件監聽，而是都提升到祖先節點處理。

通過js生成的dom對象必須append到頁面中

在IE下，js創建的額dom如果沒有添加到頁面，這部分內存是不會被回收的

避免與null比較

可以使用下面方法替換與null比較
1.如果該值為引用類型，則使用instanceof檢查其構造函數
2.如果該值為基本類型，使用typeof檢查類型

盡量使用三目運算符代替if else

if(a>b){num = a}
else{num = b}

// 可以替換為
num = a > b ? a : b

當判斷條件大于3中情況時，使用switch代替if

因為switch的執行速度比if要快，也別是在IE下，速度大約是if的兩倍

先總結這么多，其實性能優化還有很多，像預加載、服務端渲染、css選擇器優化等等。等有機會再總結