本文旨在整理常見Web前端性能優(yōu)化的思路，可供前端開發(fā)參考。因?yàn)榱η缶?jiǎn)，限于篇幅，所以并未詳述具體實(shí)施方案。

基于現(xiàn)代Web前端框架的應(yīng)用，其原理是通過瀏覽器向服務(wù)器發(fā)送網(wǎng)絡(luò)請(qǐng)求，獲取必要的index.html和打包好的JS、CSS等資源，在瀏覽器內(nèi)執(zhí)行JS，動(dòng)態(tài)獲取數(shù)據(jù)并渲染頁面，從而將結(jié)果呈現(xiàn)給用戶。

在這個(gè)過程中，有兩個(gè)步驟可能較為耗時(shí)，一個(gè)是網(wǎng)絡(luò)資源的加載，另一個(gè)是瀏覽器內(nèi)代碼執(zhí)行和DOM渲染。

而耗時(shí)的增加會(huì)導(dǎo)致頁面響應(yīng)慢，卡頓，影響用戶體驗(yàn)。

針對(duì)上述兩種耗時(shí)的情況，常見的優(yōu)化方向有：

1. 縮短請(qǐng)求耗時(shí)；
2. 減少重排重繪；
3. 改善JS性能。

1 縮短請(qǐng)求耗時(shí)

網(wǎng)絡(luò)資源是Web應(yīng)用運(yùn)行的基礎(chǔ)，改善網(wǎng)絡(luò)資源加載速度會(huì)顯著改善前端性能。

1.1 優(yōu)化打包資源

總體原則：減少或延遲模塊引用，以減少網(wǎng)絡(luò)負(fù)荷。

常用工具：

• webpack
• webpack-bundle-analyzer可視化分析工具

常用方法：

• 減小體積：減少非必要的import；壓縮JS代碼；配置服務(wù)器gzip等；使用WebP圖片；
• 按需加載：可根據(jù)“路由”、“是否可見”按需加載JS代碼，減少初次加載JS體積。比如可以使用import()進(jìn)行代碼分割，按需加載；
• 分開打包：利用瀏覽器緩存機(jī)制，依據(jù)模塊更新頻率分層打包。

其他方法：

• 雪碧圖：每個(gè)HTTP/1.1請(qǐng)求都是獨(dú)立的TCP連接，最大6個(gè)并發(fā)，所以合并圖片資源可以優(yōu)化加載速度。HTTP/2已經(jīng)不需要這么做了。

1.2 CDN加速

總體原則：通過分布式的邊緣網(wǎng)絡(luò)節(jié)點(diǎn)，縮短資源到終端用戶的訪問延遲。
常用工具：

• Cloudflare
• AWS CloudFront
• Aliyun CDN

常用方法：

• 加速圖片、視頻等大體積文件

1.3 瀏覽器緩存

總體原則：避免重復(fù)傳輸相同的數(shù)據(jù)，節(jié)省網(wǎng)絡(luò)帶寬，加速資源獲取。

常用方法：
可以通過設(shè)置HTTP Header來控制緩存策略，一般有如下幾種。

• 強(qiáng)緩存

  • Expires：HTTP/1.0
  • Cache-Control：HTTP/1.1

• 協(xié)商緩存

  • ETag+If-None-Match
  • Last-Modified+If-Modified-Since

拿ETag舉例，如果瀏覽器給的If-None-Match值與服務(wù)端給的ETag值相等，服務(wù)器就直接返回304，從而避免重復(fù)傳輸數(shù)據(jù)。

ETag示例：

如果幾個(gè)配置同時(shí)存在，則優(yōu)先級(jí)為：Cache-Control>Expires>ETag>Last-Modified。

1.4 更高版本的HTTP

總體原則：使用高版本HTTP提升性能。

常用工具：

• HTTP/2

HTTP/2較HTTP/1.1最大的改進(jìn)在于：

• 多路復(fù)用：?jiǎn)我籘CP連接，多HTTP請(qǐng)求，有Demo；
• 頭部壓縮：減少HTTP頭體積；
• 請(qǐng)求優(yōu)先級(jí)：優(yōu)先獲取重要的數(shù)據(jù)；
• 服務(wù)端推送：主動(dòng)推送CSS等靜態(tài)資源。

其他方法：

• HTTP/3

HTTP/3基于UDP，有很多方面的性能改進(jìn)，如多路復(fù)用無隊(duì)頭阻塞，響應(yīng)更快。感興趣的同學(xué)可參考Wiki。

1.5 Web Socket

總體原則：解決HTTP協(xié)議無法實(shí)時(shí)通信的問題。

Web Socket是一條有狀態(tài)的TCP長(zhǎng)連接，用于實(shí)現(xiàn)實(shí)時(shí)通信、實(shí)時(shí)響應(yīng)。

1.6 服務(wù)器端渲染（SSR）

總體原則：第一次訪問時(shí)，服務(wù)器端直接返回渲染好的頁面。

一般流程：

• 瀏覽器向 URL 發(fā)送請(qǐng)求；
• 服務(wù)器端返回“空白”index.html；
• 瀏覽器不能呈現(xiàn)頁面，需要繼續(xù)下載依賴；
• 加載所有腳本后，組件才能被渲染。

SSR流程：

• 瀏覽器向 URL 發(fā)送請(qǐng)求；
• 服務(wù)器端執(zhí)行JS完成首屏渲染并返回；
• 瀏覽器直接呈現(xiàn)頁面，然后繼續(xù)下載其他依賴；
• 加載所有腳本后，組件將再次在客戶端呈現(xiàn)。它將對(duì)現(xiàn)有View進(jìn)行合并。

常用工具：

• Node.js，用于服務(wù)器端執(zhí)行代碼，輸出HTML給瀏覽器，支持所有主流前端框架
• Next.js，用于服務(wù)器端渲染React的框架
• gatsby，用React生成靜態(tài)網(wǎng)站的工具

除了可以提升頁面用戶體驗(yàn)，還能應(yīng)用于SEO。

2 減少重排重繪

除了網(wǎng)絡(luò)資源以外，另一個(gè)影響前端性能的因素就是前端頁面的渲染繪制效率。

雖然不同的前端框架有一些差異，但整體的優(yōu)化思路是一致的，這里將以React舉例。

2.1 減少渲染量

總體原則：不渲染未展示的部分。

常用工具：

• react-window
• react-loadable
• JS原生，如IntersectionObserver
• 框架提供，如React.lazy、react-intersection-observer

常用方法：

• 虛擬列表：只渲染可見區(qū)；
• 惰性加載：無限滾動(dòng)；
• 按需加載：頁面只在切換過去時(shí)才加載。

以虛擬列表舉例，以下是使用react-window庫，僅僅渲染了可見區(qū)的數(shù)據(jù)：

2.2 減少渲染次數(shù)

總體思路：避免重復(fù)的渲染。

常用工具：

• lodash
• JS或框架自帶

常用方法：

• 防抖與節(jié)流；
• 對(duì)于React函數(shù)組件來說，合理使用副作用，拆分無關(guān)聯(lián)的副作用；
• 對(duì)于React類組件來說，可以使用shouldComponentUpdate或使用PureComponent來優(yōu)化渲染；
• 利用緩存，如React.memo；
• 使用requestAnimationFrame替代setInterval執(zhí)行動(dòng)畫。

3 改善JS性能

因?yàn)闉g覽器是單線程異步模型，長(zhǎng)時(shí)間的運(yùn)算會(huì)阻塞渲染過程，所以改善復(fù)雜運(yùn)算有助于改善前端的整體性能。

3.1 緩存復(fù)雜計(jì)算

總體思路：避免重復(fù)計(jì)算。

常用方法：

• 對(duì)于React函數(shù)組件來說，可以使用useMemo緩存復(fù)雜計(jì)算值。

舉例如下，memoizedValue需要經(jīng)過復(fù)雜計(jì)算才能得到，此時(shí)就可以使用useMemo緩存，僅僅在輸入?yún)?shù)發(fā)生變化時(shí)才重新計(jì)算，避免計(jì)算阻塞頁面渲染，從而避免頁面卡頓。

1const MyFunctionalComponent = () => {
2 const memoizedValue = useMemo(() => {
3   computeExpensiveValue(a, b);
4 }, [a, b]);
5
6 return ;
7}

但useMemo自身也有性能消耗，需要視情況使用，某些場(chǎng)景可以利用React的渲染機(jī)制避免性能問題，可以參考《Before You memo()》。

3.2 Web Worker

總體原則：多線程思想。

常用方法：

• Dedicated Workers，處理與UI無關(guān)的密集型數(shù)學(xué)計(jì)算：大數(shù)據(jù)集合排序、數(shù)據(jù)壓縮、音視頻處理；
• Service Worker，服務(wù)端推送，或者PWA中配合CacheStorage在前端控制緩存資源；
• Shared Worker，Tab間通信。

JS語言在設(shè)計(jì)之初就是單線程異步模型，好處是可以高效處理I/O操作，但壞處是無法利用多核CPU。

Web Worker會(huì)啟動(dòng)系統(tǒng)級(jí)別的線程，可進(jìn)行多線程編程，發(fā)揮多核的性能。

3.3 Web Assembly

總體原則：將復(fù)雜的計(jì)算邏輯編譯為Web Assembly，避免JS類型推斷過程中的性能開銷，可用于性能的極限優(yōu)化。

適用范圍有限：

曾在網(wǎng)上看到，有人使用自頂向下非優(yōu)化的斐波那契數(shù)列算法來舉例，說Web Assembly比原生JS快一倍，實(shí)測(cè)之后似乎也沒有。

在同一臺(tái)機(jī)器測(cè)試，其中求第48個(gè)值的耗時(shí)如下：

• C（Ubuntu+GCC）：18s
• JS（V8）：32s
• Web Assembly（V8+EMCC）：39s

一種可能的猜想是，斐波那契計(jì)算中沒有大量的類型推斷，而且V8內(nèi)部有一些優(yōu)化機(jī)制，使得此處JS執(zhí)行速度快于Web Assembly。

簡(jiǎn)而言之，并非所有場(chǎng)景都適用于Web Assembly。

另一種運(yùn)用場(chǎng)景是，把不同語言編寫的代碼（C/C++/Java等）編譯為Web Assembly，能以接近原生的速度在Web中運(yùn)行，并且與JS共存。

總結(jié)

導(dǎo)致前端性能問題的因素是多方面的。

如果是前端資源加載慢，導(dǎo)致頁面慢，則應(yīng)該考慮如何縮短請(qǐng)求耗時(shí)。而如果是前端頁面邏輯笨重，UI數(shù)據(jù)量太大，則可以試著從減少重排重繪的角度去優(yōu)化。對(duì)于耗時(shí)長(zhǎng)的復(fù)雜計(jì)算，緩存計(jì)算結(jié)果往往是見效較快的優(yōu)化方式。

最后需要注意的是，在實(shí)際應(yīng)用開發(fā)過程中，因?yàn)槭芟抻陂_發(fā)成本，所以需要平衡優(yōu)化所花的代價(jià)與其對(duì)應(yīng)產(chǎn)生的成效。可以有針對(duì)性地對(duì)性能瓶頸進(jìn)行分析和處理，同時(shí)也需要避免引入不必要的優(yōu)化措施，以確保最終優(yōu)化效果。