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

1. 減少 HTTP 請求

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

這是一個 HTTP 請求，請求的文件大小為 28.4KB。

名詞解釋：

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

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

參考資料：understanding-resource-timing

2. 使用 HTTP2

HTTP2 相比 HTTP1.1 有如下幾個優(yōu)點：

解析速度快

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

多路復用

HTTP1.1 如果要同時發(fā)起多個請求，就得建立多個 TCP 連接，因為一個 TCP 連接同時只能處理一個 HTTP1.1 的請求。

在 HTTP2 上，多個請求可以共用一個 TCP 連接，這稱為多路復用。同一個請求和響應用一個流來表示，并有唯一的流 ID 來標識。多個請求和響應在 TCP 連接中可以亂序發(fā)送，到達目的地后再通過流 ID 重新組建。

首部壓縮

HTTP2 提供了首部壓縮功能。

例如有如下兩個請求：

: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

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

HTTP/2 在客戶端和服務器端使用“首部表”來跟蹤和存儲之前發(fā)送的鍵－值對，對于相同的數(shù)據(jù)，不再通過每次請求和響應發(fā)送。

下面再來看一個簡化的例子，假設客戶端按順序發(fā)送如下請求首部：

Header1:foo Header2:bar Header3:bat

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

索引首部名稱值

62	Header1	foo
63	Header2	bar
64	Header3	bat

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

62 63 64

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

優(yōu)先級

HTTP2 可以對比較緊急的請求設置一個較高的優(yōu)先級，服務器在收到這樣的請求后，可以優(yōu)先處理。

流量控制

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

服務器推送

HTTP2 新增的一個強大的新功能，就是服務器可以對一個客戶端請求發(fā)送多個響應。換句話說，除了對最初請求的響應外，服務器還可以額外向客戶端推送資源，而無需客戶端明確地請求。

例如當瀏覽器請求一個網(wǎng)站時，除了返回 HTML 頁面外，服務器還可以根據(jù) HTML 頁面中的資源的 URL，來提前推送資源。

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

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

參考資料：

• HTTP2 簡介
• 半小時搞懂 HTTP、HTTPS和HTTP2

3. 使用服務端渲染

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

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

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

下面我用 Vue SSR 做示例，簡單的描述一下 SSR 過程。

客戶端渲染過程

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

服務器返回一個包含了引入資源語句和 <div id="app"></div> 的 HTML 文件。

客戶端通過 HTTP 向服務器請求資源，當必要的資源都加載完畢后，執(zhí)行 new Vue() 開始實例化并渲染頁面。

服務端渲染過程

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

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

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

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

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

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

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

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

CDN原理

當用戶訪問一個網(wǎng)站時，如果沒有 CDN，過程是這樣的：

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

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

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

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

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

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

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

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

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

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

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

參考資料：

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

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

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

那為什么 CSS 文件還要放在頭部呢？
因為先加載 HTML 再加載 CSS，會讓用戶第一時間看到的頁面是沒有樣式的、“丑陋”的，為了避免這種情況發(fā)生，就要將 CSS 文件放在頭部了。

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

6. 使用字體圖標 iconfont 代替圖片圖標

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

壓縮字體文件

使用 fontmin-webpack 插件對字體文件進行壓縮。

參考資料：

• fontmin-webpack
• Iconfont-阿里巴巴矢量圖標庫

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

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

不過這樣會產(chǎn)生一個問題，當文件更新了怎么辦？怎么通知瀏覽器重新請求文件？

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

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

參考資料：

• webpack + express 實現(xiàn)文件精確緩存
• webpack-緩存
• 張云龍–大公司里怎樣開發(fā)和部署前端代碼？

8. 壓縮文件

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

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

其實，我們還可以做得更好。那就是使用 gzip 壓縮。可以通過向 HTTP 請求頭中的 Accept-Encoding 頭添加 gzip 標識來開啟這一功能。當然，服務器也得支持這一功能。

gzip 是目前最流行和最有效的壓縮方法。舉個例子，我用 Vue 開發(fā)的項目構(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)化

圖片延遲加載

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

首先可以將圖片這樣設置，在頁面不可見時圖片不會加載：

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

等頁面可見時，使用 JS 加載圖片：

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

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

參考資料：

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

響應式圖片

響應式圖片的優(yōu)點是瀏覽器能夠根據(jù)屏幕大小自動加載合適的圖片。
通過 picture 實現(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>

通過 @media 實現(xiàn)

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

調(diào)整圖片大小

例如，你有一個 1920 * 1080 大小的圖片，用縮略圖的方式展示給用戶，并且當用戶鼠標懸停在上面時才展示全圖。如果用戶從未真正將鼠標懸停在縮略圖上，則浪費了下載圖片的時間。

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

降低圖片質(zhì)量

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

壓縮方法有兩種，一是通過 webpack 插件 image-webpack-loader，二是通過在線網(wǎng)站進行壓縮。
以下附上 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é)限制時會自動轉(zhuǎn)成 base64 碼引用*/name: utils.assetsPath('img/[name].[hash:7].[ext]')}},/*對圖片進行壓縮*/{loader: 'image-webpack-loader',options: {bypassOnDebug: true,}}] }

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

有很多圖片使用 CSS 效果（漸變、陰影等）就能畫出來，這種情況選擇 CSS3 效果更好。因為代碼大小通常是圖片大小的幾分之一甚至幾十分之一。

參考資料：

• img圖片在webpack中使用

使用 webp 格式的圖片

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

參考資料：

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

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

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

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

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

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

提取第三方庫

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

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

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

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

class Person {}

會被轉(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 就是一個 helper 函數(shù)，如果在很多文件里都聲明了類，那么就會產(chǎn)生很多個這樣的 helper 函數(shù)。
這里的 @babel/runtime 包就聲明了所有需要用到的幫助函數(shù)，而 @babel/plugin-transform-runtime 的作用就是將所有需要 helper 函數(shù)的文件，從 @babel/runtime包 引進來：

"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); };

這里就沒有再編譯出 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. 減少重繪重排

瀏覽器渲染過程

解析HTML生成DOM樹。

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

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

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

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

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

重排

當改變 DOM 元素位置或大小時，會導致瀏覽器重新生成渲染樹，這個過程叫重排。

重繪

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

重排和重繪這兩個操作都是非常昂貴的，因為 JavaScript 引擎線程與 GUI 渲染線程是互斥，它們同時只能一個在工作。

什么操作會導致重排？

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

如何減少重排重繪？

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

12. 使用事件委托

事件委托利用了事件冒泡，只指定一個事件處理程序，就可以管理某一類型的所有事件。所有用到按鈕的事件（多數(shù)鼠標事件和鍵盤事件）都適合采用事件委托技術(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. 注意程序的局部性

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

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

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

時間局部性示例

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

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

空間局部性示例

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

// 二維數(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 }

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

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

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

性能測試

運行環(huán)境：

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

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

所用示例為上述兩個空間局部性示例

步長為 1步長為 9000

124	2316

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

總結(jié)：

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

參考資料：

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

14. if-else 對比 switch

當判斷條件數(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 是最好的。假設 color 的值為 pink，則 if-else 語句要進行 7 次判斷，switch 只需要進行一次判斷。從可讀性來說，switch 語句也更好。

從使用時機來說，當條件值大于兩個的時候，使用 switch 更好。不過 if-else 也有 switch 無法做到的事情，例如有多個判斷條件的情況下，無法使用 switch。

15. 查找表

當條件語句特別多時，使用 switch 和 if-else 不是最佳的選擇，這時不妨試一下查找表。查找表可以使用數(shù)組和對象來構(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 }

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

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

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

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

16. 避免頁面卡頓

60fps 與設備刷新率

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

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

對于一些長時間運行的 JavaScript，我們可以使用定時器進行切分，延遲執(zhí)行。

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

假設上面的循環(huán)結(jié)構(gòu)由于 process() 復雜度過高或數(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)化實踐第 3 章。

參考資料：

• 渲染性能

17. 使用 requestAnimationFrame 來實現(xiàn)視覺變化

從第 16 點我們可以知道，大多數(shù)設備屏幕刷新率為 60 次/秒，也就是說每一幀的平均時間為 16.66 毫秒。在使用 JavaScript 實現(xiàn)動畫效果的時候，最好的情況就是每次代碼都是在幀的開頭開始執(zhí)行。而保證 JavaScript 在幀開始時運行的唯一方式是使用 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 來實現(xiàn)動畫的話，回調(diào)函數(shù)將在幀中的某個時點運行，可能剛好在末尾，而這可能經(jīng)常會使我們丟失幀，導致卡頓。

參考資料：

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

18. 使用 Web Workers

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

Web Worker 適用于那些處理純數(shù)據(jù)，或者與瀏覽器 UI 無關的長時間運行腳本。

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

var myWorker = new Worker('worker.js'); // 你可以通過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 中接收到消息后，我們可以寫一個事件處理函數(shù)代碼作為響應（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屬性進行使用。這里我們簡單的對這2個數(shù)字作乘法處理并再次使用postMessage()方法，將結(jié)果回傳給主線程。

回到主線程，我們再次使用onmessage以響應worker回傳的消息：

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

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

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

參考資料：

• Web Workers

19. 使用位操作

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

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

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

通過定義這些選項，可以用按位與操作來判斷 a/b/c 是否在 options 中。

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

20. 不要覆蓋原生方法

無論你的 JavaScript 代碼如何優(yōu)化，都比不上原生方法。因為原生方法是用低級語言寫的（C/C++），并且被編譯成機器碼，成為瀏覽器的一部分。當原生方法可用時，盡量使用它們，特別是數(shù)學運算和 DOM 操作。

21. 降低 CSS 選擇器的復雜性

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

看個示例

#block .text p {color: red; }

查找所有 P 元素。

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

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

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

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

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

選擇器越短越好。

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

避免使用通配符 *。

最后要說一句，據(jù)我查找的資料所得，CSS 選擇器沒有優(yōu)化的必要，因為最慢和慢快的選擇器性能差別非常小。

參考資料：

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

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

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

下面的截圖顯示了在 1300 個框上使用浮動的布局開銷：

然后我們用 flexbox 來重現(xiàn)這個例子：

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

• 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 屬性更改來實現(xiàn)動畫

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

參考資料：

• 使用 transform 和 opacity 屬性更改來實現(xiàn)動畫

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

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

加載時優(yōu)化

運行時優(yōu)化

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

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

檢查加載性能

一個網(wǎng)站加載性能如何主要看白屏時間和首屏時間。

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

將以下腳本放在 </head> 前面就能獲取白屏時間。

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

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

檢查運行性能

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

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

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

參考資料：

• performance.timing.navigationStart

其他參考資料

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

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

總結(jié)

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

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