書本開片就闡述了一個(gè)很重要的定理：速度是關(guān)鍵
在互聯(lián)網(wǎng)飛速發(fā)展的時(shí)代，人們有非常多的選擇，大家變的沒不那么有耐心了，人們越來越追求速度方面的用戶體驗(yàn)。WPO（Web Performance Optimization。web性能用優(yōu)化）是越來越越多的前端開發(fā)所關(guān)注的事情。
本書概述了網(wǎng)絡(luò)技術(shù)，無線網(wǎng)絡(luò)性能，HTTP，瀏覽器API與協(xié)議，從底層上告訴用戶Web優(yōu)化的原理。
造成web緩慢罪魁禍?zhǔn)资?strong>延遲。這里的延遲指的是消息從起點(diǎn)到終點(diǎn)經(jīng)歷的時(shí)間。這個(gè)定義很簡單，但是造成延遲的原因很多，任何系統(tǒng)都有可能造成影響傳輸消息的時(shí)間。因此，弄清楚這個(gè)因素是什么，是Web性能優(yōu)化提高的關(guān)鍵。
延遲分為下面幾種延遲
1.傳播延遲（從發(fā)送端發(fā)送數(shù)據(jù)開始，到接收端接收到數(shù)據(jù)所經(jīng)過的時(shí)間）
2.傳輸延遲（將消息中的所有比特從發(fā)送到全部轉(zhuǎn)移到接收端所用的時(shí)間）
3.處理延遲（處理分組首部，檢查位錯(cuò)誤及確定分組目標(biāo)所需要的時(shí)間。）
4.排隊(duì)延遲（到來的分組排隊(duì)等待處理時(shí)間）
我們在瀏覽器的地址欄輸入U(xiǎn)RL地址，然后按下回車，然后得到了我們想要的網(wǎng)址，那么問題來了！
在這個(gè)過程中瀏覽器替我們做了什么？
1.瀏覽器會檢查本地是否有緩存或則web緩存，如果有緩存就直接取緩存。
2.在沒有緩存的情況下瀏覽器會根據(jù)域名進(jìn)行DNS解析，將域名解析成服務(wù)器的IP地址，從而得到目標(biāo)IP（這個(gè)步驟耗時(shí)客場可長可短，特別是第一次DNS解析時(shí)特別長，后面本地都會緩存DNS，下次請求就會直接調(diào)用它。）
3.有了IP地址之后，瀏覽器向客戶端與服務(wù)器會有三次TCP握手（這里會消耗比較長的時(shí)間，每次傳輸信息都要啟動(dòng)一次TCP的鏈接，而每次TCP鏈接都要付出很高的代價(jià)），最后形成一條客戶端端口到服務(wù)器端口的一條TCP鏈接。
4.TCP鏈接成立后，瀏覽器就可以向服務(wù)器發(fā)送http請求，服務(wù)器響應(yīng)，將客戶端需要信息返回給瀏覽器。
5.瀏覽器得到資源后，開始渲染頁面。瀏覽器在解析HTML文檔的基礎(chǔ)上構(gòu)建DOM，與此同時(shí)，還有一個(gè)常常被忽略的模型--CSSOM，也會基于特定的樣式表規(guī)則和資源構(gòu)建而成。這兩個(gè)模型共同創(chuàng)建”渲染樹”，瀏覽器根據(jù)這個(gè)渲染樹，去布局頁面和并在屏幕上繪制圖形，最終成為一個(gè)新的頁面展示給大家。
在瀏覽器敲擊url 到得到整個(gè)頁面我需要多長時(shí)間呢？
總時(shí)間 = DNS解析時(shí)間 + 建立TCP鏈接時(shí)間 + 發(fā)送http并得到響應(yīng)的時(shí)間 +頁面渲染時(shí)間。
一切看起來十分的明朗，其實(shí)卻有非常多的坑。
坑一：DNS解析是需要花時(shí)間的，如果頁面上的域名多，那么DNS解析查詢就花費(fèi)時(shí)間越多，所以頁面上的域名越少，解析域名的時(shí)間也就越少，那有同學(xué)就問了，就用一個(gè)域名不就好了嘛 ? 不行！http請求也有個(gè)毛病，在一個(gè)TCP連接中，只有一個(gè)http請求，而客戶端最多能夠并發(fā)打開六個(gè)TCP鏈接，服務(wù)器也只能同時(shí)處理最多處理六個(gè)請求。當(dāng)服務(wù)器同時(shí)接收到六個(gè)a,b,c,d,e,f http請求，其中a的請求處理最長時(shí)間但他是第一個(gè)處理的，然后服務(wù)器再并行處理bcdef五個(gè)請求，這個(gè)五個(gè)請求很快完成了處理，但a還沒處理完，這個(gè)時(shí)候服務(wù)器把后面五個(gè)先處理完成的先緩沖起來，等a處理完并發(fā)送響應(yīng)后，再發(fā)送bcdef的響應(yīng)。這樣本來bcdef可以早早響應(yīng)，卻因?yàn)閍的原因而被堵在哪。造成了時(shí)間浪費(fèi)，所以解決方法就是域名分區(qū)，減少服務(wù)器并行的處理。但說好了減少頁面域名的呢？這個(gè)就需要開發(fā)們在這里面權(quán)衡了。
坑二：我們可以把TCP想象成一個(gè)管道，http是里面的流水，流水有兩種狀態(tài)，客戶端流向服務(wù)器，服務(wù)器流向客戶端。所以這里面就有幾種局限，首先客戶端發(fā)起請求后，服務(wù)器才能應(yīng)答，把需要的東西發(fā)給客戶端。那么每次請求都會是一次耗時(shí)的過程。就像我們向產(chǎn)品要資源一樣，我們打電話給產(chǎn)品，產(chǎn)品接電話，知道我需要一個(gè)重構(gòu)稿，然后打開rtx發(fā)給我，后來我又打電話給產(chǎn)品，產(chǎn)品接電話，知道我需要一個(gè)分享圖片，然后打開rtx發(fā)給我。 而我做了很多重復(fù)的事情，我多打了一次電話，算上等待產(chǎn)品接電話的時(shí)間，再加上產(chǎn)品多打開了一次rtx的時(shí)間。時(shí)間在大量的浪費(fèi)，多做了許多事情。所以減少打電話的時(shí)間，資源能夠一次拿完的就一次拿完。同理，頁面的http請求越少越好，每一次的http請求都是耗時(shí)的。而在頁面上，每一個(gè)js文件，css文件，圖片文件都是一條http請求。所以合并js，合并css，合并圖片為雪碧圖，減少http請求。
坑三：頁面的渲染的過程就是，DOM和CSSOM一起將頁面渲染出來。但是這個(gè)時(shí)候有個(gè)搗亂家伙出現(xiàn)了，javascript出現(xiàn)了，腳本執(zhí)行過程對dom節(jié)點(diǎn)的操作會堵塞DOM的解析和構(gòu)建，類似的js查詢對象的計(jì)算樣式，也會阻塞css的渲染。結(jié)果出現(xiàn)了js還沒執(zhí)行完成DOM是無法構(gòu)建成功的，而js在CSSDOM構(gòu)建完成之前，也是無法進(jìn)行的，這樣就造成了頁面的堵塞。所以必須讓css以最快的速度下完，css發(fā)到頁面最上面，而js放到頁面最下面。
優(yōu)化建議：
1.減少http請求，將js合并，css合成，圖片做成雪碧圖。考慮小資源（base64編碼）嵌入頁面（坑二有說明）；
2.適當(dāng)?shù)挠蛎謪^(qū)，介紹http求情堵塞的情況（坑一有說明）。
3.添加Expire/Cache-Control頭。給瀏覽器一個(gè)時(shí)間和一個(gè)判斷：即在一段時(shí)間內(nèi)，如果服務(wù)器端的內(nèi)容沒有更新，客戶端在請求時(shí)就直接使用緩存數(shù)據(jù)，而不請求服務(wù)器內(nèi)容。一般應(yīng)用中，我們對靜態(tài)內(nèi)容添加Expires，對動(dòng)態(tài)內(nèi)容設(shè)置Cache-Control。當(dāng)然，假設(shè)兩者均設(shè)置為時(shí)間常數(shù)的話，前者會被后者覆蓋掉
4.將css放在頁面最上面（坑三有說明）瀏覽器解析html的過程：獲取html文檔及樣式表文件；構(gòu)建dom樹和css樹。每當(dāng)有一個(gè)新元素加入dom樹，瀏覽器就會通過css選擇器查遍css樣式表，找到符合該元素的樣式應(yīng)用在這個(gè)元素上面，形成render tree。而瀏覽器對標(biāo)簽的解析是從上到下的，所以css出現(xiàn)的越早越好啊。
5.將js放在頁面最下面假 設(shè)我們不把script標(biāo)簽放在最后面，不給標(biāo)簽設(shè)置defer、async屬性，頁面解析時(shí)候遇見script標(biāo)簽時(shí)候，瀏覽器會這么做：停止渲染，轉(zhuǎn)而發(fā)起請求下載這個(gè).js文件（耗時(shí)一），下載完之后，會執(zhí)行這個(gè).js文件（耗時(shí)二），一共是兩個(gè)耗時(shí)過程。而在這個(gè)過程中，頁面窗口的狀態(tài)是兩個(gè)字：白板！但是假如我們添加了defer、async屬性，瀏覽器會怎么做呢？
遇見defer立刻下載文件，但是不阻塞后續(xù)dom渲染。當(dāng)dom渲染結(jié)束后，立即執(zhí)行該文件。而且js文件的執(zhí)行是按順序執(zhí)行的，相互之間的依賴還在。
遇見async立即下載文件并且執(zhí)行，而且也不阻塞后續(xù)dom渲染。但是有個(gè)不好的副作用：假設(shè)相鄰的a，b兩個(gè)js文件，a很大b很小，b依賴”下載并執(zhí)行“過程發(fā)生之后，應(yīng)該會造成亂序的后果。
看得出來，即使加了defer、async屬性，也改變不了js文件立即下載的特性。那為了克服這個(gè)問題，就把js丟到文檔最后吧。盡快解析dom呈現(xiàn)內(nèi)容給用戶才是王道！
6.壓縮css和js代碼。
7.避免重定向。
作者：半吊子程序員鏈接：http://www.lxweimin.com/p/ea48ac2a5edb來源：簡書著作權(quán)歸作者所有。商業(yè)轉(zhuǎn)載請聯(lián)系作者獲得授權(quán)，非商業(yè)轉(zhuǎn)載請注明出處。
