性能黃金法則：只有10%～20%的最終用戶響應(yīng)時(shí)間花在了下載HTML文檔上。其余的80%～90%時(shí)間花在了下載頁面中的所有組件上。
通過網(wǎng)絡(luò)層面去優(yōu)化這80%～90%的下載組件時(shí)間，比優(yōu)化代碼帶來的效果要好得多。實(shí)際操作也并不困難，你可以通過使用CDN、Keep-Alive、減少DNS查找、避免重定向和使用HTTP2來優(yōu)化你的網(wǎng)站的網(wǎng)絡(luò)訪問。
1. CDN
CDN現(xiàn)在已經(jīng)是網(wǎng)站開發(fā)的標(biāo)配。大公司都是自建CDN，小公司則使用CDN服務(wù)提供商（如：七牛云、又拍云等）或者免費(fèi)的CDN服務(wù)（如：BootCDN、360CDN等）。
CDN用于發(fā)布靜態(tài)內(nèi)容，如圖片、腳本、樣式表和Flash等。提供動(dòng)態(tài)HTML頁面會(huì)引入特殊的存儲(chǔ)需求，如數(shù)據(jù)庫連接、狀態(tài)管理、驗(yàn)證、硬件和OS優(yōu)化等。這些復(fù)雜性超越了CDN的能力范圍。
2. 減少HTTP請(qǐng)求
最快的請(qǐng)求就是沒有請(qǐng)求。減少HTTP請(qǐng)求，本質(zhì)上就是減少組件的數(shù)量。對(duì)于絕大多數(shù)網(wǎng)站，組件就是JS文件、CSS文件和圖片。你可以通過打包構(gòu)建工具，把所有JS文件打包成一個(gè)文件，CSS打包成一個(gè)文件，這就大大減少了請(qǐng)求的數(shù)量（事實(shí)上，現(xiàn)在很多的SPA就是這么做的）。減少圖片請(qǐng)求就是 CSS Sprite，將小圖標(biāo)和圖片合并成一個(gè)文件，不僅圖片總大小會(huì)減少，請(qǐng)求也大大減少了。
此外，使用SVG技術(shù)和內(nèi)聯(lián)圖片也可以減少請(qǐng)求的數(shù)量。但是你必須清楚自己在做什么，因?yàn)?strong>SVG圖片和內(nèi)聯(lián)圖片是無法緩存的，所以只有在用到一次的場景下使用。此外，對(duì)于簡單的圖片樣式和背景，你甚至可以直接用CSS3做出來（CSS3真的很強(qiáng)大，強(qiáng)大到超乎你的想象）。關(guān)于圖片的優(yōu)化，我會(huì)在《高性能網(wǎng)站：圖片篇》做更加詳細(xì)的介紹。
3. 減少DNS查找
我們知道，瀏覽器在單個(gè)域名下可以并發(fā)的請(qǐng)求數(shù)4～8個(gè)。不同瀏覽器可并發(fā)請(qǐng)求數(shù)量不同，并且HTTP/1.0和HTTP/1.1下同一瀏覽器可并發(fā)請(qǐng)求數(shù)也不同，但你必須知道，可以通過將資源分布在不同域名下，能夠增加并發(fā)請(qǐng)求的數(shù)量。
但是域名數(shù)量多了，響應(yīng)的DNS查找時(shí)間也就上去了（盡管有DNS緩存）。一般來說，DNS查找時(shí)間在10ms~100ms之間。我的建議是將你的資源分別放到至少2個(gè)，但不要超過4個(gè)主機(jī)名下。這是在減少DNS查找和允許高度并行下載之間作出的很好的權(quán)衡。
4. Keep-Alive
我們知道HTTP協(xié)議是底層是基于TCP協(xié)議，而建立TCP連接的三次握手和斷開連接的四次揮手是非常消耗時(shí)間的。Web客戶端經(jīng)常會(huì)打開到同一個(gè)站點(diǎn)的連接。比如，一個(gè)Web頁面上的大部分內(nèi)嵌圖片通常來自同一個(gè)Web站點(diǎn)，而且相當(dāng)一部分指向其他對(duì)象的超鏈通常都指向同一個(gè)站點(diǎn)。因此，初始化了對(duì)某服務(wù)器HTTP請(qǐng)求的應(yīng)用程序很可能會(huì)在不久的將來對(duì)那臺(tái)服務(wù)器發(fā)起更多的請(qǐng)求（比如，獲取在線圖片）。這種性質(zhì)被稱為站點(diǎn)局部性（site locality）。
關(guān)于Keep-Alive的更多信息，你可以參閱《HTTP權(quán)威指南》的第4.5節(jié)“持久連接”。我在這里要告訴你的是，很多的CDN和Web服務(wù)器會(huì)默認(rèn)幫你加上 Connection:keep-alive，所以你不必太擔(dān)心如何操作。此外，通過使用Keep-Alive重用現(xiàn)有連接還可以避免重復(fù)的DNS查找。
5. 避免重定向
實(shí)現(xiàn)重定向可能有很多不同的原因，包括但不限于網(wǎng)站重新設(shè)計(jì)、跟蹤流量、記錄廣告點(diǎn)擊和易于記憶的URL，但是請(qǐng)記住，重定向會(huì)使你的頁面變慢。
來看一個(gè)重定向的例子，訪問 http://toolbar.google.com 會(huì)發(fā)生302跳轉(zhuǎn)，在響應(yīng)主頁面之前有3秒的時(shí)間用戶將看不到頁面。當(dāng)然，因?yàn)槲沂褂昧舜硭圆胚@么慢，但是你要記住，重定向確實(shí)會(huì)在響應(yīng)實(shí)際頁面之前拖慢網(wǎng)站的速度，應(yīng)該避免。
如果是為了跟蹤流量，完全沒必要使用重定向。你可以分析Web服務(wù)器日志來跟蹤流量，或者使用信標(biāo)（beacon），它是一個(gè)HTTP請(qǐng)求，其URL中包含有跟蹤信息。跟蹤信息可以從信標(biāo)Web服務(wù)器的訪問日志中提取出來。信標(biāo)響應(yīng)通常是一個(gè) 1px X 1px 的透明圖片；不過204響應(yīng)更為優(yōu)秀，因?yàn)樗?、從來不?huì)被緩存，而且絕對(duì)不會(huì)改變?yōu)g覽器的狀態(tài)。
6. HTTP/2
HTTP/2 是基于Google SPDY協(xié)議，它的設(shè)計(jì)目標(biāo)是降低50%的頁面加載時(shí)間。當(dāng)下很多著名的互聯(lián)網(wǎng)公司，例如百度、淘寶、UPYUN 都在自己的網(wǎng)站或 APP 中采用了 SPDY 系列協(xié)議（當(dāng)前最新版本是 SPDY/3.1），因?yàn)樗鼘?duì)性能的提升是顯而易見的。主流的瀏覽器（谷歌、火狐、Opera）也都早已經(jīng)支持 SPDY，它已經(jīng)成為了工業(yè)標(biāo)準(zhǔn)，HTTP Working-Group 最終決定以 SPDY/2 為基礎(chǔ)，開發(fā) HTTP/2。
但是，HTTP/2 跟 SPDY 仍有不同的地方，主要是以下兩點(diǎn)：
相比 HTTP/1.x，HTTP/2 在底層傳輸做了很大的改動(dòng)和優(yōu)化：
- HTTP/2 采用二進(jìn)制格式傳輸數(shù)據(jù)，而非 HTTP/1.x 的文本格式。二進(jìn)制格式在協(xié)議的解析和優(yōu)化擴(kuò)展上帶來更多的優(yōu)勢和可能。
- HTTP/2 對(duì)消息頭采用 HPACK 進(jìn)行壓縮傳輸，能夠節(jié)省消息頭占用的網(wǎng)絡(luò)的流量。而 HTTP/1.x 每次請(qǐng)求，都會(huì)攜帶大量冗余頭信息，浪費(fèi)了很多帶寬資源。頭壓縮能夠很好的解決該問題。
- 多路復(fù)用，直白的說就是所有的請(qǐng)求都是通過一個(gè) TCP 連接并發(fā)完成。HTTP/1.x 雖然通過 pipeline 也能并發(fā)請(qǐng)求，但是多個(gè)請(qǐng)求之間的響應(yīng)會(huì)被阻塞的，所以 pipeline 至今也沒有被普及應(yīng)用，而 HTTP/2 做到了真正的并發(fā)請(qǐng)求。同時(shí)，流還支持優(yōu)先級(jí)和流量控制。
- Server Push：服務(wù)端能夠更快的把資源推送給客戶端。例如服務(wù)端可以主動(dòng)把 JS 和 CSS 文件推送給客戶端，而不需要客戶端解析 HTML 再發(fā)送這些請(qǐng)求。當(dāng)客戶端需要的時(shí)候，它已經(jīng)在客戶端了。
HTTP/2 主要是 HTTP/1.x 在底層傳輸機(jī)制上的完全重構(gòu)，HTTP/2 是基本兼容 HTTP/1.x 的語義的（詳細(xì)兼容性說明請(qǐng)戳 這里）。 Content-Type 仍然是 Content-Type，只不過它不再是文本傳輸了。
這些新特性真是好用到哭，任你窮盡奇技淫巧各種Hack，都比不上這歷史性的變革，這才是現(xiàn)代互聯(lián)網(wǎng)的協(xié)議。
下圖是 caniuse.com 給出的HTTP/2的瀏覽器支持列表，在全球支持率達(dá)到77.44%，在中國只有 59.58%。你可以根據(jù)你網(wǎng)站訪問用戶瀏覽器分布來考慮是否使用HTTP/2。
參考資料
- 《高性能網(wǎng)站建設(shè)指南》——Steve Souders
- 《HTTP權(quán)威指南》——David Gourley，Brian Totty
- HTTP/2 新特性淺析
