摘要：性能優(yōu)化追求的是什么是你的網(wǎng)頁(yè)可以以最快的速度打開(kāi)比如說(shuō)用戶(hù)點(diǎn)一下啪的就開(kāi)了點(diǎn)哪里哪里開(kāi)什么操作都是立刻有反饋關(guān)鍵字是速度試想未來(lái)有一天到了時(shí)代每個(gè)人的網(wǎng)速都是的那你還優(yōu)化什么你的網(wǎng)站就算是大小也不怕可是那是遙遠(yuǎn)的未來(lái)當(dāng)下網(wǎng)速還沒(méi)有這么快。

追求的是什么, 是你的網(wǎng)頁(yè)可以 以最快的速度 打開(kāi), 比如說(shuō)用戶(hù)點(diǎn)一下啪的就開(kāi)了
點(diǎn)哪里哪里開(kāi), 什么操作都是立刻有反饋.

關(guān)鍵字是:速度

試想未來(lái)有一天, 到了 18G 時(shí)代, 每個(gè)人的網(wǎng)速都是 1000M 的, 那你還優(yōu)化什么
你的網(wǎng)站就算是 100M 大小也不怕.

可是那是遙遠(yuǎn)的未來(lái), 當(dāng)下網(wǎng)速還沒(méi)有這么快。

所以我們的問(wèn)題是: 在一個(gè)比較低一點(diǎn)的網(wǎng)速上面, 盡可能的快的加載出來(lái)我們的頁(yè)面.

固定一個(gè)變量: 網(wǎng)速.

所以問(wèn)題變成: 在固定網(wǎng)速為 p 的條件下, 如何盡可能的讓我們的頁(yè)面快一點(diǎn)加載出來(lái).
假設(shè)我們的資源大小是 n, 網(wǎng)速為 p, 理論上將資源, 從服務(wù)器拿到客戶(hù)端需要的時(shí)間
是:

time = n/p

p 固定, 那么 n 越小, time 越小.
也就是說(shuō): 我們的資源的體積越小, 時(shí)間越短.

所以問(wèn)題變成: 如何減少我們資源的大小?
先說(shuō)我們的資源的種類(lèi)有哪些?

images
js
css
html
fonts
others

依次看看怎么減小它們的體積:

圖片壓縮
js 壓縮
css 壓縮
html 壓縮
fonts 刪減
others 不知道

這些都是建立在你當(dāng)前已經(jīng)存在的資源的上面, 還可以做預(yù)處理:

切圖的時(shí)候就不要切高清無(wú)碼圖

不要引入沒(méi)有必要的 js, 或者說(shuō)你為了兼容 Object.assign() 直接引了一個(gè) babel-polyfill這樣

不要閉著眼就把 bootstrap 引入進(jìn)來(lái)了
...

上面的討論, 實(shí)際上都是有一個(gè)前提的, 就是說(shuō):
所有的資源都從 server 到 client 之后, client 才能看見(jiàn)頁(yè)面

但是這并不是真的:
有時(shí)只要你拿回來(lái)一部分資源的時(shí)候, 頁(yè)面就可以顯示出來(lái)了.
所以我們可以對(duì)資源做一些區(qū)分, 將 "頁(yè)面顯示出來(lái)所需要的最小資源集合" 優(yōu)先返回回去,
剩下的資源再說(shuō), 這樣也是一種思路。

所以我們的問(wèn)題變成: 找到那個(gè)最小的資源集合, 或者說(shuō), 合理的安排資源的順序。
how?

依舊是那些資源類(lèi)型:

images
js
css
html
fonts
others

images 完全可以做懶加載, 不需要那么早就扔出去. 
第一次要展示的頁(yè)面是 pageA, 那么 pageB 相關(guān)的資源, 你就不要先返回啊.

這方面相關(guān)的一些概念是:

首屏渲染

按需加載

code spliting

critial css

...

其實(shí)這句話(huà)說(shuō)的好像是 server 去安排資源的順序一樣, 但是你也知道不是的, server說(shuō)我就是無(wú)腦
扔, 你自己安排。
所以我們才會(huì)去讓 link 提前加載, 讓 script 在后面加載.

上面算是第一個(gè)階段的結(jié)束, 現(xiàn)在我們更進(jìn)一步
前面說(shuō)了:

time = 資源大小 / 網(wǎng)速

實(shí)際上這個(gè)模型可以比喻成這樣:
小明從 A 點(diǎn)到 B 點(diǎn)拿一堆總重量為 100kg 的東西, 小明需要多久才能把東西全部從 B ->A?
和小明每次拿多少, 以及他一趟要多久相關(guān), 是不是?
所以上面提及到的 "網(wǎng)速" 這個(gè)概念, 是一個(gè)混合變量

"網(wǎng)速" = ("帶寬","請(qǐng)求相應(yīng)時(shí)間")

帶寬, 也就是每次拿多少, 一般都是假設(shè)是一個(gè)固定的值
那么就剩下請(qǐng)求響應(yīng)時(shí)間了, 這個(gè)涉及到的點(diǎn),
就是: 接口響應(yīng)要快.

前面討論的時(shí)候, 都是假設(shè), 只有小明一個(gè)人在搬, 但是如果有 10個(gè)人呢?
這里涉及到的就是:
瀏覽器的并行加載

這玩意是瀏覽器提供的, 我們談我們的性能優(yōu)化手段, 貌似和他也沒(méi)有關(guān)系, 這個(gè)是瀏覽器做的事情.
不不不, 我們可以利用.
從這個(gè)角度來(lái)看, 是不是并行加載的數(shù)量越多越好? 就是的.
那么我們可以嘗試去提高并行加載的數(shù)量啊, 比如說(shuō)從 1 提高到 100
這里涉及到的是:
瀏覽器的并行加載是以 domain 為區(qū)分而限制的, 一個(gè) domain 最多可以支持 4個(gè)(不同瀏覽器不同)
并行加載.

那么我們把資源分成多個(gè)域名不就可以了嗎? 好像是這個(gè)道理.
你有100個(gè)資源, 劃分成 25個(gè)域名, 同一個(gè)域名下面支持 4個(gè)并行, 那你不是一瞬間100個(gè)都發(fā)出去了嗎
那速度不是唰的一下就上來(lái)了嗎? （這塊沒(méi)弄明白）

那再想想, 還有什么辦法能讓時(shí)間更短一點(diǎn)?
讓 A 跟 B 近一點(diǎn)啊.
這個(gè)就是 CDN.
也就是說(shuō), 我們可以上 CDN, 這個(gè)的確是我們做的.

上面的都是說(shuō)第一次加載, 第一次訪(fǎng)問(wèn)的時(shí)候, 還有第二次第三次訪(fǎng)問(wèn)的情況, 這個(gè)時(shí)候就涉及到緩存了。

我們說(shuō)下緩存
以我記憶里面的概念, 在性能優(yōu)化的時(shí)候提到的緩存一般有三種情況:

瀏覽器緩存

通過(guò)使用 storage 進(jìn)行緩存

Ajax 緩存

為什么要緩存?
因?yàn)楫?dāng)你第一次訪(fǎng)問(wèn)一個(gè)網(wǎng)站, 請(qǐng)求了 100個(gè)資源.
然后你第二次又訪(fǎng)問(wèn)了這個(gè)網(wǎng)站, 又請(qǐng)求了 100個(gè)資源.

把這兩個(gè) "100個(gè)資源"做并集, 就會(huì)發(fā)現(xiàn)并集里面有很多資源.
也就是說(shuō)你在兩次訪(fǎng)問(wèn)這個(gè)網(wǎng)站的時(shí)候, 對(duì)于同一個(gè)資源, 你請(qǐng)求了兩次.
這肯定是不必要的, 浪費(fèi)的. 所以我們完全可以搞起來(lái).

怎么搞?

拿到多次訪(fǎng)問(wèn)的時(shí)候, 每次請(qǐng)求的資源, 作為一個(gè)集合

做這些集合的并集

得到的集合, 就是在這多次訪(fǎng)問(wèn)中都沒(méi)有變化的資源, 稱(chēng)為 A

我們的目標(biāo)就是: 讓 A 中所有的資源都僅僅請(qǐng)求一次就好了.
1 得到 A
我們要怎么得到 A ? 資源是我們弄出來(lái)的啊, 代碼是你寫(xiě)的,
你對(duì)資源都很清楚的, 所以你自己就知道哪些資源是一直都不變的, 哪些資源是一段時(shí)間就變的
哪些是每次都變的, 你很清楚啊.

好吧, 那我給你一個(gè)所有的不變的資源 A

2 再說(shuō)下緩存是誰(shuí)緩存? 瀏覽器啊, 那瀏覽器怎么知道這一堆資源里面哪個(gè)要緩存, 哪個(gè)不要?
你知道, 所以你要去告訴他.
你怎么告訴他? http 協(xié)議啊, 那只能是 http headers 字段里面標(biāo)記了啊.
這里不具體說(shuō) 協(xié)議頭長(zhǎng)什么樣子, 說(shuō)下方案:

server 告訴 client, 這個(gè)文件要緩存, 這個(gè)文件什么時(shí)候過(guò)期
在下一次訪(fǎng)問(wèn)的時(shí)候, 瀏覽器請(qǐng)求的時(shí)候呢發(fā)現(xiàn)了這個(gè)文件, 看看它什么時(shí)候過(guò)期, 發(fā)現(xiàn)沒(méi)有過(guò)期
那就用, 哎一發(fā)現(xiàn)過(guò)期了, 那么就去重新請(qǐng)求. 就是保質(zhì)期的意思.

第二種方案是 storage 做緩存, 我印象中記得看見(jiàn)過(guò)兩個(gè):
微信
美團(tuán)的 LsLoader

第三種就是 Ajax 請(qǐng)求緩存, 通常見(jiàn)于 query 類(lèi)型的接口的緩存, 比如說(shuō)商品列表等.

最后一個(gè)討論點(diǎn), 我們之前只是說(shuō)資源拿回來(lái), 頁(yè)面顯示, 但是這兩者之間, 還有個(gè)事情:
瀏覽器需要去渲染資源

我們說(shuō)瀏覽器的渲染過(guò)程, 到底在說(shuō)什么, 是在說(shuō)整個(gè)流程, 輸入資源, 輸出頁(yè)面.
步驟大體上可以這么描述

   輸入html -> 解析   
                  -> 合并成 render tree -> layout -> paint ->結(jié)束.
   輸入css  -> 解析 

layout: 就是安排 render tree 上面的每一個(gè)節(jié)點(diǎn)的位置, 大小
paint: 就是繪制每一個(gè)節(jié)點(diǎn).

流程是這樣, 那還有啥問(wèn)題.

(1) 下載和解析是不是同步的, 不是, 是邊下載邊解析, 不需要等到所有的資源都下載結(jié)束才解析
也就是說(shuō): 來(lái)了 html 就解析html, 來(lái)了 css 就解析 css

(2) 在渲染的過(guò)程中, 如果遇見(jiàn) js 怎么辦? 是繼續(xù)渲染還是停下, 先執(zhí)行 js?
其實(shí)就兩個(gè)答案, 要么繼續(xù), 要么停下來(lái).

繼續(xù)的話(huà), 就是說(shuō)讓 js 在我渲染之后再執(zhí)行, 別著急, 好的, 渲染結(jié)束之后, js 里面唰的一下執(zhí)行一下:

document.write("");

這意味著, 我所有的渲染的努力都白費(fèi)了.
與此相比, 在渲染的時(shí)候遇見(jiàn) js 等一下, 等它執(zhí)行結(jié)束, 再繼續(xù)執(zhí)行, 這樣防止全盤(pán)努力白費(fèi),
風(fēng)險(xiǎn)小點(diǎn), 所以還是等吧.

所以在渲染的過(guò)程中, 如果遇見(jiàn) js, 那么就停下來(lái), 執(zhí)行它.

那能不能讓 js 告訴我它到底有沒(méi)有就是說(shuō), 更改 DOM, 有時(shí)候它的確不會(huì)啊, 這個(gè)時(shí)候我就白等了.
所以有 defer 和 async

這個(gè)就相當(dāng)于說(shuō),
defer, defer啊, 告訴你, 你不用等我, 你繼續(xù)渲染, 我不會(huì)改你的, ok
這個(gè)時(shí)候, js 就會(huì)在瀏覽器渲染之后再執(zhí)行.

async 呢?
這個(gè)就坑爹了, 這個(gè)說(shuō), 你別等我, 我也不等你, 我反正下下來(lái)之后就執(zhí)行