在啟動(dòng)階段，語(yǔ)法分析，編譯與腳本執(zhí)行占據(jù)了 JavaScript 引擎運(yùn)行的絕大部分時(shí)間。換言之，這些過(guò)程造成的延遲會(huì)真實(shí)地反應(yīng)到用戶可交互時(shí)延上；譬如用戶已經(jīng)看到了某個(gè)按鈕，但是要好幾秒之后才能真正地去點(diǎn)擊操作，這一點(diǎn)會(huì)大大影響用戶體驗(yàn)。

上圖是我們使用 Chrome Canary 內(nèi)置的 V8 RunTime Call Stats 對(duì)于某個(gè)網(wǎng)站的分析結(jié)果；需要注意的是桌面瀏覽器中語(yǔ)法解析與編譯占用的時(shí)間還是蠻長(zhǎng)的，而在移動(dòng)端中占用的時(shí)間則更長(zhǎng)。實(shí)際上，對(duì)于 Facebook, Wikipedia, Reddit 這些大型網(wǎng)站中語(yǔ)法解析與編譯所占的時(shí)間也不容忽視：

上圖中的粉色區(qū)域表示花費(fèi)在 V8 與 Blink"s C++ 中的時(shí)間，而橙色和黃色分別表示語(yǔ)法解析與編譯的時(shí)間占比。Facebook 的 Sebastian Markbage 與 Google 的 Rob Wormald 也都在 Twitter 發(fā)文表示過(guò) JavaScript 的語(yǔ)法解析時(shí)間過(guò)長(zhǎng)已經(jīng)成為了不可忽視的問(wèn)題，后者還表示這也是 Angular 啟動(dòng)時(shí)主要的消耗之一。

隨著移動(dòng)端浪潮的涌來(lái)，我們不得不面對(duì)一個(gè)殘酷的事實(shí)：移動(dòng)端對(duì)于相同包體的解析與編譯過(guò)程要花費(fèi)相當(dāng)于桌面瀏覽器2~5倍的時(shí)間。當(dāng)然，對(duì)于高配的 iPhone 或者 Pixel 這樣的手機(jī)相較于 Moto G4 這樣的中配手機(jī)表現(xiàn)會(huì)好很多；這一點(diǎn)提醒我們?cè)跍y(cè)試的時(shí)候不能僅用身邊那些高配的手機(jī)，而應(yīng)該中高低配兼顧：

上圖是部分桌面瀏覽器與移動(dòng)端瀏覽器對(duì)于 1MB 的 JavaScript 包體進(jìn)行解析的時(shí)間對(duì)比，顯而易見的可以發(fā)現(xiàn)不同配置的移動(dòng)端手機(jī)之間的巨大差異。當(dāng)我們應(yīng)用包體已經(jīng)非常巨大的時(shí)候，使用一些現(xiàn)代的打包技巧，譬如代碼分割，TreeShaking，Service Workder 緩存等等會(huì)對(duì)啟動(dòng)時(shí)間有很大的影響。另一個(gè)角度來(lái)看，即使是小模塊，你代碼寫的很糟或者使用了很糟的依賴庫(kù)都會(huì)導(dǎo)致你的主線程花費(fèi)大量的時(shí)間在編譯或者冗余的函數(shù)調(diào)用中。我們必須要清醒地認(rèn)識(shí)到全面評(píng)測(cè)以挖掘出真正性能瓶頸的重要性。

我曾不止一次聽到有人說(shuō)，我又不是 Facebook，你說(shuō)的 JavaScript 語(yǔ)法解析與編譯到
底會(huì)對(duì)其他網(wǎng)站造成什么樣的影響呢？對(duì)于這個(gè)問(wèn)題我也很好奇，于是我花費(fèi)了兩個(gè)月的時(shí)間對(duì)于超過(guò) 6000 個(gè)網(wǎng)站進(jìn)行分析；這些網(wǎng)站囊括了 React，Angular，Ember，Vue 這些流行的框架或者庫(kù)。大部分的測(cè)試是基于 WebPageTest 進(jìn)行的，因此你可以很方便地重現(xiàn)這些測(cè)試結(jié)果。光纖接入的桌面瀏覽器大概需要 8 秒的時(shí)間才能允許用戶交互，而 3G 環(huán)境下的 Moto G4 大概需要 16 秒 才能允許用戶交互。

大部分應(yīng)用在桌面瀏覽器中會(huì)耗費(fèi)約 4 秒的時(shí)間進(jìn)行 JavaScript 啟動(dòng)階段（語(yǔ)法解析、編譯、執(zhí)行）：

而在移動(dòng)端瀏覽器中，大概要花費(fèi)額外 36% 的時(shí)間來(lái)進(jìn)行語(yǔ)法解析：

另外，統(tǒng)計(jì)顯示并不是所有的網(wǎng)站都甩給用戶一個(gè)龐大的 JS 包體，用戶下載的經(jīng)過(guò) Gzip 壓縮的平均包體大小是 410KB，這一點(diǎn)與 HTTPArchive 之前發(fā)布的 420KB 的數(shù)據(jù)基本一致。不過(guò)最差勁的網(wǎng)站則是直接甩了 10MB 的腳本給用戶，簡(jiǎn)直可怕。

通過(guò)上面的統(tǒng)計(jì)我們可以發(fā)現(xiàn)，包體體積固然重要，但是其并非唯一因素，語(yǔ)法解析與編譯的耗時(shí)也不一定隨著包體體積的增長(zhǎng)而線性增長(zhǎng)。總體而言小的 JavaScript 包體是會(huì)加載地更快（忽略瀏覽器、設(shè)備與網(wǎng)絡(luò)連接的差異），但是同樣 200KB 的大小，不同開發(fā)者的包體在語(yǔ)法解析、編譯上的時(shí)間卻是天差地別，不可同日而語(yǔ)。

打開 Timeline( Performance panel ) > Bottom-Up/Call Tree/Event Log 就會(huì)顯示出當(dāng)前網(wǎng)站在語(yǔ)法解析/編譯上的時(shí)間占比。如果你希望得到更完整的信息，那么可以打開 V8 的 Runtime Call Stats。在 Canary 中，其位于 Timeline 的 Experims > V8 Runtime Call Stats 下。

打開 about:tracing 頁(yè)面，Chrome 提供的底層的追蹤工具允許我們使用disabled-by-default-v8.runtime_stats來(lái)深度了解 V8 的時(shí)間消耗情況。V8 也提供了詳細(xì)的指南來(lái)介紹如何使用這個(gè)功能。

WebPageTest 中 Processing Breakdown 頁(yè)面在我們啟用 Chrome > Capture Dev Tools Timeline 時(shí)會(huì)自動(dòng)記錄 V8 編譯、EvaluateScript 以及 FunctionCall 的時(shí)間。我們同樣可以通過(guò)指明disabled-by-default-v8.runtime_stats的方式來(lái)啟用 Runtime Call Stats。

更多使用說(shuō)明參考我的gist。

我們還可以使用 Nolan Lawson 推薦的User Timing API來(lái)評(píng)估語(yǔ)法解析的時(shí)間。不過(guò)這種方式可能會(huì)受 V8 預(yù)解析過(guò)程的影響，我們可以借鑒 Nolan 在 optimize-js 評(píng)測(cè)中的方式，在腳本的尾部添加隨機(jī)字符串來(lái)解決這個(gè)問(wèn)題。我基于 Google Analytics 使用相似的方式來(lái)評(píng)估真實(shí)用戶與設(shè)備訪問(wèn)網(wǎng)站時(shí)候的解析時(shí)間：

Etsy 的 DeviceTiming 工具能夠模擬某些受限環(huán)境來(lái)評(píng)估頁(yè)面的語(yǔ)法解析與執(zhí)行時(shí)間。其將本地腳本包裹在了某個(gè)儀表工具代碼內(nèi)從而使我們的頁(yè)面能夠模擬從不同的設(shè)備中訪問(wèn)?？梢蚤喿x Daniel Espeset 的Benchmarking JS Parsing and Execution on Mobile Devices 一文來(lái)了解更詳細(xì)的使用方式。

減少 JavaScript 包體體積。我們?cè)谏衔闹幸蔡峒埃〉陌w往往意味著更少的解析工作量，也就能降低瀏覽器在解析與編譯階段的時(shí)間消耗。

使用代碼分割工具來(lái)按需傳遞代碼與懶加載剩余模塊。這可能是最佳的方式了，類似于PRPL這樣的模式鼓勵(lì)基于路由的分組，目前被 Flipkart, Housing.com 與 Twitter 廣泛使用。

Script streaming: 過(guò)去 V8 鼓勵(lì)開發(fā)者使用async/defer來(lái)基于script streaming實(shí)現(xiàn) 10-20% 的性能提升。這個(gè)技術(shù)會(huì)允許 HTML 解析器將相應(yīng)的腳本加載任務(wù)分配給專門的 script streaming 線程，從而避免阻塞文檔解析。V8 推薦盡早加載較大的模塊，畢竟我們只有一個(gè) streamer 線程。

評(píng)估我們依賴的解析消耗。我們應(yīng)該盡可能地選擇具有相同功能但是加載地更快的依賴，譬如使用 Preact 或者 Inferno 來(lái)代替 React，二者相較于 React 體積更小具有更少的語(yǔ)法解析與編譯時(shí)間。Paul Lewis 在最近的一篇文章中也討論了框架啟動(dòng)的代價(jià)，與 Sebastian Markbage 的說(shuō)法不謀而合：最好地評(píng)測(cè)某個(gè)框架啟動(dòng)消耗的方式就是先渲染一個(gè)界面，然后刪除，最后進(jìn)行重新渲染。第一次渲染的過(guò)程會(huì)包含了分析與編譯，通過(guò)對(duì)比就能發(fā)現(xiàn)該框架的啟動(dòng)消耗。

如果你的 JavaScript 框架支持 AOT（ahead-of-time）編譯模式，那么能夠有效地減少解析與編譯的時(shí)間。Angular 應(yīng)用就受益于這種模式：

不用灰心，你并不是唯一糾結(jié)于如何提升啟動(dòng)時(shí)間的人，我們 V8 團(tuán)隊(duì)也一直在努力。我們發(fā)現(xiàn)之前的某個(gè)評(píng)測(cè)工具 Octane 是個(gè)不錯(cuò)的對(duì)于真實(shí)場(chǎng)景的模擬，它在微型框架與冷啟動(dòng)方面很符合真實(shí)的用戶習(xí)慣。而基于這些工具，V8 團(tuán)隊(duì)在過(guò)去的工作中也實(shí)現(xiàn)了大約 25% 的啟動(dòng)性能提升：

本部分我們就會(huì)對(duì)過(guò)去幾年中我們使用的提升語(yǔ)法解析與編譯時(shí)間的技巧進(jìn)行闡述。

Chrome 42 開始引入了所謂的代碼緩存的概念，為我們提供了一種存放編譯后的代碼副本的機(jī)制，從而當(dāng)用戶二次訪問(wèn)該頁(yè)面時(shí)可以避免腳本抓取、解析與編譯這些步驟。除以之外，我們還發(fā)現(xiàn)在重復(fù)訪問(wèn)的時(shí)候這種機(jī)制還能避免 40% 左右的編譯時(shí)間，這里我會(huì)深入介紹一些內(nèi)容：

代碼緩存會(huì)對(duì)于那些在 72 小時(shí)之內(nèi)重復(fù)執(zhí)行的腳本起作用。

對(duì)于 Service Worker 中的腳本，代碼緩存同樣對(duì) 72 小時(shí)之內(nèi)的腳本起作用。

對(duì)于利用 Service Worker 緩存在 Cache Storage 中的腳本，代碼緩存能在腳本首次執(zhí)行的時(shí)候起作用。

總而言之，對(duì)于主動(dòng)緩存的 JavaScript 代碼，最多在第三次調(diào)用的時(shí)候其能夠跳過(guò)語(yǔ)法分析與編譯的步驟。我們可以通過(guò)chrome://flags/#v8-cache-strategies-for-cache-storage來(lái)查看其中的差異，也可以設(shè)置?js-flags=profile-deserialization運(yùn)行 Chrome 來(lái)查看代碼是否加載自代碼緩存。不過(guò)需要注意的是，代碼緩存機(jī)制僅會(huì)緩存那些經(jīng)過(guò)編譯的代碼，主要是指那些頂層的往往用于設(shè)置全局變量的代碼。而對(duì)于類似于函數(shù)定義這樣懶編譯的代碼并不會(huì)被緩存，不過(guò) IIFE 同樣被包含在了 V8 中，因此這些函數(shù)也是可以被緩存的。

Script Streaming允許在后臺(tái)線程中對(duì)異步腳本執(zhí)行解析操作，可以對(duì)于頁(yè)面加載時(shí)間有大概 10% 的提升。上文也提到過(guò)，這個(gè)機(jī)制同樣會(huì)對(duì)同步腳本起作用。

這個(gè)特性倒是第一次提及，因此 V8 會(huì)允許所有的腳本，即使阻塞型的

(function (global, module) { … })(this, function module() { my functions })