網站性能優化——DNS預熱與合併HTTP請求

DNS預熱

一次DNS解析耗時 20-120ms, 當網頁中使用的域名較多時，DNS預熱節省的時間仍是很是可觀的

先看效果

預熱的目的：

1. 減小請求次數
2. 提早對DNS預獲取

預熱的方式

1. 爬蟲
2. APP
3. 網頁meta

<meta http-equiv="x-dns-prefetch-control" content="on" />
    <link rel="dns-prefetch" href="//webresource.english.c-ctrip.com" />
    <link rel="dns-prefetch" href="//webresource.c-ctrip.com" />
    <link rel="dns-prefetch" href="//s.c-ctrip.com" />
    <link rel="dns-prefetch" href="//pic.english.c-ctrip.com" />
    <link rel="dns-prefetch" href="//m.ctrip.com" />

另外，對於國際化站點尤爲須要這麼作，舉個例子，在美國訪問中國的網站，DNS解析會回源到中國，耗時一般在 400ms至 800ms，甚至更長，若是提早預熱，那麼能夠節省這些時間。

合併HTTP請求

這裏的合併主要針對當前頁面上訪問的資源文件，好比css,js,圖片等。

爲甚麼要合併請求？

有人會很奇怪，現代瀏覽器均可以併發請求資源了，爲何還要這麼作？我只能說你還too young too simple了。瀏覽器雖然能夠併發，可是PC接入互聯網的帶寬是有限的，瀏覽器所能用的TCP連接更是有限的，我來看一個網頁請求的實例：

看到了吧，一個2KB的資源加載須要將近0.5s，而99%時間是等待, OMG! 因此還掙扎什麼，老老實實的用webpack壓在一塊兒吧。

注意chrome在http和https下相同域名能夠併發的請求數不一樣：http = 6，https > 13，這裏併發是有至關的水分，從上圖中能夠看出，連接雖然創建了，但並沒什麼卵用，依然要等待以前的資源下載下來纔開始生效，至於瀏覽器爲啥要這般？（誰知道能夠留言告知，萬分感謝！）

更多參考

• 瀏覽器請求靜態資源的併發數