JavaScript 作為當(dāng)前最為常見的直譯式腳本語言，已經(jīng)廣泛應(yīng)用于 Web 應(yīng)用開發(fā)中。為了提高Web應(yīng)用的性能，從 JavaScript 的性能優(yōu)化方向入手，會是一個很好的選擇。

本文從加載、上下文、解析、編譯、執(zhí)行和捆綁等多個方面來講解 JavaScript 的性能優(yōu)化技巧，以便讓更多的前端開發(fā)人員掌握這方面知識。

什么是高性能的 JavaScript 代碼？

盡管目前沒有高性能代碼的絕對定義，但卻存在一個以用戶為中心的性能模型，可以用作參考：RAIL模型。

響應(yīng)

如果你的應(yīng)用程序能在100毫秒內(nèi)響應(yīng)用戶的操作，那么用戶會認(rèn)為該響應(yīng)為即時的。這適用于可點擊的元素，不適用于滾動或拖動操作。

動畫

在60Hz的顯示器上，我們希望動畫和滾動時每秒有60幀，這種情況下每幀大約為16ms。在這16ms的時間內(nèi)，實際上只有8-10ms來完成所有工作，其余時間則由瀏覽器的內(nèi)部和其它差異占據(jù)。

空閑工作

如果你有一個耗時很久，需要持續(xù)運行的任務(wù)時，請確保把它分成很小的塊，以便允許主線程對用戶的輸入操作做出反應(yīng)。不應(yīng)該出現(xiàn)一個任務(wù)延遲超過50ms的用戶輸入。

加載

頁面加載應(yīng)該在1000毫秒內(nèi)完成。在移動設(shè)備上，這是一個很難達(dá)到的目標(biāo)，因為它涉及到頁面的互動，而不僅僅是在屏幕上渲染和滾動。

現(xiàn)代加載最佳實踐（Chrome Dev Summit 2017）

如果移動網(wǎng)站的加載時間超過三秒，則會有53％的用戶放棄訪問

50%的用戶希望在不到2秒的時間內(nèi)完成頁面加載

77％的移動網(wǎng)站需要10秒以上的時間來加載3G網(wǎng)絡(luò)

19秒是3G網(wǎng)絡(luò)上移動站點的平均加載時間

代碼內(nèi)容

你可能已經(jīng)注意到了，最大的瓶頸是加載網(wǎng)站所需的時間。具體來說就是 JavaScript 的下載、解析、編譯和執(zhí)行時間。除了加載更少的 JavaScript 文件或者加載的更加靈活以外，看起來沒有其它辦法。

除去啟動網(wǎng)站之外，JavaScript 代碼又是如何實際工作的呢？

在進(jìn)行代碼優(yōu)化之前，請考慮你當(dāng)前正在構(gòu)建的內(nèi)容。你正在建立的是一個框架還是一個 VDOM 庫？你的代碼是否需要每秒執(zhí)行數(shù)千次操作？你是否正在做一個對時間要求較為嚴(yán)格的庫來處理用戶輸入和/或動畫？如果沒有，你需要把時間和精力轉(zhuǎn)移到更有影響力的地方。

編寫高性能代碼并不是那么重要，因為對于宏觀計劃通常沒有什么影響。50k ops/s 聽起來好于 1k ops/s，但在大多數(shù)情況下整體時間并不會有所改變。

解析、編譯和執(zhí)行

從根本上說，大多數(shù) JavaScript 的性能問題，并不在于運行代碼本身，而是在代碼開始執(zhí)行之前必須采取的一系列步驟。

我們在這里討論抽象層次的問題。計算機(jī)上運行的大多數(shù)代碼都是編譯后的二進(jìn)制格式。意思是說，除了所有的操作系​​統(tǒng)級別的抽象外，代碼都可以在硬件上本地運行，不需要準(zhǔn)備工作。

JavaScript 代碼不是預(yù)編譯的，它在瀏覽器上是可讀的。

JavaScript 代碼首先會被解析，也就是讀取并轉(zhuǎn)換成可用于編譯的計算機(jī)索引的結(jié)構(gòu)，然后再被編譯成字節(jié)碼，最后被編譯成機(jī)器碼，用于設(shè)備/瀏覽器執(zhí)行。

另一個非常重要的方面是：JavaScript 是單線程的，并且在瀏覽器的主線程上運行。這意味著一次只能運行一個進(jìn)程。如果你的 DevTools 性能時間線充滿黃色峰值，同時 CPU 占用率達(dá)到100%，則將出現(xiàn)丟幀的情況。這是滾動操作常出現(xiàn)的，也是很討厭的一種情況。

在 JavaScript 代碼運行之前，需要完成所有的這些解析、編譯和執(zhí)行工作。在 ChromeV8 引擎中，解析和編譯占 JavaScript 執(zhí)行總時間的50％左右。

所以在這部分中，應(yīng)該了解兩件事情：

1. 雖然 JavaScript 解析的時間長度和包的大小不是完全線性的，但是需要處理的 JavaScript 越少，則所花時間越少。

2. 你使用的每一個 JavaScript 框架（React，Vue，Angular，Preact ...）都是另一個抽象層次（除非它是一個預(yù)編譯的）。這不僅會增加你的包的大小，而且會讓你的代碼變慢，因為你不是直接與瀏覽器通信的。

有些方法可以緩解這種情況，比如使用 service workers 在后臺的另一個線程中執(zhí)行部分工作，或者使用 asm.js 編寫更容易編譯機(jī)器指令的代碼。

我們所能做的，就是避免使用 JavaScript 動畫庫。只有在使用常規(guī)的 CSS 轉(zhuǎn)換和動畫完全無法實現(xiàn)時，才去使用這些庫。

即使這些 JavaScript 動畫庫使用 CSS 轉(zhuǎn)換，合成屬性和 requestAnimationFrame( )，但是它們?nèi)匀贿\行在 JavaScript 的主線程上?；旧线@些庫會使用內(nèi)聯(lián)樣式每16ms訪問一次 DOM。你需要確保所有的 JavaScript 都在每幀8ms以內(nèi)完成，才能保持動畫的平滑性。

另一方面，CSS 動畫和轉(zhuǎn)換會在主線程中運行，如果能夠高效執(zhí)行，則能避免重新布局/重排的情況出現(xiàn)。

考慮到大多數(shù)動畫都在加載或用戶交互的過程中運行，這可以為你的 web 應(yīng)用程序提供非常重要的調(diào)整空間。

web Animations API 是一個即將到來的功能集，它能夠脫離主線程執(zhí)行高性能的 JavaScript 動畫。但就目前而言，還需要繼續(xù)使用 CSS 轉(zhuǎn)換等技術(shù)。

捆綁尺寸非常重要

現(xiàn)在已經(jīng)不再是在 </body> 結(jié)束標(biāo)簽之前包含有多個 <script> 的時代了?，F(xiàn)在，可以在 npm 上找到各式各樣的工具包，并且可以將這些工具包和 Webpack 捆綁在一個單個的 1MB 大小的 JavaScript 文件中，在完成數(shù)據(jù)計劃時，提醒用戶的瀏覽器進(jìn)行爬取。

這樣可以使用更少量的 JavaScript，這也意味著你的項目可能不再需要整個Lodash庫。如果必須使用 JavaScript 庫，也可以考慮使用 React 以外的東西，比如 Preact 或者 HyperHTML，它們只是 React 的1/20大小。

Webpack 3 有著神奇的功能，被稱作代碼分割和動態(tài)導(dǎo)入。它不會將所有 JavaScript 模塊捆綁到一個 app.js 整包中，而是使用 import( ) 語法自動分割代碼并且進(jìn)行異步加載。

你不需要使用框架、組件和客戶端路由，就能獲得這些好處。你只需要簡單地在主 JavaScript 文件中寫入以下內(nèi)容：

if (document.querySelector('.mega-widget')) {
 import('./mega-widget');
}

如果你的應(yīng)用程序需要在頁面上用到這個小部件，它將動態(tài)加載所需的支持代碼。

另外，Webpack 需要運行時間來工作，并將其注入到它生成的所有 .js 文件中。如果使用該 commonChunks 插件，則可以使用以下內(nèi)容將運行時抽取到 Chunk 中：

new webpack.optimize.CommonsChunkPlugin({
 name: 'runtime',
}),

確保 Webpack 在主 JavaScript 包之前已完成加載，那么所有其它 chunk 中的運行時間會剝離到各自的文件中，這種情況也被成為 runtime.js。例如：

<script src="runtime.js">
<script src="main-bundle.js">

然后是編譯代碼和 polyfills 的部分。如果你正在編寫現(xiàn)代 JavaScript 代碼（ES6 +），則可以使用 Babel 將其轉(zhuǎn)換為 ES5 兼容的代碼。與原生 ES6+ 代碼相比，編譯不僅增加了文件的大小，還增加了復(fù)雜性，并且經(jīng)常會出現(xiàn)性能下降的情況。

除此之外，你還很可能使用 babel-polyfill 軟件包和 whatwg-fetch，來修復(fù)舊版本瀏覽器中的缺失功能。因此如果你正在編寫 async/await，你還需要使用包 regenerator-runtime 的生成器來進(jìn)行編譯。

問題是，你為 JavaScript 軟件包添加了近 100KB 的內(nèi)容，這不僅是一個巨大的文件，而且預(yù)示著巨大的解析和執(zhí)行花費，以便能夠支持舊版本的瀏覽器。

一種方法是創(chuàng)建兩個獨立的 bundle，并根據(jù)實際條件來加載它們。Babel 轉(zhuǎn)換編譯器在 babel-preset-env 的幫助下，會使同時面臨新舊兩種瀏覽器的情況更加容易處理。

一個并不規(guī)范但行之有效的方法，是將以下內(nèi)容放在一個內(nèi)聯(lián)腳本中：

(function() {
 try {
 new Function('async () => {}')();
 } catch (error) {
 // create script tag pointing to legacy-bundle.js;
 return;
 }
 // create script tag pointing to modern-bundle.js;;
})();

如果瀏覽器無法識別 async 函數(shù)，則會被認(rèn)為是舊版本的瀏覽器，此時就會用到 polyfill 包。如果能識別，用戶則將得到現(xiàn)代瀏覽器的處理。

結(jié)論

想要提高網(wǎng)站的運行速度，就需要確保網(wǎng)站能快速的加載 JavaScript 文件，以實現(xiàn)快速的互動。你的 JavaScript 代碼應(yīng)該被分成更小的、可管理的 bundle，同時盡可能地進(jìn)行異步加載。在服務(wù)器端，請確保啟用了 HTTP 2.0，以便實現(xiàn)更快的并行傳輸和 gzip/Brotli 壓縮，從而大大減少了 JavaScript 的傳輸大小。

以上這篇基于JavaScript 性能優(yōu)化技巧心得(分享)就是小編分享給大家的全部內(nèi)容了，希望能給大家一個參考，也希望大家多多支持腳本之家。

最新評論