前端性能優(yōu)化是把雙刃劍，有好的一面也有壞的一面。好的一面就是能提升網(wǎng)站性能，壞的一面就是配置麻煩，或要遵守的規(guī)則太多。并且性能優(yōu)化并不適用于所有的場(chǎng)景，需要謹(jǐn)慎使用。

1. 減少 HTTP 請(qǐng)求

一個(gè)完整的HTTP請(qǐng)求需要經(jīng)歷 DNS 查找，TCP 握手，瀏覽器發(fā)出 HTTP 請(qǐng)求，服務(wù)器接收請(qǐng)求，服務(wù)器處理請(qǐng)求并發(fā)出響應(yīng)，瀏覽器接收響應(yīng)等過(guò)程。接下來(lái)看一個(gè)具體的例子幫助理解 HTTP ：

這是一個(gè) HTTP 請(qǐng)求，請(qǐng)求的文件大小為 28.4KB。

名詞解釋：

• Queueing: 在請(qǐng)求隊(duì)列中的時(shí)間。
• Stalled: 從TCP 連接建立完成，到真正可以傳輸數(shù)據(jù)之間的時(shí)間差，此時(shí)間包括代理協(xié)商時(shí)間。
• Proxy negotiation: 與代理服務(wù)器連接進(jìn)行協(xié)商所花費(fèi)的時(shí)間。
• DNS Lookup: 執(zhí)行DNS查找所花費(fèi)的時(shí)間，頁(yè)面上的每個(gè)不同的域都需要進(jìn)行DNS查找。
• Initial Connection / Connecting: 建立連接所花費(fèi)的時(shí)間，包括TCP握手/重試和協(xié)商SSL。
• SSL: 完成SSL握手所花費(fèi)的時(shí)間。
• Request sent: 發(fā)出網(wǎng)絡(luò)請(qǐng)求所花費(fèi)的時(shí)間，通常為一毫秒的時(shí)間。
• Waiting(TFFB): TFFB 是發(fā)出頁(yè)面請(qǐng)求到接收到應(yīng)答數(shù)據(jù)第一個(gè)字節(jié)的時(shí)間。
• Content Download: 接收響應(yīng)數(shù)據(jù)所花費(fèi)的時(shí)間

從這個(gè)例子可以看出，真正下載數(shù)據(jù)的時(shí)間占比為 13.05 / 204.16 = 6.39%，文件越小，這個(gè)比例越小，文件越大，比例就越高。這就是為什么要建議將多個(gè)小文件合并為一個(gè)大文件，從而減少 HTTP 請(qǐng)求次數(shù)的原因。

參考資料：understanding-resource-timing

2. 使用 HTTP2

HTTP2 相比 HTTP1.1 有如下幾個(gè)優(yōu)點(diǎn)：

解析速度快

服務(wù)器解析 HTTP1.1 的請(qǐng)求時(shí)，必須不斷地讀入字節(jié)，直到遇到分隔符 CRLF 為止。而解析 HTTP2 的請(qǐng)求就不用這么麻煩，因?yàn)?HTTP2 是基于幀的協(xié)議，每個(gè)幀都有表示幀長(zhǎng)度的字段。

多路復(fù)用

HTTP1.1 如果要同時(shí)發(fā)起多個(gè)請(qǐng)求，就得建立多個(gè) TCP 連接，因?yàn)橐粋€(gè) TCP 連接同時(shí)只能處理一個(gè) HTTP1.1 的請(qǐng)求。

在 HTTP2 上，多個(gè)請(qǐng)求可以共用一個(gè) TCP 連接，這稱為多路復(fù)用。同一個(gè)請(qǐng)求和響應(yīng)用一個(gè)流來(lái)表示，并有唯一的流 ID 來(lái)標(biāo)識(shí)。多個(gè)請(qǐng)求和響應(yīng)在 TCP 連接中可以亂序發(fā)送，到達(dá)目的地后再通過(guò)流 ID 重新組建。

首部壓縮

HTTP2 提供了首部壓縮功能。

例如有如下兩個(gè)請(qǐng)求：

:authority: unpkg.zhimg.com :method: GET :path: /za-js-sdk@2.16.0/dist/zap.js :scheme: https accept: */* accept-encoding: gzip, deflate, br accept-language: zh-CN,zh;q=0.9 cache-control: no-cache pragma: no-cache referer: https://www.zhihu.com/ sec-fetch-dest: script sec-fetch-mode: no-cors sec-fetch-site: cross-site user-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36 :authority: zz.bdstatic.com :method: GET :path: /linksubmit/push.js :scheme: https accept: */* accept-encoding: gzip, deflate, br accept-language: zh-CN,zh;q=0.9 cache-control: no-cache pragma: no-cache referer: https://www.zhihu.com/ sec-fetch-dest: script sec-fetch-mode: no-cors sec-fetch-site: cross-site user-agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/80.0.3987.122 Safari/537.36

從上面兩個(gè)請(qǐng)求可以看出來(lái)，有很多數(shù)據(jù)都是重復(fù)的。如果可以把相同的首部存儲(chǔ)起來(lái)，僅發(fā)送它們之間不同的部分，就可以節(jié)省不少的流量，加快請(qǐng)求的時(shí)間。

HTTP/2 在客戶端和服務(wù)器端使用“首部表”來(lái)跟蹤和存儲(chǔ)之前發(fā)送的鍵－值對(duì)，對(duì)于相同的數(shù)據(jù)，不再通過(guò)每次請(qǐng)求和響應(yīng)發(fā)送。

下面再來(lái)看一個(gè)簡(jiǎn)化的例子，假設(shè)客戶端按順序發(fā)送如下請(qǐng)求首部：

Header1:foo Header2:bar Header3:bat

當(dāng)客戶端發(fā)送請(qǐng)求時(shí)，它會(huì)根據(jù)首部值創(chuàng)建一張表：

索引首部名稱值

62	Header1	foo
63	Header2	bar
64	Header3	bat

如果服務(wù)器收到了請(qǐng)求，它會(huì)照樣創(chuàng)建一張表。 當(dāng)客戶端發(fā)送下一個(gè)請(qǐng)求的時(shí)候，如果首部相同，它可以直接發(fā)送這樣的首部塊：

62 63 64

服務(wù)器會(huì)查找先前建立的表格，并把這些數(shù)字還原成索引對(duì)應(yīng)的完整首部。

優(yōu)先級(jí)

HTTP2 可以對(duì)比較緊急的請(qǐng)求設(shè)置一個(gè)較高的優(yōu)先級(jí)，服務(wù)器在收到這樣的請(qǐng)求后，可以優(yōu)先處理。

流量控制

由于一個(gè) TCP 連接流量帶寬（根據(jù)客戶端到服務(wù)器的網(wǎng)絡(luò)帶寬而定）是固定的，當(dāng)有多個(gè)請(qǐng)求并發(fā)時(shí)，一個(gè)請(qǐng)求占的流量多，另一個(gè)請(qǐng)求占的流量就會(huì)少。流量控制可以對(duì)不同的流的流量進(jìn)行精確控制。

服務(wù)器推送

HTTP2 新增的一個(gè)強(qiáng)大的新功能，就是服務(wù)器可以對(duì)一個(gè)客戶端請(qǐng)求發(fā)送多個(gè)響應(yīng)。換句話說(shuō)，除了對(duì)最初請(qǐng)求的響應(yīng)外，服務(wù)器還可以額外向客戶端推送資源，而無(wú)需客戶端明確地請(qǐng)求。

例如當(dāng)瀏覽器請(qǐng)求一個(gè)網(wǎng)站時(shí)，除了返回 HTML 頁(yè)面外，服務(wù)器還可以根據(jù) HTML 頁(yè)面中的資源的 URL，來(lái)提前推送資源。

現(xiàn)在有很多網(wǎng)站已經(jīng)開始使用 HTTP2 了，例如知乎：

其中 h2 是指 HTTP2 協(xié)議，http/1.1 則是指 HTTP1.1 協(xié)議。

參考資料：

• HTTP2 簡(jiǎn)介
• 半小時(shí)搞懂 HTTP、HTTPS和HTTP2

3. 使用服務(wù)端渲染

客戶端渲染: 獲取 HTML 文件，根據(jù)需要下載 JavaScript 文件，運(yùn)行文件，生成 DOM，再渲染。

服務(wù)端渲染：服務(wù)端返回 HTML 文件，客戶端只需解析 HTML。

• 優(yōu)點(diǎn)：首屏渲染快，SEO 好。
• 缺點(diǎn)：配置麻煩，增加了服務(wù)器的計(jì)算壓力。

下面我用 Vue SSR 做示例，簡(jiǎn)單的描述一下 SSR 過(guò)程。

客戶端渲染過(guò)程

訪問(wèn)客戶端渲染的網(wǎng)站。

服務(wù)器返回一個(gè)包含了引入資源語(yǔ)句和 <div id="app"></div> 的 HTML 文件。

客戶端通過(guò) HTTP 向服務(wù)器請(qǐng)求資源，當(dāng)必要的資源都加載完畢后，執(zhí)行 new Vue() 開始實(shí)例化并渲染頁(yè)面。

服務(wù)端渲染過(guò)程

訪問(wèn)服務(wù)端渲染的網(wǎng)站。

服務(wù)器會(huì)查看當(dāng)前路由組件需要哪些資源文件，然后將這些文件的內(nèi)容填充到 HTML 文件。如果有 ajax 請(qǐng)求，就會(huì)執(zhí)行它進(jìn)行數(shù)據(jù)預(yù)取并填充到 HTML 文件里，最后返回這個(gè) HTML 頁(yè)面。

當(dāng)客戶端接收到這個(gè) HTML 頁(yè)面時(shí)，可以馬上就開始渲染頁(yè)面。與此同時(shí)，頁(yè)面也會(huì)加載資源，當(dāng)必要的資源都加載完畢后，開始執(zhí)行 new Vue() 開始實(shí)例化并接管頁(yè)面。

從上述兩個(gè)過(guò)程中可以看出，區(qū)別就在于第二步。客戶端渲染的網(wǎng)站會(huì)直接返回 HTML 文件，而服務(wù)端渲染的網(wǎng)站則會(huì)渲染完頁(yè)面再返回這個(gè) HTML 文件。

這樣做的好處是什么？是更快的內(nèi)容到達(dá)時(shí)間 (time-to-content)。

這樣一算：客戶端渲染的網(wǎng)站需要加載 4 個(gè)文件和 HTML 文件才能完成首頁(yè)渲染，總計(jì)大小為 4M（忽略 HTML 文件大小）。而服務(wù)端渲染的網(wǎng)站只需要加載一個(gè)渲染完畢的 HTML 文件就能完成首頁(yè)渲染，總計(jì)大小為已經(jīng)渲染完畢的 HTML 文件（這種文件不會(huì)太大，一般為幾百K，我的個(gè)人博客網(wǎng)站（SSR）加載的 HTML 文件為 400K）。這就是服務(wù)端渲染更快的原因。

4. 靜態(tài)資源使用 CDN

內(nèi)容分發(fā)網(wǎng)絡(luò)（CDN）是一組分布在多個(gè)不同地理位置的 Web 服務(wù)器。我們都知道，當(dāng)服務(wù)器離用戶越遠(yuǎn)時(shí)，延遲越高。CDN 就是為了解決這一問(wèn)題，在多個(gè)位置部署服務(wù)器，讓用戶離服務(wù)器更近，從而縮短請(qǐng)求時(shí)間。

CDN原理

當(dāng)用戶訪問(wèn)一個(gè)網(wǎng)站時(shí)，如果沒(méi)有 CDN，過(guò)程是這樣的：

瀏覽器要將域名解析為 IP 地址，所以需要向本地 DNS 發(fā)出請(qǐng)求。

本地 DNS 依次向根服務(wù)器、頂級(jí)域名服務(wù)器、權(quán)限服務(wù)器發(fā)出請(qǐng)求，得到網(wǎng)站服務(wù)器的 IP 地址。

本地 DNS 將 IP 地址發(fā)回給瀏覽器，瀏覽器向網(wǎng)站服務(wù)器 IP 地址發(fā)出請(qǐng)求并得到資源。

如果用戶訪問(wèn)的網(wǎng)站部署了 CDN，過(guò)程是這樣的：

瀏覽器要將域名解析為 IP 地址，所以需要向本地 DNS 發(fā)出請(qǐng)求。

本地 DNS 依次向根服務(wù)器、頂級(jí)域名服務(wù)器、權(quán)限服務(wù)器發(fā)出請(qǐng)求，得到全局負(fù)載均衡系統(tǒng)（GSLB）的 IP 地址。

本地 DNS 再向 GSLB 發(fā)出請(qǐng)求，GSLB 的主要功能是根據(jù)本地 DNS 的 IP 地址判斷用戶的位置，篩選出距離用戶較近的本地負(fù)載均衡系統(tǒng)（SLB），并將該 SLB 的 IP 地址作為結(jié)果返回給本地 DNS。

本地 DNS 將 SLB 的 IP 地址發(fā)回給瀏覽器，瀏覽器向 SLB 發(fā)出請(qǐng)求。

SLB 根據(jù)瀏覽器請(qǐng)求的資源和地址，選出最優(yōu)的緩存服務(wù)器發(fā)回給瀏覽器。

瀏覽器再根據(jù) SLB 發(fā)回的地址重定向到緩存服務(wù)器。

如果緩存服務(wù)器有瀏覽器需要的資源，就將資源發(fā)回給瀏覽器。如果沒(méi)有，就向源服務(wù)器請(qǐng)求資源，再發(fā)給瀏覽器并緩存在本地。

參考資料：

• CDN是什么？使用CDN有什么優(yōu)勢(shì)？
• CDN原理簡(jiǎn)析

5. 將 CSS 放在文件頭部，JavaScript 文件放在底部

所有放在 head 標(biāo)簽里的 CSS 和 JS 文件都會(huì)堵塞渲染（CSS 不會(huì)阻塞 DOM 解析）。如果這些 CSS 和 JS 需要加載和解析很久的話，那么頁(yè)面就空白了。所以 JS 文件要放在底部，等 HTML 解析完了再加載 JS 文件。

那為什么 CSS 文件還要放在頭部呢？
因?yàn)橄燃虞d HTML 再加載 CSS，會(huì)讓用戶第一時(shí)間看到的頁(yè)面是沒(méi)有樣式的、“丑陋”的，為了避免這種情況發(fā)生，就要將 CSS 文件放在頭部了。

另外，JS 文件也不是不可以放在頭部，只要給 script 標(biāo)簽加上 defer 屬性就可以了，異步下載，延遲執(zhí)行。

6. 使用字體圖標(biāo) iconfont 代替圖片圖標(biāo)

字體圖標(biāo)就是將圖標(biāo)制作成一個(gè)字體，使用時(shí)就跟字體一樣，可以設(shè)置屬性，例如 font-size、color 等等，非常方便。并且字體圖標(biāo)是矢量圖，不會(huì)失真。還有一個(gè)優(yōu)點(diǎn)是生成的文件特別小。

壓縮字體文件

使用 fontmin-webpack 插件對(duì)字體文件進(jìn)行壓縮。

參考資料：

• fontmin-webpack
• Iconfont-阿里巴巴矢量圖標(biāo)庫(kù)

7. 善用緩存，不重復(fù)加載相同的資源

為了避免用戶每次訪問(wèn)網(wǎng)站都得請(qǐng)求文件，我們可以通過(guò)添加 Expires 或 max-age 來(lái)控制這一行為。Expires 設(shè)置了一個(gè)時(shí)間，只要在這個(gè)時(shí)間之前，瀏覽器都不會(huì)請(qǐng)求文件，而是直接使用緩存。而 max-age 是一個(gè)相對(duì)時(shí)間，建議使用 max-age 代替 Expires 。

不過(guò)這樣會(huì)產(chǎn)生一個(gè)問(wèn)題，當(dāng)文件更新了怎么辦？怎么通知瀏覽器重新請(qǐng)求文件？

可以通過(guò)更新頁(yè)面中引用的資源鏈接地址，讓瀏覽器主動(dòng)放棄緩存，加載新資源。

具體做法是把資源地址 URL 的修改與文件內(nèi)容關(guān)聯(lián)起來(lái)，也就是說(shuō)，只有文件內(nèi)容變化，才會(huì)導(dǎo)致相應(yīng) URL 的變更，從而實(shí)現(xiàn)文件級(jí)別的精確緩存控制。什么東西與文件內(nèi)容相關(guān)呢？我們會(huì)很自然的聯(lián)想到利用數(shù)據(jù)摘要算法對(duì)文件求摘要信息，摘要信息與文件內(nèi)容一一對(duì)應(yīng)，就有了一種可以精確到單個(gè)文件粒度的緩存控制依據(jù)了。

參考資料：

• webpack + express 實(shí)現(xiàn)文件精確緩存
• webpack-緩存
• 張?jiān)讫埁C大公司里怎樣開發(fā)和部署前端代碼？

8. 壓縮文件

壓縮文件可以減少文件下載時(shí)間，讓用戶體驗(yàn)性更好。
得益于 webpack 和 node 的發(fā)展，現(xiàn)在壓縮文件已經(jīng)非常方便了。
在 webpack 可以使用如下插件進(jìn)行壓縮：

• JavaScript：UglifyPlugin
• CSS ：MiniCssExtractPlugin
• HTML：HtmlWebpackPlugin

其實(shí)，我們還可以做得更好。那就是使用 gzip 壓縮。可以通過(guò)向 HTTP 請(qǐng)求頭中的 Accept-Encoding 頭添加 gzip 標(biāo)識(shí)來(lái)開啟這一功能。當(dāng)然，服務(wù)器也得支持這一功能。

gzip 是目前最流行和最有效的壓縮方法。舉個(gè)例子，我用 Vue 開發(fā)的項(xiàng)目構(gòu)建后生成的 app.js 文件大小為 1.4MB，使用 gzip 壓縮后只有 573KB，體積減少了將近 60%。

附上 webpack 和 node 配置 gzip 的使用方法。

下載插件

npm install compression-webpack-plugin --save-dev npm install compression

webpack 配置

const CompressionPlugin = require('compression-webpack-plugin');module.exports = {plugins: [new CompressionPlugin()], }

node 配置

const compression = require('compression') // 在其他中間件前使用 app.use(compression())

9. 圖片優(yōu)化

圖片延遲加載

在頁(yè)面中，先不給圖片設(shè)置路徑，只有當(dāng)圖片出現(xiàn)在瀏覽器的可視區(qū)域時(shí)，才去加載真正的圖片，這就是延遲加載。對(duì)于圖片很多的網(wǎng)站來(lái)說(shuō)，一次性加載全部圖片，會(huì)對(duì)用戶體驗(yàn)造成很大的影響，所以需要使用圖片延遲加載。

首先可以將圖片這樣設(shè)置，在頁(yè)面不可見時(shí)圖片不會(huì)加載：

<img data-src="https://avatars0.githubusercontent.com/u/22117876?s=460&u=7bd8f32788df6988833da6bd155c3cfbebc68006&v=4">

等頁(yè)面可見時(shí)，使用 JS 加載圖片：

const img = document.querySelector('img') img.src = img.dataset.src

這樣圖片就加載出來(lái)了，完整的代碼可以看一下參考資料。

參考資料：

• web 前端圖片懶加載實(shí)現(xiàn)原理

響應(yīng)式圖片

響應(yīng)式圖片的優(yōu)點(diǎn)是瀏覽器能夠根據(jù)屏幕大小自動(dòng)加載合適的圖片。
通過(guò) picture 實(shí)現(xiàn)

<picture><source srcset="banner_w1000.jpg" media="(min-width: 801px)"><source srcset="banner_w800.jpg" media="(max-width: 800px)"><img src="banner_w800.jpg" alt=""> </picture>

通過(guò) @media 實(shí)現(xiàn)

@media (min-width: 769px) {.bg {background-image: url(bg1080.jpg);} } @media (max-width: 768px) {.bg {background-image: url(bg768.jpg);} }

調(diào)整圖片大小

例如，你有一個(gè) 1920 * 1080 大小的圖片，用縮略圖的方式展示給用戶，并且當(dāng)用戶鼠標(biāo)懸停在上面時(shí)才展示全圖。如果用戶從未真正將鼠標(biāo)懸停在縮略圖上，則浪費(fèi)了下載圖片的時(shí)間。

所以，我們可以用兩張圖片來(lái)實(shí)行優(yōu)化。一開始，只加載縮略圖，當(dāng)用戶懸停在圖片上時(shí)，才加載大圖。還有一種辦法，即對(duì)大圖進(jìn)行延遲加載，在所有元素都加載完成后手動(dòng)更改大圖的 src 進(jìn)行下載。

降低圖片質(zhì)量

例如 JPG 格式的圖片，100% 的質(zhì)量和 90% 質(zhì)量的通常看不出來(lái)區(qū)別，尤其是用來(lái)當(dāng)背景圖的時(shí)候。我經(jīng)常用 PS 切背景圖時(shí)， 將圖片切成 JPG 格式，并且將它壓縮到 60% 的質(zhì)量，基本上看不出來(lái)區(qū)別。

壓縮方法有兩種，一是通過(guò) webpack 插件 image-webpack-loader，二是通過(guò)在線網(wǎng)站進(jìn)行壓縮。
以下附上 webpack 插件 image-webpack-loader 的用法。

npm i -D image-webpack-loader

webpack 配置

{test: /\.(png|jpe?g|gif|svg)(\?.*)?$/,use:[{loader: 'url-loader',options: {limit: 10000, /* 圖片大小小于1000字節(jié)限制時(shí)會(huì)自動(dòng)轉(zhuǎn)成 base64 碼引用*/name: utils.assetsPath('img/[name].[hash:7].[ext]')}},/*對(duì)圖片進(jìn)行壓縮*/{loader: 'image-webpack-loader',options: {bypassOnDebug: true,}}] }

盡可能利用 CSS3 效果代替圖片

有很多圖片使用 CSS 效果（漸變、陰影等）就能畫出來(lái)，這種情況選擇 CSS3 效果更好。因?yàn)榇a大小通常是圖片大小的幾分之一甚至幾十分之一。

參考資料：

• img圖片在webpack中使用

使用 webp 格式的圖片

WebP 的優(yōu)勢(shì)體現(xiàn)在它具有更優(yōu)的圖像數(shù)據(jù)壓縮算法，能帶來(lái)更小的圖片體積，而且擁有肉眼識(shí)別無(wú)差異的圖像質(zhì)量；同時(shí)具備了無(wú)損和有損的壓縮模式、Alpha 透明以及動(dòng)畫的特性，在 JPEG 和 PNG 上的轉(zhuǎn)化效果都相當(dāng)優(yōu)秀、穩(wěn)定和統(tǒng)一。

參考資料：

• WebP 相對(duì)于 PNG、JPG 有什么優(yōu)勢(shì)？

10. 通過(guò) webpack 按需加載代碼，提取第三庫(kù)代碼，減少 ES6 轉(zhuǎn)為 ES5 的冗余代碼

懶加載或者按需加載，是一種很好的優(yōu)化網(wǎng)頁(yè)或應(yīng)用的方式。這種方式實(shí)際上是先把你的代碼在一些邏輯斷點(diǎn)處分離開，然后在一些代碼塊中完成某些操作后，立即引用或即將引用另外一些新的代碼塊。這樣加快了應(yīng)用的初始加載速度，減輕了它的總體體積，因?yàn)槟承┐a塊可能永遠(yuǎn)不會(huì)被加載。

根據(jù)文件內(nèi)容生成文件名，結(jié)合 import 動(dòng)態(tài)引入組件實(shí)現(xiàn)按需加載

通過(guò)配置 output 的 filename 屬性可以實(shí)現(xiàn)這個(gè)需求。filename 屬性的值選項(xiàng)中有一個(gè) [contenthash]，它將根據(jù)文件內(nèi)容創(chuàng)建出唯一 hash。當(dāng)文件內(nèi)容發(fā)生變化時(shí)，[contenthash] 也會(huì)發(fā)生變化。

output: {filename: '[name].[contenthash].js',chunkFilename: '[name].[contenthash].js',path: path.resolve(__dirname, '../dist'), },

提取第三方庫(kù)

由于引入的第三方庫(kù)一般都比較穩(wěn)定，不會(huì)經(jīng)常改變。所以將它們單獨(dú)提取出來(lái)，作為長(zhǎng)期緩存是一個(gè)更好的選擇。 這里需要使用 webpack4 的 splitChunk 插件 cacheGroups 選項(xiàng)。

optimization: {runtimeChunk: {name: 'manifest' // 將 webpack 的 runtime 代碼拆分為一個(gè)單獨(dú)的 chunk。},splitChunks: {cacheGroups: {vendor: {name: 'chunk-vendors',test: /[\\/]node_modules[\\/]/,priority: -10,chunks: 'initial'},common: {name: 'chunk-common',minChunks: 2,priority: -20,chunks: 'initial',reuseExistingChunk: true}},} },

• test: 用于控制哪些模塊被這個(gè)緩存組匹配到。原封不動(dòng)傳遞出去的話，它默認(rèn)會(huì)選擇所有的模塊。可以傳遞的值類型：RegExp、String和Function;
• priority：表示抽取權(quán)重，數(shù)字越大表示優(yōu)先級(jí)越高。因?yàn)橐粋€(gè) module 可能會(huì)滿足多個(gè) cacheGroups 的條件，那么抽取到哪個(gè)就由權(quán)重最高的說(shuō)了算；
• reuseExistingChunk：表示是否使用已有的 chunk，如果為 true 則表示如果當(dāng)前的 chunk 包含的模塊已經(jīng)被抽取出去了，那么將不會(huì)重新生成新的。
• minChunks（默認(rèn)是1）：在分割之前，這個(gè)代碼塊最小應(yīng)該被引用的次數(shù)（譯注：保證代碼塊復(fù)用性，默認(rèn)配置的策略是不需要多次引用也可以被分割）
• chunks (默認(rèn)是async) ：initial、async和all
• name(打包的chunks的名字)：字符串或者函數(shù)(函數(shù)可以根據(jù)條件自定義名字)

減少 ES6 轉(zhuǎn)為 ES5 的冗余代碼

Babel 轉(zhuǎn)化后的代碼想要實(shí)現(xiàn)和原來(lái)代碼一樣的功能需要借助一些幫助函數(shù)，比如：

class Person {}

會(huì)被轉(zhuǎn)化為：

"use strict";function _classCallCheck(instance, Constructor) {if (!(instance instanceof Constructor)) {throw new TypeError("Cannot call a class as a function");} }var Person = function Person() {_classCallCheck(this, Person); };

這里 _classCallCheck 就是一個(gè) helper 函數(shù)，如果在很多文件里都聲明了類，那么就會(huì)產(chǎn)生很多個(gè)這樣的 helper 函數(shù)。
這里的 @babel/runtime 包就聲明了所有需要用到的幫助函數(shù)，而 @babel/plugin-transform-runtime 的作用就是將所有需要 helper 函數(shù)的文件，從 @babel/runtime包 引進(jìn)來(lái)：

"use strict";var _classCallCheck2 = require("@babel/runtime/helpers/classCallCheck");var _classCallCheck3 = _interopRequireDefault(_classCallCheck2);function _interopRequireDefault(obj) {return obj && obj.__esModule ? obj : { default: obj }; }var Person = function Person() {(0, _classCallCheck3.default)(this, Person); };

這里就沒(méi)有再編譯出 helper 函數(shù) classCallCheck 了，而是直接引用了 @babel/runtime 中的 helpers/classCallCheck。

安裝

npm i -D @babel/plugin-transform-runtime @babel/runtime

在 babelrc 中使用

"plugins": ["@babel/plugin-transform-runtime" ]

參考資料：

• Babel 7.1介紹 transform-runtime polyfill env
• 懶加載
• Vue 路由懶加載
• webpack 緩存
• 一步一步的了解webpack4的splitChunk插件

11. 減少重繪重排

瀏覽器渲染過(guò)程

解析HTML生成DOM樹。

解析CSS生成CSSOM規(guī)則樹。

解析JS，操作 DOM 樹和 CSSOM 規(guī)則樹。

將DOM樹與CSSOM規(guī)則樹合并在一起生成渲染樹。

遍歷渲染樹開始布局，計(jì)算每個(gè)節(jié)點(diǎn)的位置大小信息。

瀏覽器將所有圖層的數(shù)據(jù)發(fā)送給GPU，GPU將圖層合成并顯示在屏幕上。

重排

當(dāng)改變 DOM 元素位置或大小時(shí)，會(huì)導(dǎo)致瀏覽器重新生成渲染樹，這個(gè)過(guò)程叫重排。

重繪

當(dāng)重新生成渲染樹后，就要將渲染樹每個(gè)節(jié)點(diǎn)繪制到屏幕，這個(gè)過(guò)程叫重繪。不是所有的動(dòng)作都會(huì)導(dǎo)致重排，例如改變字體顏色，只會(huì)導(dǎo)致重繪。記住，重排會(huì)導(dǎo)致重繪，重繪不會(huì)導(dǎo)致重排 。

重排和重繪這兩個(gè)操作都是非常昂貴的，因?yàn)?JavaScript 引擎線程與 GUI 渲染線程是互斥，它們同時(shí)只能一個(gè)在工作。

什么操作會(huì)導(dǎo)致重排？

• 添加或刪除可見的 DOM 元素
• 元素位置改變
• 元素尺寸改變
• 內(nèi)容改變
• 瀏覽器窗口尺寸改變

如何減少重排重繪？

• 用 JavaScript 修改樣式時(shí)，最好不要直接寫樣式，而是替換 class 來(lái)改變樣式。
• 如果要對(duì) DOM 元素執(zhí)行一系列操作，可以將 DOM 元素脫離文檔流，修改完成后，再將它帶回文檔。推薦使用隱藏元素（display:none）或文檔碎片（DocumentFragement），都能很好的實(shí)現(xiàn)這個(gè)方案。

12. 使用事件委托

事件委托利用了事件冒泡，只指定一個(gè)事件處理程序，就可以管理某一類型的所有事件。所有用到按鈕的事件（多數(shù)鼠標(biāo)事件和鍵盤事件）都適合采用事件委托技術(shù)， 使用事件委托可以節(jié)省內(nèi)存。

<ul><li>蘋果</li><li>香蕉</li><li>鳳梨</li> </ul>// good document.querySelector('ul').onclick = (event) => {const target = event.targetif (target.nodeName === 'LI') {console.log(target.innerHTML)} }// bad document.querySelectorAll('li').forEach((e) => {e.onclick = function() {console.log(this.innerHTML)} })

13. 注意程序的局部性

一個(gè)編寫良好的計(jì)算機(jī)程序常常具有良好的局部性，它們傾向于引用最近引用過(guò)的數(shù)據(jù)項(xiàng)附近的數(shù)據(jù)項(xiàng)，或者最近引用過(guò)的數(shù)據(jù)項(xiàng)本身，這種傾向性，被稱為局部性原理。有良好局部性的程序比局部性差的程序運(yùn)行得更快。

局部性通常有兩種不同的形式：

• 時(shí)間局部性：在一個(gè)具有良好時(shí)間局部性的程序中，被引用過(guò)一次的內(nèi)存位置很可能在不遠(yuǎn)的將來(lái)被多次引用。
• 空間局部性 ：在一個(gè)具有良好空間局部性的程序中，如果一個(gè)內(nèi)存位置被引用了一次，那么程序很可能在不遠(yuǎn)的將來(lái)引用附近的一個(gè)內(nèi)存位置。

時(shí)間局部性示例

function sum(arry) {let i, sum = 0let len = arry.lengthfor (i = 0; i < len; i++) {sum += arry[i]}return sum }

在這個(gè)例子中，變量sum在每次循環(huán)迭代中被引用一次，因此，對(duì)于sum來(lái)說(shuō)，具有良好的時(shí)間局部性

空間局部性示例

具有良好空間局部性的程序

// 二維數(shù)組 function sum1(arry, rows, cols) {let i, j, sum = 0for (i = 0; i < rows; i++) {for (j = 0; j < cols; j++) {sum += arry[i][j]}}return sum }

看一下上面的兩個(gè)空間局部性示例，像示例中從每行開始按順序訪問(wèn)數(shù)組每個(gè)元素的方式，稱為具有步長(zhǎng)為1的引用模式。如果在數(shù)組中，每隔k個(gè)元素進(jìn)行訪問(wèn)，就稱為步長(zhǎng)為k的引用模式。一般而言，隨著步長(zhǎng)的增加，空間局部性下降。

這兩個(gè)例子有什么區(qū)別？區(qū)別在于第一個(gè)示例是按行掃描數(shù)組，每掃描完一行再去掃下一行；第二個(gè)示例是按列來(lái)掃描數(shù)組，掃完一行中的一個(gè)元素，馬上就去掃下一行中的同一列元素。

數(shù)組在內(nèi)存中是按照行順序來(lái)存放的，結(jié)果就是逐行掃描數(shù)組的示例得到了步長(zhǎng)為 1 引用模式，具有良好的空間局部性；而另一個(gè)示例步長(zhǎng)為 rows，空間局部性極差。

性能測(cè)試

運(yùn)行環(huán)境：

• cpu: i5-7400
• 瀏覽器: chrome 70.0.3538.110

對(duì)一個(gè)長(zhǎng)度為9000的二維數(shù)組（子數(shù)組長(zhǎng)度也為9000）進(jìn)行10次空間局部性測(cè)試，時(shí)間（毫秒）取平均值，結(jié)果如下：

所用示例為上述兩個(gè)空間局部性示例

步長(zhǎng)為 1步長(zhǎng)為 9000

124	2316

從以上測(cè)試結(jié)果來(lái)看，步長(zhǎng)為 1 的數(shù)組執(zhí)行時(shí)間比步長(zhǎng)為 9000 的數(shù)組快了一個(gè)數(shù)量級(jí)。

總結(jié)：

• 重復(fù)引用相同變量的程序具有良好的時(shí)間局部性
• 對(duì)于具有步長(zhǎng)為 k 的引用模式的程序，步長(zhǎng)越小，空間局部性越好；而在內(nèi)存中以大步長(zhǎng)跳來(lái)跳去的程序空間局部性會(huì)很差

參考資料：

• 深入理解計(jì)算機(jī)系統(tǒng)

14. if-else 對(duì)比 switch

當(dāng)判斷條件數(shù)量越來(lái)越多時(shí)，越傾向于使用 switch 而不是 if-else。

if (color == 'blue') {} else if (color == 'yellow') {} else if (color == 'white') {} else if (color == 'black') {} else if (color == 'green') {} else if (color == 'orange') {} else if (color == 'pink') {}switch (color) {case 'blue':breakcase 'yellow':breakcase 'white':breakcase 'black':breakcase 'green':breakcase 'orange':breakcase 'pink':break }

像以上這種情況，使用 switch 是最好的。假設(shè) color 的值為 pink，則 if-else 語(yǔ)句要進(jìn)行 7 次判斷，switch 只需要進(jìn)行一次判斷。從可讀性來(lái)說(shuō)，switch 語(yǔ)句也更好。

從使用時(shí)機(jī)來(lái)說(shuō)，當(dāng)條件值大于兩個(gè)的時(shí)候，使用 switch 更好。不過(guò) if-else 也有 switch 無(wú)法做到的事情，例如有多個(gè)判斷條件的情況下，無(wú)法使用 switch。

15. 查找表

當(dāng)條件語(yǔ)句特別多時(shí)，使用 switch 和 if-else 不是最佳的選擇，這時(shí)不妨試一下查找表。查找表可以使用數(shù)組和對(duì)象來(lái)構(gòu)建。

switch (index) {case '0':return result0case '1':return result1case '2':return result2case '3':return result3case '4':return result4case '5':return result5case '6':return result6case '7':return result7case '8':return result8case '9':return result9case '10':return result10case '11':return result11 }

可以將這個(gè) switch 語(yǔ)句轉(zhuǎn)換為查找表

const results = [result0,result1,result2,result3,result4,result5,result6,result7,result8,result9,result10,result11] return results[index]

如果條件語(yǔ)句不是數(shù)值而是字符串，可以用對(duì)象來(lái)建立查找表

const map = {red: result0,green: result1, }return map[color]

16. 避免頁(yè)面卡頓

60fps 與設(shè)備刷新率

目前大多數(shù)設(shè)備的屏幕刷新率為 60 次/秒。因此，如果在頁(yè)面中有一個(gè)動(dòng)畫或漸變效果，或者用戶正在滾動(dòng)頁(yè)面，那么瀏覽器渲染動(dòng)畫或頁(yè)面的每一幀的速率也需要跟設(shè)備屏幕的刷新率保持一致。

其中每個(gè)幀的預(yù)算時(shí)間僅比 16 毫秒多一點(diǎn) (1 秒/ 60 = 16.66 毫秒)。但實(shí)際上，瀏覽器有整理工作要做，因此您的所有工作需要在 10 毫秒內(nèi)完成。如果無(wú)法符合此預(yù)算，幀率將下降，并且內(nèi)容會(huì)在屏幕上抖動(dòng)。 此現(xiàn)象通常稱為卡頓，會(huì)對(duì)用戶體驗(yàn)產(chǎn)生負(fù)面影響。

對(duì)于一些長(zhǎng)時(shí)間運(yùn)行的 JavaScript，我們可以使用定時(shí)器進(jìn)行切分，延遲執(zhí)行。

for (let i = 0, len = arry.length; i < len; i++) {process(arry[i]) }

假設(shè)上面的循環(huán)結(jié)構(gòu)由于 process() 復(fù)雜度過(guò)高或數(shù)組元素太多，甚至兩者都有，可以嘗試一下切分。

const todo = arry.concat() setTimeout(function() {process(todo.shift())if (todo.length) {setTimeout(arguments.callee, 25)} else {callback(arry)} }, 25)

如果有興趣了解更多，可以查看一下高性能JavaScript第 6 章和高效前端：Web高效編程與優(yōu)化實(shí)踐第 3 章。

參考資料：

• 渲染性能

17. 使用 requestAnimationFrame 來(lái)實(shí)現(xiàn)視覺變化

從第 16 點(diǎn)我們可以知道，大多數(shù)設(shè)備屏幕刷新率為 60 次/秒，也就是說(shuō)每一幀的平均時(shí)間為 16.66 毫秒。在使用 JavaScript 實(shí)現(xiàn)動(dòng)畫效果的時(shí)候，最好的情況就是每次代碼都是在幀的開頭開始執(zhí)行。而保證 JavaScript 在幀開始時(shí)運(yùn)行的唯一方式是使用 requestAnimationFrame。

/*** If run as a requestAnimationFrame callback, this* will be run at the start of the frame.*/ function updateScreen(time) {// Make visual updates here. }requestAnimationFrame(updateScreen);

如果采取 setTimeout 或 setInterval 來(lái)實(shí)現(xiàn)動(dòng)畫的話，回調(diào)函數(shù)將在幀中的某個(gè)時(shí)點(diǎn)運(yùn)行，可能剛好在末尾，而這可能經(jīng)常會(huì)使我們丟失幀，導(dǎo)致卡頓。

參考資料：

• 優(yōu)化 JavaScript 執(zhí)行

18. 使用 Web Workers

Web Worker 使用其他工作線程從而獨(dú)立于主線程之外，它可以執(zhí)行任務(wù)而不干擾用戶界面。一個(gè) worker 可以將消息發(fā)送到創(chuàng)建它的 JavaScript 代碼, 通過(guò)將消息發(fā)送到該代碼指定的事件處理程序（反之亦然）。

Web Worker 適用于那些處理純數(shù)據(jù)，或者與瀏覽器 UI 無(wú)關(guān)的長(zhǎng)時(shí)間運(yùn)行腳本。

創(chuàng)建一個(gè)新的 worker 很簡(jiǎn)單，指定一個(gè)腳本的 URI 來(lái)執(zhí)行 worker 線程（main.js）：

var myWorker = new Worker('worker.js'); // 你可以通過(guò)postMessage() 方法和onmessage事件向worker發(fā)送消息。 first.onchange = function() {myWorker.postMessage([first.value,second.value]);console.log('Message posted to worker'); }second.onchange = function() {myWorker.postMessage([first.value,second.value]);console.log('Message posted to worker'); }

在 worker 中接收到消息后，我們可以寫一個(gè)事件處理函數(shù)代碼作為響應(yīng)（worker.js）：

onmessage = function(e) {console.log('Message received from main script');var workerResult = 'Result: ' + (e.data[0] * e.data[1]);console.log('Posting message back to main script');postMessage(workerResult); }

onmessage處理函數(shù)在接收到消息后馬上執(zhí)行，代碼中消息本身作為事件的data屬性進(jìn)行使用。這里我們簡(jiǎn)單的對(duì)這2個(gè)數(shù)字作乘法處理并再次使用postMessage()方法，將結(jié)果回傳給主線程。

回到主線程，我們?cè)俅问褂胦nmessage以響應(yīng)worker回傳的消息：

myWorker.onmessage = function(e) {result.textContent = e.data;console.log('Message received from worker'); }

在這里我們獲取消息事件的data，并且將它設(shè)置為result的textContent，所以用戶可以直接看到運(yùn)算的結(jié)果。

不過(guò)在worker內(nèi)，不能直接操作DOM節(jié)點(diǎn)，也不能使用window對(duì)象的默認(rèn)方法和屬性。然而你可以使用大量window對(duì)象之下的東西，包括WebSockets，IndexedDB以及FireFox OS專用的Data Store API等數(shù)據(jù)存儲(chǔ)機(jī)制。

參考資料：

• Web Workers

19. 使用位操作

JavaScript 中的數(shù)字都使用 IEEE-754 標(biāo)準(zhǔn)以 64 位格式存儲(chǔ)。但是在位操作中，數(shù)字被轉(zhuǎn)換為有符號(hào)的 32 位格式。即使需要轉(zhuǎn)換，位操作也比其他數(shù)學(xué)運(yùn)算和布爾操作快得多。

取模
由于偶數(shù)的最低位為 0，奇數(shù)為 1，所以取模運(yùn)算可以用位操作來(lái)代替。

if (value % 2) {// 奇數(shù) } else {// 偶數(shù) } // 位操作 if (value & 1) {// 奇數(shù) } else {// 偶數(shù) }

取整

~~10.12 // 10 ~~10 // 10 ~~'1.5' // 1 ~~undefined // 0 ~~null //

位掩碼

const a = 1 const b = 2 const c = 4 const options = a | b | c

通過(guò)定義這些選項(xiàng)，可以用按位與操作來(lái)判斷 a/b/c 是否在 options 中。

// 選項(xiàng) b 是否在選項(xiàng)中 if (b & options) {... }

20. 不要覆蓋原生方法

無(wú)論你的 JavaScript 代碼如何優(yōu)化，都比不上原生方法。因?yàn)樵椒ㄊ怯玫图?jí)語(yǔ)言寫的（C/C++），并且被編譯成機(jī)器碼，成為瀏覽器的一部分。當(dāng)原生方法可用時(shí)，盡量使用它們，特別是數(shù)學(xué)運(yùn)算和 DOM 操作。

21. 降低 CSS 選擇器的復(fù)雜性

瀏覽器讀取選擇器，遵循的原則是從選擇器的右邊到左邊讀取。

看個(gè)示例

#block .text p {color: red; }

查找所有 P 元素。

查找結(jié)果 1 中的元素是否有類名為 text 的父元素

查找結(jié)果 2 中的元素是否有 id 為 block 的父元素

CSS 選擇器優(yōu)先級(jí)

內(nèi)聯(lián) > ID選擇器 > 類選擇器 > 標(biāo)簽選擇器

根據(jù)以上兩個(gè)信息可以得出結(jié)論。

選擇器越短越好。

盡量使用高優(yōu)先級(jí)的選擇器，例如 ID 和類選擇器。

避免使用通配符 *。

最后要說(shuō)一句，據(jù)我查找的資料所得，CSS 選擇器沒(méi)有優(yōu)化的必要，因?yàn)樽盥吐斓倪x擇器性能差別非常小。

參考資料：

• CSS selector performance
• Optimizing CSS: ID Selectors and Other Myths

22. 使用 flexbox 而不是較早的布局模型

在早期的 CSS 布局方式中我們能對(duì)元素實(shí)行絕對(duì)定位、相對(duì)定位或浮動(dòng)定位。而現(xiàn)在，我們有了新的布局方式 flexbox，它比起早期的布局方式來(lái)說(shuō)有個(gè)優(yōu)勢(shì)，那就是性能比較好。

下面的截圖顯示了在 1300 個(gè)框上使用浮動(dòng)的布局開銷：

然后我們用 flexbox 來(lái)重現(xiàn)這個(gè)例子：

現(xiàn)在，對(duì)于相同數(shù)量的元素和相同的視覺外觀，布局的時(shí)間要少得多（本例中為分別 3.5 毫秒和 14 毫秒）。
不過(guò) flexbox 兼容性還是有點(diǎn)問(wèn)題，不是所有瀏覽器都支持它，所以要謹(jǐn)慎使用。
各瀏覽器兼容性：

• Chrome 29+
• Firefox 28+
• Internet Explorer 11
• Opera 17+
• Safari 6.1+ (prefixed with -webkit-)
• Android 4.4+
• iOS 7.1+ (prefixed with -webkit-)

參考資料：

• 使用 flexbox 而不是較早的布局模型

23. 使用 transform 和 opacity 屬性更改來(lái)實(shí)現(xiàn)動(dòng)畫

在 CSS 中，transforms 和 opacity 這兩個(gè)屬性更改不會(huì)觸發(fā)重排與重繪，它們是可以由合成器（composite）單獨(dú)處理的屬性。

參考資料：

• 使用 transform 和 opacity 屬性更改來(lái)實(shí)現(xiàn)動(dòng)畫

24. 合理使用規(guī)則，避免過(guò)度優(yōu)化

性能優(yōu)化主要分為兩類：

加載時(shí)優(yōu)化

運(yùn)行時(shí)優(yōu)化

上述 23 條建議中，屬于加載時(shí)優(yōu)化的是前面 10 條建議，屬于運(yùn)行時(shí)優(yōu)化的是后面 13 條建議。通常來(lái)說(shuō)，沒(méi)有必要 23 條性能優(yōu)化規(guī)則都用上，根據(jù)網(wǎng)站用戶群體來(lái)做針對(duì)性的調(diào)整是最好的，節(jié)省精力，節(jié)省時(shí)間。

在解決問(wèn)題之前，得先找出問(wèn)題，否則無(wú)從下手。所以在做性能優(yōu)化之前，最好先調(diào)查一下網(wǎng)站的加載性能和運(yùn)行性能。

檢查加載性能

一個(gè)網(wǎng)站加載性能如何主要看白屏?xí)r間和首屏?xí)r間。

• 白屏?xí)r間：指從輸入網(wǎng)址，到頁(yè)面開始顯示內(nèi)容的時(shí)間。
• 首屏?xí)r間：指從輸入網(wǎng)址，到頁(yè)面完全渲染的時(shí)間。

將以下腳本放在 </head> 前面就能獲取白屏?xí)r間。

<script>new Date() - performance.timing.navigationStart </script>

在 window.onload 事件里執(zhí)行 new Date() - performance.timing.navigationStart 即可獲取首屏?xí)r間。

檢查運(yùn)行性能

配合 chrome 的開發(fā)者工具，我們可以查看網(wǎng)站在運(yùn)行時(shí)的性能。

打開網(wǎng)站，按 F12 選擇 performance，點(diǎn)擊左上角的灰色圓點(diǎn)，變成紅色就代表開始記錄了。這時(shí)可以模仿用戶使用網(wǎng)站，在使用完畢后，點(diǎn)擊 stop，然后你就能看到網(wǎng)站運(yùn)行期間的性能報(bào)告。如果有紅色的塊，代表有掉幀的情況；如果是綠色，則代表 FPS 很好。performance 的具體使用方法請(qǐng)用搜索引擎搜索一下，畢竟篇幅有限。

通過(guò)檢查加載和運(yùn)行性能，相信你對(duì)網(wǎng)站性能已經(jīng)有了大概了解。所以這時(shí)候要做的事情，就是使用上述 23 條建議盡情地去優(yōu)化你的網(wǎng)站，加油！

參考資料：

• performance.timing.navigationStart

其他參考資料

• 性能為何至關(guān)重要
• 高性能網(wǎng)站建設(shè)指南
• Web性能權(quán)威指南
• 高性能JavaScript
• 高效前端：Web高效編程與優(yōu)化實(shí)踐

特別說(shuō)明，文章轉(zhuǎn)載：https://juejin.cn/post/6892994632968306702

總結(jié)

以上是生活随笔為你收集整理的前端性能优化 24 条建议的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。