性能優(yōu)化不單指優(yōu)化一個頁面的打開速度，在開發(fā)環(huán)境將一個項目的啟動時間縮短使開發(fā)體驗更好也屬于性能優(yōu)化，大文件上傳時為其添加分片上傳、斷點續(xù)傳也屬于性能優(yōu)化。在項目開發(fā)以及用戶使用的過程中，能夠讓任何一個鏈路快一點，都可以被叫做性能優(yōu)化。

本文會對web頁面的全鏈路進行完整的講解并針對每一步找到能做的性能優(yōu)化點，本文的目標是極致的性能優(yōu)化。

因為針對性能優(yōu)化，能做的點會特別特別的多，覆蓋著整個互聯(lián)網(wǎng)的訪問流程，因此此文章的內(nèi)容會比較多且雜，筆者會盡量對內(nèi)容進行分類講解。

本文的大致流程為先講理論知識，比如如何評價一個頁面的性能好與不好、如果獲取性能指標，如何使用各種性能相關工具，瀏覽器如何獲取并渲染頁面。筆者認為這些都是基礎，只有了解了這些基礎才能開始考慮如何去優(yōu)化。

接下來我們會進入性能優(yōu)化環(huán)節(jié)，在這個環(huán)節(jié)我會詳細講解在頁面的整個流程中，哪些地方可以做哪些優(yōu)化。

瀏覽器渲染原理

我們需要知道瀏覽器是如何渲染一個頁面的，我們才能知道如何對頁面進行性能優(yōu)化，所以這里我們對一些基礎知識進行講解

進程與線程

瀏覽器有多種進程，其中最主要的5種進程如下

瀏覽器進程負責界面展示、用戶交互、子進程管理、提供存儲等
渲染進程每個頁面都有一個單獨的渲染進程，用于渲染頁面，包含webworker線程
網(wǎng)絡進程主要處理網(wǎng)絡資源加載（HTML、CSS、JS、IMAGE、AJAX等）
GPU進程 3D繪制，提高性能
插件進程 chrome插件，每個插件占用一個進程

輸入url到頁面展示完整過程

圖1

1.用戶輸入

用戶在瀏覽器進程輸入并按下回車健后，瀏覽器判斷用戶輸入的url是否為正確的url，如果不是，則使用默認的搜索引擎將該關鍵字拼接成url。

2.卸載原頁面并重定向到新頁面

然后瀏覽器會將現(xiàn)有頁面卸載掉并重定向到用戶新輸入的url頁面，也就是圖中【Process Unload Event】和【Redirect】流程。

此時瀏覽器會準備一個渲染進程用于渲染即將到來的頁面，和一個網(wǎng)絡進程用于發(fā)送網(wǎng)絡請求。

3.處理Service Worker

如果當前頁面注冊了Service Worker那么它可以攔截當前網(wǎng)站所有的請求，進行判斷是否需要向遠程發(fā)送網(wǎng)絡請求。也就是圖中【Service Worker Init】與【Service Worker Fecth Event 】步驟

如果不需要發(fā)送網(wǎng)絡請求，則取本地文件。如果需要則進行下一步。

4.網(wǎng)絡請求

OSI網(wǎng)絡七層模型：物理層、數(shù)據(jù)鏈路層、網(wǎng)絡層、傳輸層、會話層、表示層、應用層
在實際應用中物理層、數(shù)據(jù)鏈路層被統(tǒng)稱為物理層，會話層、表示層、應用層被統(tǒng)稱為應用層，所以實際使用時通常分為4個層級
【物理層】>【網(wǎng)絡層(IP)】>【傳輸層(TCP/UDP)】>【應用層(HTTP)】

也就是圖中【HTTP Cache】、【DNS】、【TCP】、【Request】、【Response】步驟

圖2

瀏覽器會拿著url通過網(wǎng)絡進程進行如下步驟

根據(jù)url查詢本地是否已經(jīng)有強制緩存，如果有則判斷緩存是否過期，如果沒過期則直接返回緩存內(nèi)容，也就是圖1中【HTTP Cache】步驟
如果沒有強制緩存或者緩存已過期，則將該請求加入隊列進行排隊準備發(fā)送網(wǎng)絡請求，也就是圖2中【正在排隊】，然后進入DNS解析階段，也就是圖1中【DNS】以及圖2中的【DNS查找】，DNS根據(jù)域名解析出對應的IP地址。(DNS基于UDP)。
然后使用IP尋址找到對方，然后根據(jù)IP地址+端口號創(chuàng)建一個TCP連接(三次握手)，也就是圖1中【TCP】以及圖2中的【初始連接】創(chuàng)建完成后利用TCP連接來傳輸數(shù)據(jù)。(TCP會將數(shù)據(jù)拆分為多個數(shù)據(jù)包，進行有序傳輸，如果丟包會重發(fā)，TCP的特點是可靠、有序)
判斷當前協(xié)議是否為https，如果為https，則進行SSL協(xié)商，將數(shù)據(jù)進行加密，如果為http協(xié)議則不進行加密(明文傳輸)，也就是圖2中的【SSL】。
開始發(fā)送http請求(請求行/請求頭/請求體)，也就是圖1中【Request】以及圖2中的【已發(fā)送請求】。HTTP協(xié)議有多個版本，目前使用最多的版本為HTTP/1.1，HTTP/1.1發(fā)送完成后默認不會斷開。keep-alive 默認打開，為了下次傳輸數(shù)據(jù)時復用上次創(chuàng)建的連接。每個域名最多同時建立6個TCP連接，所以同一時間最多發(fā)生6個請求。
HTTP協(xié)議的各個版本特性如下：

HTTP/0.9 沒有請求頭和響應頭，不區(qū)分傳輸?shù)膬?nèi)容類型，因為當時只傳輸HTML。
HTTP/1.0 提供了請求頭和響應頭，可以傳輸不同類型的內(nèi)容數(shù)據(jù)。根據(jù)請求響應頭的不同來處理不同的資源，HTTP1.0每次發(fā)完請求都會斷開TCP連接。有新的請求時再次創(chuàng)建TCP連接。
HTTP/1.1 默認開啟了 keep-alive ，它能夠讓一個TCP連接中傳輸多個HTTP請求，也叫鏈路復用。但一個TCP連接同一時間只能發(fā)送一個HTTP請求，為了不阻塞多個請求，Chrome允許創(chuàng)建6個TCP連接，所以在HTTP/1.1中，最多能夠同時發(fā)送6個網(wǎng)絡請求。
HTTP/2.0 HTTP/2.0使用同一個TCP連接來發(fā)送數(shù)據(jù)，他把多個請求通過二進制分貞層實現(xiàn)了分貞，然后把數(shù)據(jù)傳輸給服務器。也叫多路復用，多個請求復用同一個TCP連接。HTTP/2.0會將所有以:開頭的請求頭做一個映射表，然后使用hpack進行壓縮，使用這種方式會使請求頭更小。服務器可主動推送數(shù)據(jù)給客戶端。
HTTP/3.0 使用UDP實現(xiàn)，在UDP上一層加入一層QUIC協(xié)議，解決了TCP協(xié)議中的隊頭阻塞問題。

服務器收到數(shù)據(jù)后解析HTTP請求(請求行/請求頭/請求體)，處理完成后生成狀態(tài)碼和HTTP響應(響應行/響應頭/響應體)后返回給客戶端，也就是圖2的【等待中】在做的事情。
客戶端接收到HTTP響應后根據(jù)狀態(tài)碼進行對應的處理，如果狀態(tài)碼為304則直接代表協(xié)商緩存生效，直接取本地的緩存文件。如果不是則下載內(nèi)容。也就是圖1中【Response】以及圖2中的【下載內(nèi)容】步驟。

5.服務端響應

在4.網(wǎng)絡請求第6步中，服務器收到HTTP請求后需要根據(jù)請求信息來進行解析，并返回給客戶端想要的數(shù)據(jù)，這也就服務端響應。

服務端可以響應并返回給客戶端很多種類型的資源，這里主要介紹html類型

目前前端處理服務端響應html請求主要分為SSR服務端渲染與CSR客戶端渲染，CSR就是返回一個空的HTML模版，然后瀏覽器加載js后通過js動態(tài)渲染頁面。SSR是服務端在接受到請求時事先在服務端渲染好html返回給客戶端后，客戶端再進行客戶端激活。

在打開一個站點的首屏頁的完整鏈路中，使用SSR服務端渲染時的速度要遠大于CSR客戶端渲染，并且SSR對SEO友好。所以對于首屏加載速度比較敏感或者需要優(yōu)化SEO的站點來說，使用SSR是更好的選擇。

6.瀏覽器渲染詳細流程

瀏覽器渲染詳細流程主要在4.網(wǎng)絡請求中的地7步。瀏覽器下載完html內(nèi)容后進行解析何渲染頁面的流程。

渲染流程分為4種情況，

HTML中無任何CSS相關標簽
CSS相關標簽在HTML最頂部，且在解析到內(nèi)容標簽（
）時已經(jīng)解析完CSS相關標簽
CSS相關標簽在HTML最頂部，但在解析到內(nèi)容標簽（
）時CSS相關標簽尚未解析完
CSS相關標簽在HTML最底部

下面的流程是對上圖的文字版解析。讀者可將以上4種情況分別帶入到如下的渲染流程中走一遍。就能理解瀏覽器的完整渲染過程了。

【HTML】

瀏覽器收到html資源后先預掃描和

我們遵循讀寫分離的原則，將讀取位置操作放到函數(shù)外，我們可以發(fā)現(xiàn)就算循環(huán)插入10個dom節(jié)點，也只需要執(zhí)行一次【計算樣式】和【重排】。

如何減少重排與重繪

脫離文檔流(絕對定位、固定定位)，脫離文檔流的元素進行重排不會影響到其他元素。
圖片渲染時增加寬高屬性，寬高固定后，圖片不會根據(jù)內(nèi)容動態(tài)改變高度，便不會觸發(fā)重排。
盡量用CSS3動畫，CSS3動畫能最大程度減少重排與重繪。
使用will-change: transform;將元素獨立為一個單獨的圖層。（定位、透明、transform、clip都會產(chǎn)生獨立圖層）

靜態(tài)文件優(yōu)化策略

圖片格式

jpeg

適合色彩豐富的圖、Banner圖。不適合：圖形文字、圖標、不支持透明度。

png

適合純色、透明、圖標，支持純透明和半透明。不適合色彩豐富圖片，因為無損儲存會導致儲存體積大于jpeg

gif

適合動畫、可以動的圖標。支持純透明但不支持半透明，不適合色彩豐富的圖片。

埋點信息通常也會使用gif發(fā)送，因為1x1的gif圖發(fā)送的網(wǎng)絡請求比普通的get請求要小一些。

webp

支持純透明和半透明，可以保證圖片質(zhì)量和較小的體積，適合Chrome和移動端瀏覽器。不適合其他瀏覽器。

svg

矢量格式，大小非常小，但渲染成本過高，適合小且色彩單一的圖標。

圖片優(yōu)化

減少圖片資源的尺寸和大小，節(jié)約用戶流量
設置alt="xxx"屬性，圖像無法顯示時會顯示alt內(nèi)容
圖片懶加載， loading="lazy"為原生，建議使用IntersectionObserver自己做懶加載
不同環(huán)境加載不同尺寸和像素的圖片srcset與sizes的使用。
采用漸進式加載先加載占位圖，然后加載模糊小圖，最后加載真正清晰的圖
使用Base64URL 減少圖片請求數(shù)
采用雪碧圖合并圖片，減少請求數(shù)。

HTML優(yōu)化

語義化HTML，代碼簡潔清晰，利于SEO，便于開發(fā)維護。
減少HTML嵌套關系，減少DOM節(jié)點數(shù)量。
提前聲明字符編碼，讓瀏覽器快速確定如何渲染網(wǎng)頁內(nèi)容
刪除多余空格、空行、注釋、無用屬性
減少iframe，子iframe會阻塞父級的onload事件。可以使用js動態(tài)給iframe賦值，就能解決這個問題。
避免table布局

CSS優(yōu)化

減少偽類選擇器，減少選擇器層數(shù)、減少通配符選擇器、減少正則選擇器
避免css表達式background-color: expression(...)
刪除空格、空行、注釋、減少無意義的單位、css壓縮
css外鏈，能走緩存
添加媒體字段，只加載有效的css文件

<link?rel="stylesheet"?href="./small.css"?media="screen?and?(max-width:600px)"?/>
<link?rel="stylesheet"?href="./big.css"?media="screen?and?(min-width:601px)"/>

使用css contain屬性，能控制對應元素是否根據(jù)子集元素的改變進行重排
減少@import使用，因為它使用串行加載

JS優(yōu)化

通過script的async、defer屬性異步加載，不阻塞DOM渲染
減少DOM操作，緩存訪問過的元素。
不直接操作真實DOM，可以先修改，然后一次性應用到DOM上。（虛擬DOM、DOM碎片節(jié)點）
使用webworker解決復雜運算，避免復雜運算阻塞主線程，webworker線程位于渲染進程
圖片懶加載，使用IntersectionObserver實現(xiàn)

html>
<html?lang="en">
??<head>
????<meta?charset="UTF-8"?/>
????<meta?http-equiv="X-UA-Compatible"?content="IE=edge"?/>
????<meta?name="viewport"?content="width=device-width,?initial-scale=1.0"?/>
????<style>
??????img?{
????????height:?200px;
????????display:?block;
??????}
????style>
????<title>Documenttitle>
??head>
??<body>
????<img?src="./loading.gif"?src="./01.jpg"?/>
????<img?src="./loading.gif"?src="./02.jpg"?/>
????<img?src="./loading.gif"?src="./03.jpg"?/>
????<img?src="./loading.gif"?src="./04.jpg"?/>
????<img?src="./loading.gif"?src="./05.jpg"?/>
????<img?src="./loading.gif"?src="./06.jpg"?/>
????<img?src="./loading.gif"?src="./07.jpg"?/>
????<img?src="./loading.gif"?src="./08.jpg"?/>
????<img?src="./loading.gif"?src="./09.jpg"?/>
????<img?src="./loading.gif"?src="./10.jpg"?/>

????<script>
??????const?intersectionObserver?=?new?IntersectionObserver((changes)?=>?{
????????changes.forEach((item,?index)?=>?{
??????????if?(item.intersectionRatio?>?0)?{
????????????intersectionObserver.unobserve(item.target)
????????????item.target.src?=?item.target.dataset.src
??????????}
????????})
??????});

??????const?domImgList?=?document.querySelectorAll("img");
??????domImgList.forEach((domImg)?=>?intersectionObserver.observe(domImg));
????script>
??body>
html>

虛擬滾動
使用requestAnimationFrame來做動畫，使用requestIdleCallback來進行空閑時的任務處理
盡量避免使用eval，性能差。
使用事件委托，能減少事件綁定個數(shù)。事件越多性能越差。
盡量使用canvas、css3動畫。
通過chrome覆蓋率（Coverage）工具排查代碼中未使用過的代碼并將其刪除
通過chrome性能（Performance）工具查看每個函數(shù)的執(zhí)行性能并優(yōu)化

字體優(yōu)化

FOUT(Flash of Unstyled Text）等待一段時間，如果沒加載完成，先顯示默認。加載后再進行切換。

FOIT(F1ash of Invisib1e Text）字體加載完畢后顯示，加載超時降級系統(tǒng)字體（白屏

html>
<html?lang="en">
<head>
??<meta?charset="UTF-8">
??<meta?http-equiv="X-UA-Compatible"?content="IE=edge">
??<meta?name="viewport"?content="width=device-width,?initial-scale=1.0">
??<style>
????@font-face?{
??????font-family:?'hagan';
??????src:?url('./font.ttc');
??????font-display:?swap;
??????/*?b1ock?35?內(nèi)不顯示，如果沒加載完畢用默認的?*/
??????/*?swap?顯示老字體?在替換*/
??????/*?fa11back?縮短不顯示時間，如果沒加載完畢用默認的，和b1ock類似*
??????/*?optional?替換可能用字體?可能不替換*/
????}
????article?{
??????font-family:?hagan;
????}
??style>
??<title>Documenttitle>
head>
<body>
??<article>ABC?abcarticle>??
body>
html>

瀏覽器儲存優(yōu)化策略

Cookie

cookie在過期之前一直有效，最大儲存大小為4k，限制字段個數(shù)，不適合大量的數(shù)據(jù)儲存，每次請求會攜帶cookie，主要用來做身份校驗。

優(yōu)化方式：

需要合理設置cookie有效期
根據(jù)不同子域劃分cookie來減少cookie傳輸
靜態(tài)資源域名和cookie域名采用不同域名，避免靜態(tài)資源請求攜帶cookie。

LocalStorage

Chrome下最多儲存5M，除非手動清除，否則一直存在。可以利用localStorage儲存靜態(tài)資源。比如儲存網(wǎng)頁的.js、.css，這樣會使頁面打開速度非常快。例如 https://m.baidu.com

/index.js

const?name?=?'hagan'
function?showName?()?{
??console.log(name)
}
showName()

/index.html

html>
<html?lang="en">
<head>
??<meta?charset="UTF-8">
??<meta?http-equiv="X-UA-Compatible"?content="IE=edge">
??<meta?name="viewport"?content="width=device-width,?initial-scale=1.0">
??<title>Documenttitle>
head>
<body>
??<script?src="https://lib.baomitu.com/axios/0.26.1/axios.js">script>
??<script>
????cacheFile('/index.js')

????async?function?cacheFile?(url)?{
??????const?fileContent?=?localStorage.getItem(url)
??????if?(fileContent)?{
????????eval(fileContent)
??????}?else?{
????????const?{?data?}?=?await?axios.get(url)
????????eval(data)
????????localStorage.setItem(url,?data)
??????}
????}
??script>
body>
html>

SessionStorage

會話級別儲存，可用于頁面間的傳值

IndexDB

瀏覽器的本地數(shù)據(jù)庫，大小幾乎無上限

其他優(yōu)化策略

關鍵資源個數(shù)越多，首次頁面加載時間就會越長
關鍵資源的大小，內(nèi)容越小下載時間越短。
優(yōu)化白屏，合理使用內(nèi)聯(lián)css、js
預渲染，打包時進行預渲染，生成靜態(tài)HTML文件，用戶訪問時直接返回靜態(tài)HTML。
服務端渲染同構(gòu)，加速首屏速度（耗費服務端資源），有利于SEO優(yōu)化。首屏使用服務端渲染，后續(xù)交互使用客戶端渲染。

使用PWA提高用戶體驗

webapp用戶體驗差的一大原因是不能離線訪問。用戶粘性低的一大原因是無法保存入口，PWA就是為了解決webapp的用戶體驗問題而誕生的。使用PWA能令站點擁有快速、可靠、安全等特性。

Web App Manifest 將網(wǎng)站添加到電腦桌面、手機桌面，類似Native的體驗。
Service Worker 配合Cache API，能做到離線緩存各種內(nèi)容。
Push API 配合 Notification API，能做到類似Native的消息推送與實時提醒。
App Shell 配合 App Skeleton，能做App殼與骨架屏

參考資料

https://www.w3.org/TR/navigation-timing-2/

Web頁面全鏈路性能優(yōu)化指南

目錄