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

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

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

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

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

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

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

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

time = n/p

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

所以問題變成: 如何減少我們資源的大小?
先說我們的資源的種類有哪些?

images
js
css
html
fonts
others

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

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

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

切圖的時候就不要切高清無碼圖

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

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

上面的討論, 實際上都是有一個前提的, 就是說:
所有的資源都從 server 到 client 之后, client 才能看見頁面

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

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

依舊是那些資源類型:

images
js
css
html
fonts
others

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

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

首屏渲染

按需加載

code spliting

critial css

...

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

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

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

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

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

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

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

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

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

那再想想, 還有什么辦法能讓時間更短一點?
讓 A 跟 B 近一點啊.
這個就是 CDN.
也就是說, 我們可以上 CDN, 這個的確是我們做的.

上面的都是說第一次加載, 第一次訪問的時候, 還有第二次第三次訪問的情況, 這個時候就涉及到緩存了。

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

瀏覽器緩存

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

Ajax 緩存

為什么要緩存?
因為當(dāng)你第一次訪問一個網(wǎng)站, 請求了 100個資源.
然后你第二次又訪問了這個網(wǎng)站, 又請求了 100個資源.

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

怎么搞?

拿到多次訪問的時候, 每次請求的資源, 作為一個集合

做這些集合的并集

得到的集合, 就是在這多次訪問中都沒有變化的資源, 稱為 A

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

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

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

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

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

第三種就是 Ajax 請求緩存, 通常見于 query 類型的接口的緩存, 比如說商品列表等.

最后一個討論點, 我們之前只是說資源拿回來, 頁面顯示, 但是這兩者之間, 還有個事情:
瀏覽器需要去渲染資源

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

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

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

流程是這樣, 那還有啥問題.

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

(2) 在渲染的過程中, 如果遇見 js 怎么辦? 是繼續(xù)渲染還是停下, 先執(zhí)行 js?
其實就兩個答案, 要么繼續(xù), 要么停下來.

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

document.write("");

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

所以在渲染的過程中, 如果遇見 js, 那么就停下來, 執(zhí)行它.

那能不能讓 js 告訴我它到底有沒有就是說, 更改 DOM, 有時候它的確不會啊, 這個時候我就白等了.
所以有 defer 和 async

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

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