什么是性能優(yōu)化
一提到前端性能優(yōu)化大家的本能反應(yīng)：sprite 圖合并 / 靜態(tài)資源打包 /... 峰弹，那么針對網(wǎng)絡(luò)這塊是怎么進(jìn)行性能優(yōu)化的？
一般性的用戶行為例子：
用戶 => 促銷頁面 => 商品頁面 => 下單流程 => 支付成功
首先用戶訪問促銷活動頁面，之后再到商品詳情頁面也拜，然后再下單到支付成功泡嘴。用戶每進(jìn)行一個步驟都是一次頁面的訪問，所以上面流程至少有 4 個及其以上的訪問柑土。一般性我們怎么來知道性能優(yōu)化的標(biāo)準(zhǔn)呢蜀肘？我們來看一下業(yè)內(nèi)的一個關(guān)鍵詞：
3秒 = 50% 離開
3 秒意味著可能有 50% 用戶已經(jīng)離開了，它其實(shí)定義了好與不好稽屏。例如：白屏?xí)r間超過了3秒扮宠，用戶極有可能已經(jīng)離開了。如果假設(shè)每個頁面加載都超過 3 秒狐榔，那用戶真正能留下來的概率就會是下面這樣：
0.5 * 0.5 * ...
可以看出鏈路越長轉(zhuǎn)化越差坛增。
對于我們電商來說获雕，性能優(yōu)化如果能多降低 0.1 秒，能極大的提升銷售的轉(zhuǎn)化收捣，對成本來說也會有很大的影響届案。另外，3 秒這個指標(biāo)對訪問入口也是有影響的罢艾。大于 3 秒的頁面會影響到百度或者谷歌對網(wǎng)站的 SEO楣颠。流量可能會受一定影響。所以在流量和轉(zhuǎn)化的一種雙重夾擊下面昆婿，性能優(yōu)化成為一個必行之道球碉。
性能優(yōu)化的衡量標(biāo)準(zhǔn)
- Web 端（PC / Web App）：首屏?xí)r間、白屏?xí)r間仓蛆、可交互時間睁冬、完全加載時間等。
- 移動端（Native App）：Crash 率看疙、內(nèi)存使用率豆拨、FPS（Frames Per Second，每秒傳輸幀數(shù)）能庆、端到端響應(yīng)時間等施禾。
- 后端：響應(yīng)時間（RT）、吞吐量（TPS）搁胆、并發(fā)數(shù)等弥搞。
下圖是 Web 端的性能優(yōu)化的木桶理論：
定位性能問題
通常的：
首屏?xí)r間 = DNS時間 + 建立連接時間 + 后端響應(yīng)時間 + 網(wǎng)絡(luò)傳輸時間 + 首屏頁面渲染時間
上面的描述看起來會比較抽象，我們拿 Chrome 調(diào)試中的 Network 來看下具體的時序圖是什么樣渠旁。
上圖中我們關(guān)心的指標(biāo)通常有：
- Stalled（掛起）
- DNS Lookup（DNS 節(jié)點(diǎn)查詢）
- TTFB（首字節(jié)的返回）
- Content Download（文檔下載時間）
從圖中可以看到 DNS 查詢時間是 4.13ms攀例，TTFB 是 2.08s，Content Download是 673.91ms顾腊。其中 TTFB 非常高粤铭，這可能是服務(wù)器、基礎(chǔ)網(wǎng)絡(luò)杂靶、CDN 出現(xiàn)問題梆惯。第二是 DNS Lookup 是 4.13ms，看起來還好一些吗垮，可能采用 CDN 就近策略垛吗，如果是單機(jī)部署的話這個值可能會高一些。Content Download 和網(wǎng)絡(luò)抱既、帶寬及文本大小有關(guān)系职烧。
看完時序圖我們來看一下整體的一個匯總：
結(jié)合上面是單個時序圖及多個請求的匯總圖，我們來分析一下整體的時序圖防泵。
首先可以看到 index 請求發(fā)完后緊接著發(fā)了 9 個請求蚀之，其中 CSS 有3個，JS 有6個捷泞。有 3 個 JS 時間非常的長足删，這樣情況我們可以調(diào)整代碼打包的策略，將小的 JS 文件合并來減少請求的數(shù)量锁右。一般建議小于 5k 的文件不要單獨(dú)發(fā)一個 HTTP 請求失受。
執(zhí)行性能優(yōu)化
根據(jù)上面我們發(fā)現(xiàn)的性能問題，下面是執(zhí)行了性能優(yōu)化后的效果圖咏瑟。
均衡請求值的大蟹鞯健（其中藍(lán)色的線是分布相對均勻）
控制合理的請求數(shù)量：單次5個（一般初次的請求數(shù)量 5 個就能滿足了）
總結(jié)
最后總結(jié)一下性能優(yōu)化。
性能優(yōu)化更加像圖中這樣一個冰山码泞。上面是網(wǎng)絡(luò)層的優(yōu)化兄旬，下面是代碼層的優(yōu)化。當(dāng)然代碼層優(yōu)化是一個非常龐大的項(xiàng)目余寥，它甚至?xí)嵏参覀兊募夹g(shù)選型领铐。對于網(wǎng)絡(luò)層我們都是有共性的，比如控制數(shù)量宋舷、控制請求的情況绪撵，不僅僅只是減少請求的數(shù)量甚至要均衡請求的大小。這是我們眼睛能看到的部分祝蝠，這部分優(yōu)化好之后其實(shí)也會對頁面性能有一個質(zhì)的飛躍音诈。但是代碼層因?yàn)槊總€項(xiàng)目都不一樣選型，我們可以看下比如：部分動畫我們是否可以采用CSS3的性能绎狭、插入DOM的時候是否可以批量插入细溅。就像圖中一樣，代碼層優(yōu)化水也是很深的坟岔，需要大家在自己的項(xiàng)目中慢慢摸索谒兄。
以上就是關(guān)于Web端的性能優(yōu)化，希望能幫到大家社付。
