4.文件合并

 

從上圖可以看出不合并請求有以下缺點：

 

• 文件與文件之間有插入的上行請求，增加了N-1個網(wǎng)絡延遲

• 受丟包問題影響更嚴重

• keep-alive方式可能會出現(xiàn)狀況，經(jīng)過代理服務器時可能會被斷開，也就是說不能一直保持keep-alive的狀態(tài)

 

壓縮合并css和js可以減少網(wǎng)站http請求的次數(shù)，但合并文件可能會帶來問題:首屏渲染和緩存失效問題。那該如何處理這問題呢？—-公共庫合并和不同頁面的合并。

 

如何進行文件合并

 

1. 使用在線網(wǎng)站進行文件合并

2. 使用nodejs實現(xiàn)文件合并(gulp、fis3)

 

二、非核心代碼異步加載異步加載的方式

 

1、異步加載的方式

 

異步加載的三種方式——async和defer、動態(tài)腳本創(chuàng)建

 

① async方式

 

• async屬性是HTML5新增屬性，需要Chrome、FireFox、IE9+瀏覽器支持

• async屬性規(guī)定一旦腳本可用，則會異步執(zhí)行

• async屬性僅適用于外部腳本

• 如果是多個腳本，該方法不能保證腳本按順序執(zhí)行

 

<script type="text/javascript" src="xxx.js" async="async"></script>

 

② defer方式

 

• 兼容所有瀏覽器

• defer屬性規(guī)定是否對腳本執(zhí)行進行延遲，直到頁面加載為止

• 如果是多個腳本，該方法可以確保所有設置了defer屬性的腳本按順序執(zhí)行

• 如果腳本不會改變文檔的內(nèi)容，可將defer屬性加入到script標簽中，以便加快處理文檔的速度

 

③動態(tài)創(chuàng)建script標簽

在還沒定義defer和async前，異步加載的方式是動態(tài)創(chuàng)建script，通過window.onload方法確保頁面加載完畢再將script標簽插入到DOM中,具體代碼如下：

 

function addScriptTag(src){  

    var script = document.createElement('script');  

    script.setAttribute("type","text/javascript");  

    script.src = src;  

    document.body.appendChild(script);  

}  

window.onload = function(){  

    addScriptTag("js/index.js");  

}  

 

2、異步加載的區(qū)別

 

1)defer是在HTML解析完之后才會執(zhí)行，如果是多個，按照加載的順序依次執(zhí)行

 

2)async是在加載完之后立即執(zhí)行，如果是多個，執(zhí)行順序和加載順序無關

async和defer

 

其中藍色線代表網(wǎng)絡讀取，紅色線代表執(zhí)行時間，這倆都是針對腳本的；綠色線代表 HTML 解析。

 

三、利用瀏覽器緩存

 

對于web應用來說，緩存是提升頁面性能同時減少服務器壓力的利器。

 

瀏覽器緩存類型

 

1.強緩存：不會向服務器發(fā)送請求，直接從緩存中讀取資源，在chrome控制臺的network選項中可以看到該請求返回200的狀態(tài)碼，并且size顯示from disk cache或from memory cache；

 

相關的header:

Expires ：response header里的過期時間，瀏覽器再次加載資源時，如果在這個過期時間內(nèi)，則命中強緩存。它的值為一個絕對時間的GMT格式的時間字符串， 比如Expires:Thu,21 Jan 2018 23:39:02 GMT

 

Cache-Control ：這是一個相對時間，在配置緩存的時候，以秒為單位，用數(shù)值表示。當值設為max-age=300時，則代表在這個請求正確返回時間（瀏覽器也會記錄下來）的5分鐘內(nèi)再次加載資源，就會命中強緩存。比如Cache-Control:max-age=300，

 

簡單概括：其實這兩者差別不大，區(qū)別就在于 Expires 是http1.0的產(chǎn)物，Cache-Control是http1.1的產(chǎn)物，兩者同時存在的話，Cache-Control優(yōu)先級高于Expires；在某些不支持HTTP1.1的環(huán)境下，Expires就會發(fā)揮用處。所以Expires其實是過時的產(chǎn)物，現(xiàn)階段它的存在只是一種兼容性的寫法。強緩存判斷是否緩存的依據(jù)來自于是否超出某個時間或者某個時間段，而不關心服務器端文件是否已經(jīng)更新，這可能會導致加載文件不是服務器端最新的內(nèi)容，那我們?nèi)绾潍@知服務器端內(nèi)容較客戶端是否已經(jīng)發(fā)生了更新呢？此時我們需要協(xié)商緩存策略。

 

2.協(xié)商緩存：向服務器發(fā)送請求，服務器會根據(jù)這個請求的request header的一些參數(shù)來判斷是否命中協(xié)商緩存，如果命中，則返回304狀態(tài)碼并帶上新的response header通知瀏覽器從緩存中讀取資源；另外協(xié)商緩存需要與cache-control共同使用。

 

相關的header:

①Last-Modified和If-Modified-Since：當?shù)谝淮握埱筚Y源時，服務器將資源傳遞給客戶端時，會將資源最后更改的時間以“Last-Modified: GMT”的形式加在實體首部上一起返回給客戶端。

 

Last-Modified: Fri, 22 Jul 2016 01:47:00 GMT

 

客戶端會為資源標記上該信息，下次再次請求時，會把該信息附帶在請求報文中一并帶給服務器去做檢查，若傳遞的時間值與服務器上該資源最終修改時間是一致的，則說明該資源沒有被修改過，直接返回304狀態(tài)碼，內(nèi)容為空，這樣就節(jié)省了傳輸數(shù)據(jù)量 。如果兩個時間不一致，則服務器會發(fā)回該資源并返回200狀態(tài)碼，和第一次請求時類似。這樣保證不向客戶端重復發(fā)出資源，也保證當服務器有變化時，客戶端能夠得到最新的資源。一個304響應比一個靜態(tài)資源通常小得多，這樣就節(jié)省了網(wǎng)絡帶寬。