前端性能优化建议,24条
目錄
- 一級(jí)目錄
- 1. 減少 HTTP 請(qǐng)求
- 2. 使用 HTTP2
- 3. 使用服務(wù)端渲染
- 4. 靜態(tài)資源使用 CDN
- 5. 將 CSS 放在文件頭部，JavaScript 文件放在底部
- 6. 使用字體圖標(biāo) iconfont 代替圖片圖標(biāo)
- 7. 善用緩存，不重復(fù)加載相同的資源
- 8. 壓縮文件
- 9. 圖片優(yōu)化
- 10. 通過 webpack 按需加載代碼，提取第三庫代碼，減少 ES6 轉(zhuǎn)為 ES5 的冗余代碼
- 11. 減少重繪重排
- 12. 使用事件委托
- 13. 注意程序的局部性
- 14. if-else 對(duì)比 switch
- 15. 查找表
- 16. 避免頁面卡頓
- 17. 使用 requestAnimationFrame 來實(shí)現(xiàn)視覺變化
- 18. 使用 Web Workers
- 19. 使用位操作
- 20. 不要覆蓋原生方法
- 21. 降低 CSS 選擇器的復(fù)雜性
- 22. 使用 flexbox 而不是較早的布局模型
- 23. 使用 transform 和 opacity 屬性更改來實(shí)現(xiàn)動(dòng)畫
- 24. 合理使用規(guī)則，避免過度優(yōu)化
一級(jí)目錄
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)等過程。接下來看一個(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í)間，頁面上的每個(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ā)出頁面請(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ù)的原因。
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è)幀都有表示幀長度的字段。
多路復(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è)流來表示，并有唯一的流 ID 來標(biāo)識(shí)。多個(gè)請(qǐng)求和響應(yīng)在 TCP 連接中可以亂序發(fā)送，到達(dá)目的地后再通過流 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)求可以看出來，有很多數(shù)據(jù)都是重復(fù)的。如果可以把相同的首部存儲(chǔ)起來，僅發(fā)送它們之間不同的部分，就可以節(jié)省不少的流量，加快請(qǐng)求的時(shí)間。
HTTP/2 在客戶端和服務(wù)器端使用“首部表”來跟蹤和存儲(chǔ)之前發(fā)送的鍵－值對(duì)，對(duì)于相同的數(shù)據(jù)，不再通過每次請(qǐng)求和響應(yīng)發(fā)送。
下面再來看一個(gè)簡化的例子，假設(shè)客戶端按順序發(fā)送如下請(qǐng)求首部：
Header1:foo Header2:bar Header3:bat當(dāng)客戶端發(fā)送請(qǐng)求時(shí)，它會(huì)根據(jù)首部值創(chuàng)建一張表：
索引 首部名稱 值
| 62 | Header1 |
| 63 | Header2 |
| 64 | Header3 |
如果服務(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)。換句話說，除了對(duì)最初請(qǐng)求的響應(yīng)外，服務(wù)器還可以額外向客戶端推送資源，而無需客戶端明確地請(qǐng)求。
例如當(dāng)瀏覽器請(qǐng)求一個(gè)網(wǎng)站時(shí)，除了返回 HTML 頁面外，服務(wù)器還可以根據(jù) HTML 頁面中的資源的 URL，來提前推送資源。
現(xiàn)在有很多網(wǎng)站已經(jīng)開始使用 HTTP2 了，例如知乎：
其中 h2 是指 HTTP2 協(xié)議，http/1.1 則是指 HTTP1.1 協(xié)議。
3. 使用服務(wù)端渲染
客戶端渲染: 獲取 HTML 文件，根據(jù)需要下載 JavaScript 文件，運(yùn)行文件，生成 DOM，再渲染。
服務(wù)端渲染：服務(wù)端返回 HTML 文件，客戶端只需解析 HTML。
- 優(yōu)點(diǎn)：首屏渲染快，SEO 好。
- 缺點(diǎn)：配置麻煩，增加了服務(wù)器的計(jì)算壓力。
下面我用 Vue SSR 做示例，簡單的描述一下 SSR 過程。
客戶端渲染過程
服務(wù)端渲染過程
從上述兩個(gè)過程中可以看出，區(qū)別就在于第二步。客戶端渲染的網(wǎng)站會(huì)直接返回 HTML 文件，而服務(wù)端渲染的網(wǎng)站則會(huì)渲染完頁面再返回這個(gè) HTML 文件。
這樣做的好處是什么？是更快的內(nèi)容到達(dá)時(shí)間 (time-to-content)。
假設(shè)你的網(wǎng)站需要加載完 abcd 四個(gè)文件才能渲染完畢。并且每個(gè)文件大小為 1 M。
這樣一算：客戶端渲染的網(wǎng)站需要加載 4 個(gè)文件和 HTML 文件才能完成首頁渲染，總計(jì)大小為 4M（忽略 HTML 文件大小）。而服務(wù)端渲染的網(wǎng)站只需要加載一個(gè)渲染完畢的 HTML 文件就能完成首頁渲染，總計(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 就是為了解決這一問題，在多個(gè)位置部署服務(wù)器，讓用戶離服務(wù)器更近，從而縮短請(qǐng)求時(shí)間。
CDN 原理
當(dāng)用戶訪問一個(gè)網(wǎng)站時(shí)，如果沒有 CDN，過程是這樣的：
如果用戶訪問的網(wǎng)站部署了 CDN，過程是這樣的：
5. 將 CSS 放在文件頭部，JavaScript 文件放在底部
所有放在 head 標(biāo)簽里的 CSS 和 JS 文件都會(huì)堵塞渲染（CSS 不會(huì)阻塞 DOM 解析）。如果這些 CSS 和 JS 需要加載和解析很久的話，那么頁面就空白了。所以 JS 文件要放在底部，等 HTML 解析完了再加載 JS 文件。
那為什么 CSS 文件還要放在頭部呢？
因?yàn)橄燃虞d HTML 再加載 CSS，會(huì)讓用戶第一時(shí)間看到的頁面是沒有樣式的、“丑陋”的，為了避免這種情況發(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)行壓縮。
7. 善用緩存，不重復(fù)加載相同的資源
為了避免用戶每次訪問網(wǎng)站都得請(qǐng)求文件，我們可以通過添加 Expires 或 max-age 來控制這一行為。Expires 設(shè)置了一個(gè)時(shí)間，只要在這個(gè)時(shí)間之前，瀏覽器都不會(huì)請(qǐng)求文件，而是直接使用緩存。而 max-age 是一個(gè)相對(duì)時(shí)間，建議使用 max-age 代替 Expires 。
不過這樣會(huì)產(chǎn)生一個(gè)問題，當(dāng)文件更新了怎么辦？怎么通知瀏覽器重新請(qǐng)求文件？
可以通過更新頁面中引用的資源鏈接地址，讓瀏覽器主動(dòng)放棄緩存，加載新資源。
具體做法是把資源地址 URL 的修改與文件內(nèi)容關(guān)聯(lián)起來，也就是說，只有文件內(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ù)了。
8. 壓縮文件
壓縮文件可以減少文件下載時(shí)間，讓用戶體驗(yàn)性更好。
得益于 webpack 和 node 的發(fā)展，現(xiàn)在壓縮文件已經(jīng)非常方便了。
在 webpack 可以使用如下插件進(jìn)行壓縮：
- JavaScript：UglifyPlugin
- CSS ：MiniCssExtractPlugin
- HTML：HtmlWebpackPlugin
其實(shí)，我們還可以做得更好。那就是使用 gzip 壓縮。可以通過向 HTTP 請(qǐng)求頭中的 Accept-Encoding 頭添加 gzip 標(biāo)識(shí)來開啟這一功能。當(dāng)然，服務(wù)器也得支持這一功能。
gzip 是目前最流行和最有效的壓縮方法。舉個(gè)例子，我用 Vue 開發(fā)的項(xiàng)目構(gòu)建后生成的 app.js 文件大小為 1.4MB，使用 gzip 壓縮后只有 573KB，體積減少了將近 60%。
附上 webpack 和 node 配置 gzip 的使用方法。
下載插件
webpack 配置
const CompressionPlugin = require('compression-webpack-plugin');module.exports = {plugins: [new CompressionPlugin()], }node 配置
const compression = require('compression') // 在其他中間件前使用 app.use(compression())9. 圖片優(yōu)化
(1). 圖片延遲加載
在頁面中，先不給圖片設(shè)置路徑，只有當(dāng)圖片出現(xiàn)在瀏覽器的可視區(qū)域時(shí)，才去加載真正的圖片，這就是延遲加載。對(duì)于圖片很多的網(wǎng)站來說，一次性加載全部圖片，會(huì)對(duì)用戶體驗(yàn)造成很大的影響，所以需要使用圖片延遲加載。
首先可以將圖片這樣設(shè)置，在頁面不可見時(shí)圖片不會(huì)加載：
<img data-src="https://avatars0.githubusercontent.com/u/22117876?s=460&u=7bd8f32788df6988833da6bd155c3cfbebc68006&v=4">等頁面可見時(shí)，使用 JS 加載圖片：
const img = document.querySelector('img') img.src = img.dataset.src這樣圖片就加載出來了。
(2). 響應(yīng)式圖片
響應(yīng)式圖片的優(yōu)點(diǎn)是瀏覽器能夠根據(jù)屏幕大小自動(dòng)加載合適的圖片。
通過 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>通過 @media 實(shí)現(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)整圖片大小
例如，你有一個(gè) 1920 * 1080 大小的圖片，用縮略圖的方式展示給用戶，并且當(dāng)用戶鼠標(biāo)懸停在上面時(shí)才展示全圖。如果用戶從未真正將鼠標(biāo)懸停在縮略圖上，則浪費(fèi)了下載圖片的時(shí)間。
所以，我們可以用兩張圖片來實(shí)行優(yōu)化。一開始，只加載縮略圖，當(dāng)用戶懸停在圖片上時(shí)，才加載大圖。還有一種辦法，即對(duì)大圖進(jìn)行延遲加載，在所有元素都加載完成后手動(dòng)更改大圖的 src 進(jìn)行下載。
(4). 降低圖片質(zhì)量
例如 JPG 格式的圖片，100% 的質(zhì)量和 90% 質(zhì)量的通常看不出來區(qū)別，尤其是用來當(dāng)背景圖的時(shí)候。我經(jīng)常用 PS 切背景圖時(shí)， 將圖片切成 JPG 格式，并且將它壓縮到 60% 的質(zhì)量，基本上看不出來區(qū)別。
壓縮方法有兩種，一是通過 webpack 插件image-webpack-loader，二是通過在線網(wǎng)站進(jìn)行壓縮。
以下附上 webpack 插件 image-webpack-loader 的用法。
npm i -D image-webpack-loaderwebpack 配置
{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,}}] }(5). 盡可能利用 CSS3 效果代替圖片
有很多圖片使用 CSS 效果（漸變、陰影等）就能畫出來，這種情況選擇 CSS3 效果更好。因?yàn)榇a大小通常是圖片大小的幾分之一甚至幾十分之一。
(6). 使用 webp 格式的圖片
WebP 的優(yōu)勢體現(xiàn)在它具有更優(yōu)的圖像數(shù)據(jù)壓縮算法，能帶來更小的圖片體積，而且擁有肉眼識(shí)別無差異的圖像質(zhì)量；同時(shí)具備了無損和有損的壓縮模式、Alpha 透明以及動(dòng)畫的特性，在 JPEG 和 PNG 上的轉(zhuǎn)化效果都相當(dāng)優(yōu)秀、穩(wěn)定和統(tǒng)一。
參考資料：
WebP 相對(duì)于 PNG、JPG 有什么優(yōu)勢？
10. 通過 webpack 按需加載代碼，提取第三庫代碼，減少 ES6 轉(zhuǎn)為 ES5 的冗余代碼
懶加載或者按需加載，是一種很好的優(yōu)化網(wǎng)頁或應(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)按需加載
通過配置 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ā)生變化。
提取第三方庫
由于引入的第三方庫一般都比較穩(wěn)定，不會(huì)經(jīng)常改變。所以將它們單獨(dú)提取出來，作為長期緩存是一個(gè)更好的選擇。這里需要使用 webpack4 的 splitChunk 插件 cacheGroups 選項(xiàng)。
- 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)重最高的說了算；
- 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)和原來代碼一樣的功能需要借助一些幫助函數(shù)，比如：
會(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)來：
"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" ]11. 減少重繪重排
瀏覽器渲染過程
重排
當(dāng)改變 DOM 元素位置或大小時(shí)，會(huì)導(dǎo)致瀏覽器重新生成渲染樹，這個(gè)過程叫重排。
重繪
當(dāng)重新生成渲染樹后，就要將渲染樹每個(gè)節(jié)點(diǎn)繪制到屏幕，這個(gè)過程叫重繪。不是所有的動(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 來改變樣式。
- 如果要對(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ī)程序常常具有良好的局部性，它們傾向于引用最近引用過的數(shù)據(jù)項(xiàng)附近的數(shù)據(jù)項(xiàng)，或者最近引用過的數(shù)據(jù)項(xiàng)本身，這種傾向性，被稱為局部性原理。有良好局部性的程序比局部性差的程序運(yùn)行得更快。
局部性通常有兩種不同的形式：
- 時(shí)間局部性：在一個(gè)具有良好時(shí)間局部性的程序中，被引用過一次的內(nèi)存位置很可能在不遠(yuǎn)的將來被多次引用。
- 空間局部性 ：在一個(gè)具有良好空間局部性的程序中，如果一個(gè)內(nèi)存位置被引用了一次，那么程序很可能在不遠(yuǎn)的將來引用附近的一個(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來說，具有良好的時(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 }空間局部性差的程序
// 二維數(shù)組 function sum2(arry, rows, cols) {let i, j, sum = 0for (j = 0; j < cols; j++) {for (i = 0; i < rows; i++) {sum += arry[i][j]}}return sum }看一下上面的兩個(gè)空間局部性示例，像示例中從每行開始按順序訪問數(shù)組每個(gè)元素的方式，稱為具有步長為1的引用模式。如果在數(shù)組中，每隔k個(gè)元素進(jìn)行訪問，就稱為步長為k的引用模式。一般而言，隨著步長的增加，空間局部性下降。
這兩個(gè)例子有什么區(qū)別？區(qū)別在于第一個(gè)示例是按行掃描數(shù)組，每掃描完一行再去掃下一行；第二個(gè)示例是按列來掃描數(shù)組，掃完一行中的一個(gè)元素，馬上就去掃下一行中的同一列元素。
數(shù)組在內(nèi)存中是按照行順序來存放的，結(jié)果就是逐行掃描數(shù)組的示例得到了步長為 1 引用模式，具有良好的空間局部性；而另一個(gè)示例步長為 rows，空間局部性極差。
性能測試
運(yùn)行環(huán)境：
cpu: i5-7400
瀏覽器: chrome 70.0.3538.110
對(duì)一個(gè)長度為9000的二維數(shù)組（子數(shù)組長度也為9000）進(jìn)行10次空間局部性測試，時(shí)間（毫秒）取平均值，結(jié)果如下：
所用示例為上述兩個(gè)空間局部性示例
| 124 | 2316 |
從以上測試結(jié)果來看，步長為 1 的數(shù)組執(zhí)行時(shí)間比步長為 9000 的數(shù)組快了一個(gè)數(shù)量級(jí)。
總結(jié)：
- 重復(fù)引用相同變量的程序具有良好的時(shí)間局部性
- 對(duì)于具有步長為 k 的引用模式的程序，步長越小，空間局部性越好；而在內(nèi)存中以大步長跳來跳去的程序空間局部性會(huì)很差
14. if-else 對(duì)比 switch
當(dāng)判斷條件數(shù)量越來越多時(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 語句要進(jìn)行 7 次判斷，switch 只需要進(jìn)行一次判斷。從可讀性來說，switch 語句也更好。
從使用時(shí)機(jī)來說，當(dāng)條件值大于兩個(gè)的時(shí)候，使用 switch 更好。不過 if-else 也有 switch 無法做到的事情，例如有多個(gè)判斷條件的情況下，無法使用 switch。
15. 查找表
當(dāng)條件語句特別多時(shí)，使用 switch 和 if-else 不是最佳的選擇，這時(shí)不妨試一下查找表。查找表可以使用數(shù)組和對(duì)象來構(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 語句轉(zhuǎn)換為查找表
const results = [result0,result1,result2,result3,result4,result5,result6,result7,result8,result9,result10,result11]return results[index]如果條件語句不是數(shù)值而是字符串，可以用對(duì)象來建立查找表
const map = {red: result0,green: result1, }return map[color]16. 避免頁面卡頓
60fps 與設(shè)備刷新率
目前大多數(shù)設(shè)備的屏幕刷新率為 60 次/秒。因此，如果在頁面中有一個(gè)動(dòng)畫或漸變效果，或者用戶正在滾動(dòng)頁面，那么瀏覽器渲染動(dòng)畫或頁面的每一幀的速率也需要跟設(shè)備屏幕的刷新率保持一致。
其中每個(gè)幀的預(yù)算時(shí)間僅比 16 毫秒多一點(diǎn) (1 秒/ 60 = 16.66 毫秒)。但實(shí)際上，瀏覽器有整理工作要做，因此您的所有工作需要在 10 毫秒內(nèi)完成。如果無法符合此預(yù)算，幀率將下降，并且內(nèi)容會(huì)在屏幕上抖動(dòng)。此現(xiàn)象通常稱為卡頓，會(huì)對(duì)用戶體驗(yàn)產(chǎn)生負(fù)面影響。
假如你用 JavaScript 修改了 DOM，并觸發(fā)樣式修改，經(jīng)歷重排重繪最后畫到屏幕上。如果這其中任意一項(xiàng)的執(zhí)行時(shí)間過長，都會(huì)導(dǎo)致渲染這一幀的時(shí)間過長，平均幀率就會(huì)下降。假設(shè)這一幀花了 50 ms，那么此時(shí)的幀率為 1s / 50ms = 20fps，頁面看起來就像卡頓了一樣。
對(duì)于一些長時(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ù)雜度過高或數(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 來實(shí)現(xiàn)視覺變化
從第 16 點(diǎn)我們可以知道，大多數(shù)設(shè)備屏幕刷新率為 60 次/秒，也就是說每一幀的平均時(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 來實(shí)現(xiàn)動(dòng)畫的話，回調(diào)函數(shù)將在幀中的某個(gè)時(shí)點(diǎn)運(yùn)行，可能剛好在末尾，而這可能經(jīng)常會(huì)使我們丟失幀，導(dǎo)致卡頓。
18. 使用 Web Workers
Web Worker 使用其他工作線程從而獨(dú)立于主線程之外，它可以執(zhí)行任務(wù)而不干擾用戶界面。一個(gè) worker 可以將消息發(fā)送到創(chuàng)建它的 JavaScript 代碼, 通過將消息發(fā)送到該代碼指定的事件處理程序（反之亦然）。
Web Worker 適用于那些處理純數(shù)據(jù)，或者與瀏覽器 UI 無關(guān)的長時(shí)間運(yùn)行腳本。
創(chuàng)建一個(gè)新的 worker 很簡單，指定一個(gè)腳本的 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 中接收到消息后，我們可以寫一個(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)行使用。這里我們簡單的對(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é)果。
不過在worker內(nèi)，不能直接操作DOM節(jié)點(diǎn)，也不能使用window對(duì)象的默認(rèn)方法和屬性。然而你可以使用大量window對(duì)象之下的東西，包括WebSockets，IndexedDB以及FireFox OS專用的Data Store API等數(shù)據(jù)存儲(chǔ)機(jī)制。
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)算可以用位操作來代替。
取整
~~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通過定義這些選項(xiàng)，可以用按位與操作來判斷 a/b/c 是否在 options 中。
// 選項(xiàng) b 是否在選項(xiàng)中 if (b & options) {... }20. 不要覆蓋原生方法
無論你的 JavaScript 代碼如何優(yōu)化，都比不上原生方法。因?yàn)樵椒ㄊ怯玫图?jí)語言寫的（C/C++），并且被編譯成機(jī)器碼，成為瀏覽器的一部分。當(dāng)原生方法可用時(shí)，盡量使用它們，特別是數(shù)學(xué)運(yùn)算和 DOM 操作。
21. 降低 CSS 選擇器的復(fù)雜性
(1). 瀏覽器讀取選擇器，遵循的原則是從選擇器的右邊到左邊讀取。
看個(gè)示例
的父元素
(2). CSS 選擇器優(yōu)先級(jí)
內(nèi)聯(lián) > ID選擇器 > 類選擇器 > 標(biāo)簽選擇器根據(jù)以上兩個(gè)信息可以得出結(jié)論。
最后要說一句，據(jù)我查找的資料所得，CSS 選擇器沒有優(yōu)化的必要，因?yàn)樽盥吐斓倪x擇器性能差別非常小。
22. 使用 flexbox 而不是較早的布局模型
在早期的 CSS 布局方式中我們能對(duì)元素實(shí)行絕對(duì)定位、相對(duì)定位或浮動(dòng)定位。而現(xiàn)在，我們有了新的布局方式 flexbox，它比起早期的布局方式來說有個(gè)優(yōu)勢，那就是性能比較好。
下面的截圖顯示了在 1300 個(gè)框上使用浮動(dòng)的布局開銷：
然后我們用 flexbox 來重現(xiàn)這個(gè)例子：
現(xiàn)在，對(duì)于相同數(shù)量的元素和相同的視覺外觀，布局的時(shí)間要少得多（本例中為分別 3.5 毫秒和 14 毫秒）。
不過 flexbox 兼容性還是有點(diǎ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-)
23. 使用 transform 和 opacity 屬性更改來實(shí)現(xiàn)動(dòng)畫
在 CSS 中，transforms 和 opacity 這兩個(gè)屬性更改不會(huì)觸發(fā)重排與重繪，它們是可以由合成器（composite）單獨(dú)處理的屬性。
24. 合理使用規(guī)則，避免過度優(yōu)化
性能優(yōu)化主要分為兩類：
上述 23 條建議中，屬于加載時(shí)優(yōu)化的是前面 10 條建議，屬于運(yùn)行時(shí)優(yōu)化的是后面 13 條建議。通常來說，沒有必要 23 條性能優(yōu)化規(guī)則都用上，根據(jù)網(wǎng)站用戶群體來做針對(duì)性的調(diào)整是最好的，節(jié)省精力，節(jié)省時(shí)間。
在解決問題之前，得先找出問題，否則無從下手。所以在做性能優(yōu)化之前，最好先調(diào)查一下網(wǎng)站的加載性能和運(yùn)行性能。
檢查加載性能
一個(gè)網(wǎng)站加載性能如何主要看白屏?xí)r間和首屏?xí)r間。
- 白屏?xí)r間：指從輸入網(wǎng)址，到頁面開始顯示內(nèi)容的時(shí)間。
- 首屏?xí)r間：指從輸入網(wǎng)址，到頁面完全渲染的時(shí)間。
將以下腳本放在 前面就能獲取白屏?xí)r間。
在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)用搜索引擎搜索一下，畢竟篇幅有限。
通過檢查加載和運(yùn)行性能，相信你對(duì)網(wǎng)站性能已經(jīng)有了大概了解。所以這時(shí)候要做的事情，就是使用上述 23 條建議盡情地去優(yōu)化你的網(wǎng)站，加油！
總結(jié)
以上是生活随笔為你收集整理的前端性能优化建议,24条的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。
- 上一篇： 电缆载流量计算对照表
- 下一篇： 谷歌浏览器不使用独立显卡