DNS預熱
一次DNS解析耗時
20-120ms, 當網頁中使用的域名較多時，DNS預熱節省的時間還是非常可觀的
先看效果
預熱的目的：
- 減少請求次數
- 提前對DNS預獲取
如何做到以上兩點
我們來看下DNS的解析流程：瀏覽器快取-系統快取-路由器快取-ISP DNS快取-DNS源伺服器，如下圖：
從圖中我們看出，當我們訪問過一次域名之後，就會在每個節點上生成DNS快取，即完成DNS預熱，這樣同一地區（或網路服務商）的其他使用者再次訪問該域名時就不需要重新回源，直接讀取最近的DNS快取，從而減少請求次數，提升了網站訪問速度。
預熱的方式
- 爬蟲
- APP
- 網頁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，這裡併發是有相當的水分，從上圖中可以看出，連結雖然建立了，但並沒什麼卵用，依然要等待之前的資源下載下來才開始生效，至於瀏覽器為啥要這般？（誰知道可以留言告知，萬分感謝！）