性能優(yōu)化是把雙刃劍臊泰，有好的一面也有壞的一面。好的一面就是能提升網(wǎng)站性能蚜枢，壞的一面就是配置麻煩缸逃，或者要遵守的規(guī)則太多。并且某些性能優(yōu)化規(guī)則并不適用所有場景厂抽，需要謹慎使用需频，請讀者帶著批判性的眼光來閱讀本文。

1修肠、減少 HTTP 請求

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

image.png

這是一個 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é)的時間總和铜跑，它包含了 DNS 解析時- 間门怪、 TCP 連接時間、發(fā)送 HTTP 請求時間和獲得響應消息第一個字節(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)建一張表：

如果服務器收到了請求，它會照樣創(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 了亿柑，例如知乎：

image.png

其中 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-demo
• Vue.js 服務器端渲染指南

4车海、靜態(tài)資源使用CDN

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

CDN 原理

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

1. 瀏覽器要將域名解析為 IP 地址哟冬，所以需要向本地 DNS 發(fā)出請求。
2. 本地 DNS 依次向根服務器忆绰、頂級域名服務器浩峡、權限服務器發(fā)出請求，得到網(wǎng)站服務器的 IP 地址错敢。

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

   
   
   image.png

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

1. 瀏覽器要將域名解析為 IP 地址纸淮，所以需要向本地 DNS 發(fā)出請求。
2. 本地 DNS 依次向根服務器亚享、頂級域名服務器咽块、權限服務器發(fā)出請求，得到全局負載均衡系統(tǒng)（GSLB）的 IP 地址欺税。
3. 本地 DNS 再向 GSLB 發(fā)出請求侈沪，GSLB 的主要功能是根據(jù)本地 DNS 的 IP 地址判斷用戶的位置，篩選出距離用戶較近的本地負載均衡系統(tǒng)（SLB）晚凿，并將該 SLB 的 IP 地址作為結(jié)果返回給本地 DNS亭罪。
4. 本地 DNS 將 SLB 的 IP 地址發(fā)回給瀏覽器，瀏覽器向 SLB 發(fā)出請求歼秽。
5. SLB 根據(jù)瀏覽器請求的資源和地址应役，選出最優(yōu)的緩存服務器發(fā)回給瀏覽器燥筷。
6. 瀏覽器再根據(jù) SLB 發(fā)回的地址重定向到緩存服務器肆氓。
7. 如果緩存服務器有瀏覽器需要的資源袍祖，就將資源發(fā)回給瀏覽器做院。如果沒有濒持，就向源服務器請求資源，再發(fā)給瀏覽器并緩存在本地柑营。

image.png

參考資料：

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

5站刑、將 CSS 放在文件頭部绞旅，JavaScript 文件放在底部

所有放在 head 標簽里的 CSS 和 JS 文件都會堵塞渲染因悲。如果這些 CSS 和 JS 需要加載和解析很久的話晃琳，那么頁面就空白了卫旱。所以 JS 文件要放在底部，等 HTML 解析完了再加載 JS 文件誊涯。

那為什么 CSS 文件還要放在頭部呢？

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

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

6蟆盐、使用字體圖標 iconfont 代替圖片圖標

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

壓縮字體文件

使用 fontmin-webpack 插件對字體文件進行壓縮（感謝前端小偉提供）。

image.png

參考資料：

• 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ā)的項目構建后生成的 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)化

1. 圖片延遲加載

在頁面中，先不給圖片設置路徑低匙，只有當圖片出現(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)原理

2. 響應式圖片

響應式圖片的優(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);
    }
}

3. 調(diào)整圖片大小

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

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

4. 降低圖片質(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,
      }
    }
  ]
}

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

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

參考資料：

• img圖片在webpack中使用

6. 使用 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：表示抽取權重，數(shù)字越大表示優(yōu)先級越高娩嚼。因為一個 module 可能會滿足多個 cacheGroups 的條件蘑险，那么抽取到哪個就由權重最高的說了算；
• 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</font> 的作用就是將所有需要 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唆鸡、減少重繪重排

瀏覽器渲染過程

1. 解析HTML生成DOM樹涝影。
2. 解析CSS生成CSSOM規(guī)則樹。
3. 將DOM樹與CSSOM規(guī)則樹合并在一起生成渲染樹争占。
4. 遍歷渲染樹開始布局燃逻，計算每個節(jié)點的位置大小信息。
5. 將渲染樹每個節(jié)點繪制到屏幕臂痕。

image.png

重排

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

重繪

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

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

什么操作會導致重排喊递？

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

如何減少重排重繪随闪？

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

12. 使用事件委托

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

<ul>
  <li>蘋果</li>
  <li>香蕉</li>
  <li>鳳梨</li>
</ul>

// good
document.querySelector('ul').onclick = (event) => {
  const target = event.target
  if (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 = 0
    let len = arry.length

    for (i = 0; i < len; i++) {
        sum += arry[i]
    }

    return sum
}

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

空間局部性示例

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

// 二維數(shù)組 
function sum1(arry, rows, cols) {
    let i, j, sum = 0

    for (i = 0; i < rows; i++) {
        for (j = 0; j < cols; j++) {
            sum += arry[i][j]
        }
    }
    return sum
}

空間局部性差的程序

// 二維數(shù)組 
function sum2(arry, rows, cols) {
    let i, j, sum = 0

    for (j = 0; j < cols; j++) {
        for (i = 0; i < rows; i++) {
            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é)果如下：

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

從以上測試結(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':

        break
    case 'yellow':

        break
    case 'white':

        break
    case 'black':

        break
    case 'green':

        break
    case 'orange':

        break
    case 'pink':

        break
}

像以上這種情況吸占，使用 switch 是最好的。假設 color 的值為 pink凿宾，則 if-else 語句要進行 7 次判斷矾屯，switch 只需要進行一次判斷。 從可讀性來說初厚，switch 語句也更好件蚕。

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

15、查找表

當條件語句特別多時楞件，使用 switch 和 if-else 不是最佳的選擇衫生，這時不妨試一下查找表裳瘪。查找表可以使用數(shù)組和對象來構建。

switch (index) {
    case '0':
        return result0
    case '1':
        return result1
    case '2':
        return result2
    case '3':
        return result3
    case '4':
        return result4
    case '5':
        return result5
    case '6':
        return result6
    case '7':
        return result7
    case '8':
        return result8
    case '9':
        return result9
    case '10':
        return result10
    case '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)生負面影響粱甫。

image.png

假如你用 JavaScript 修改了 DOM泳叠，并觸發(fā)樣式修改，經(jīng)歷重排重繪最后畫到屏幕上茶宵。如果這其中任意一項的執(zhí)行時間過長危纫，都會導致渲染這一幀的時間過長，平均幀率就會下降乌庶。假設這一幀花了 50 ms种蝶，那么此時的幀率為 1s / 50ms = 20fps，頁面看起來就像卡頓了一樣瞒大。

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

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

假設上面的循環(huán)結(jié)構由于 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)常會使我們丟失幀，導致卡頓翻翩。

image.png

參考資料：

• 優(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 // 0

位掩碼

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 選擇器的復雜性

1. 瀏覽器讀取選擇器畸裳，遵循的原則是從選擇器的右邊到左邊讀取缰犁。

看個示例

#block .text p {
    color: red;
}

1. 查找所有 P 元素。
2. 查找結(jié)果 1 中的元素是否有類名為 text 的父元素
3. 查找結(jié)果 2 中的元素是否有 id 為 block 的父元素

2. 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 個框上使用浮動的布局開銷：

image.png

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

image.png

現(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)化主要分為兩類：

1. 加載時優(yōu)化
2. 運行時優(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性能權威指南
• 高性能JavaScript
• 高效前端：Web高效編程與優(yōu)化實踐

作者：譚光志
鏈接：https://juejin.cn/post/6892994632968306702
來源：掘金