在建立那些嚴重依賴于JavaScript網(wǎng)站的時候，有時我們會為自己發(fā)送的內容付出一些隱形的成本。在本篇文章中，我會介紹一些可以幫助你提升網(wǎng)站在移動設備上加載和運行速度的實用規(guī)則。

tl;dr：更少的代碼 = 更少的解析/編譯 (parse/compile)+ 更少的傳送 + 更少的解壓縮

網(wǎng)絡

大多數(shù)開發(fā)人員考慮JavaScript成本的時候，考慮的都是下載和執(zhí)行成本。通過線路發(fā)送的JavaScript字節(jié)越多，所需時間就越長，用戶連接就越慢。

即使是在發(fā)達國家，這也可能是一個問題，因為用戶實際上用的有效網(wǎng)絡連接類型可能并不是3G、4G或者Wifi。表面上你可能連的是咖啡店的Wifi，但實際上連到的是只有2G速度的蜂窩熱點。

你可以通過以下的幾種方式來降低JavaScript的網(wǎng)絡傳輸成本：

1. 只傳送用戶需要的代碼?？捎么a拆分(Code-splitting)。
2. 優(yōu)化壓縮代碼(ES5的Uglify，ES2015的babel-minify或者uglify-es)
3. 高度壓縮(用Brotli~q11，Zopfli或gzip)。Brotli的壓縮比優(yōu)于gzip。它可以幫CertSimple節(jié)省17%的壓縮JS的字節(jié)大小，以及幫LinkedIn減少4%的加載時間。
4. 移除無用的代碼。用 Chrome DevTools代碼覆蓋率功能來查找未使用的JS代碼。對于精簡代碼，可參閱tree-shaking， Closure Compiler的高端模式(advanced optimizations)和類似于 lodash-babel-plugin的微調庫插件，或者像Moment.js這類庫的Webpack的ContextReplacementPlugin。用babel-preset-env & browserlist來避免現(xiàn)代瀏覽器中已有的轉譯(transpiling)功能。高級開發(fā)人員可能會發(fā)現(xiàn)仔細分析Webpack打包(bundle)有助于他們識別和調整不必要的依賴關系。
5. 緩存HTTP代碼來減少網(wǎng)絡傳輸量。確定腳本最佳的緩存時間(例如：max-age)和提供驗證令牌(Etag)來避免傳送無變化的字節(jié)。用Service Worker緩存一方面可以讓應用程序網(wǎng)絡更加靈活，另一方面也可以讓你能夠快速訪問像V8代碼緩存這樣的功能。長期緩存可以去了解下Webpack帶哈希值文件名(filename hashing)。

(減少向用戶發(fā)送JavaScript量的最佳做法。)

解析/編譯

下載成功后，JavaScript**絕大部分的時間都消耗在JS引擎對下載代碼的解析/編譯**上。在Chrome DevTools中，解析和編譯是下面性能面板(Performance panel)中黃色“腳本”時間的一部分。

Bottom-Up/Call Tree允許我們去確切地查看解析/編譯所用時間：

(Chrome DevTools性能面板下級菜單>Bottom-U。啟動V8的Runtime Call Stats，就能看到不同階段的時間消耗，比如解析/編譯所用時間。)

但是，這為什么會是個問題?

耗費很長的時間在解析/編譯代碼上，會嚴重延遲用戶與你網(wǎng)站的交互時間。你發(fā)送的JavaScript越多，在網(wǎng)站實現(xiàn)交互前所用的解析/編譯的時間就會越長。

即使是同樣多的字節(jié)，瀏覽器處理JavaScript也會比處理等大小的圖片和網(wǎng)頁字體消耗更高的成本——Tom Dale

相比于JavaScript，處理等字節(jié)的圖片所需要的時間成本很高(因為圖片仍需要解碼!)但是在一般的移動設備上，反而是JS更有可能對頁面的交互產(chǎn)生負面的影響。

(JavaScript字節(jié)和圖像字節(jié)耗費的時間成本不同。圖像通常不會阻塞主線程，也不會在解碼和光柵化的時候阻止接口進行交互。然而JS會因為解析、編譯和執(zhí)行的時間消耗阻滯交互性。)

當我們說解析和編譯的速度變慢的時候，要注意具體的網(wǎng)絡端和設備端的情況，在這里我們針對的是普通手機。普通用戶所使用手機的CPU和GPU速度比較慢，沒有L2/L3緩存，甚至可能會有內存限制。

網(wǎng)絡功能和設備功能并不總是相匹配的。有速度驚人的光纖連接的用戶不一定會有最好的CPU來解析和評估發(fā)送到他們的設備的JavaScript。反過來也是如此…你可能有糟糕的網(wǎng)絡連接，但卻有快速的CPU。 – Kristofer Baxter，LinkedIn

在JavaScript Start-up Performance一文中，我曾提到過在低端和高端硬件上解析~1MB解壓縮過(簡單)的JavaScript所需要消耗的時間。市面上的普通手機和運行速度最快的手機相比，解析/編譯代碼的所用的時間會有2-5倍的差距。

(在不同級別的臺式和移動設備上解析1MB的JavaScript包(經(jīng)gzip壓縮，大小約為250KB )。當分析解析成本時，我們需要考慮的是解壓后的數(shù)據(jù)量，例如〜250KBgzip壓縮過的JS解壓縮后約為〜1MB的代碼。)

那解析/編譯真實網(wǎng)站的時間差異又會是怎樣呢，比如CNN.com網(wǎng)站?

在高端的iPhone 8上解析/編譯CNN網(wǎng)站的JS大約花費了4秒，相比于普通手機(Moto G4)的13秒左右。這可以顯著地影響用戶與CNN網(wǎng)站實現(xiàn)完全交互的速度。

(蘋果公司的A11仿生芯片和更普通的Android硬件中的Snapdragon 617的解析時間上的性能比較

這就突出了在普通硬件(比如Moto G4)上測試的重要性，而不僅僅是在自己恰好有的手機上測試。基于自己客戶原有的設備和網(wǎng)絡條件來進行優(yōu)化是很重要的。

分析可以使你更加深入了解自己真實客戶訪問網(wǎng)站所用的移動設備的級別和這些設備CPU/GPU的局限性。

我們真的發(fā)送了太多的JavaScript了嗎?呃…真有可能:)

用HTTP Archive(qian500K站點)來分析移動設備上JavaScript的狀態(tài)時，我們可以看到，50%的站點需要14秒才能取得交互。這些網(wǎng)站光是用來解析和編譯JS的時間就長達4秒。

考慮到獲取和處理JS和其他資源所耗費的時間，也就不奇怪用戶可能需要在頁面可用之前等待一段時間了。我們絕對可以在這個方面做的更好。

從網(wǎng)頁中刪除不必要的JavaScript可以減少傳輸時間、CPU密集型解析和編譯以及潛在的內存消耗，同時也有助于加快網(wǎng)頁的交互速度。

執(zhí)行時間

不光是解析和編譯會有時間成本。執(zhí)行JavaScript(在解析/編譯之后運行代碼)也是需要在主線程上進行的操作之一。長的執(zhí)行時間也會延遲用戶與你網(wǎng)站的交互時間。

如果腳本執(zhí)行的時間超過了50ms，那么延遲交互的時間將會是下載、編譯和執(zhí)行JS所需時間的總和——Alex Russell

為了解決這個問題，可以將JavaScript腳本分為幾個小塊來執(zhí)行，以避免鎖定主線程。探索一下是否可以減少腳本執(zhí)行過程中進行中工作量的可能性。

減少JavaScript交付成本的模式

當你試圖降低JavaScript解析/編譯和網(wǎng)絡傳輸所用時間時，類似于基于路由分塊和PRPL這些模式也會有用。

PRPL是一種通過激進的(aggresive)代碼分割和緩存來優(yōu)化交互性的模式：

為了能將PRPL的影響以視覺化方式表現(xiàn)出來。

我們用V8引擎中的Runtime Call Stats分析了流行移動網(wǎng)站和progressive Web Apps(PWA)的加載時間。正如我們所看到的，解析部分(用橙色表示)是很多網(wǎng)站頁面加載時產(chǎn)生顯著時間消耗的部分。

Wego網(wǎng)站就使用了PRPL來保持較低的路由解析時間，讓頁面交互得以快速的進行。以上的很多站點都試圖采用代碼分割和性能預算來降低JS的消耗。

JavaScript的其他消耗

JavaScript還可以通過其他方式來影響頁面性能：

• 存儲。頁面可能會因為垃圾回收(GC，garbage colleciton)，頁面可能會出現(xiàn)畫面中斷卡頓(junk)和暫停。因為當一個瀏覽器回收內存的時候，JS的執(zhí)行也會被中止，所以經(jīng)常回收垃圾的瀏覽器會比我們想象中的更頻繁地中止JS的執(zhí)行。在這種情況下，可以通過避免內存溢出和頻繁內存回收來保持頁面的流暢。
• 在運行時，長時間的運行JavaScript會阻塞主線程，導致頁面沒有響應。這種情況下，可以將腳本的工作量分成多個小的板塊(具體可用requestAnimationFrame()或者requestIdleCallback()進行任務調度)來執(zhí)行，以此減少頁面響應的問題。

Progressive Bootstrapping

很多網(wǎng)站將優(yōu)化內容可視性作為保證交互性所需代價的一部分。為了在JavaScript有大體積包體時改善首屏性能，開發(fā)人員有時會先用服務器端渲染幫助客戶提前看到頁面內容，然后再在JavaScript最終執(zhí)行完成后“升級”附加上事件處理程序。

但是值得注意的是，這樣做也是有代價的。你1)通常會發(fā)送一個更大的HTML響應來增加交互性，2)在一段時間內，用戶會處在一半的頁面交互體驗缺失的奇怪狀況下，直到JavaScript處理完成。

Progressive Bootstrapping或許會是一個更好的處理方式。瀏覽器請求一個最少化的功能頁面(僅由當前路由所需要的HTML/JS/CSS組成)。當有更多的資源請求的時候，應用程序則可以懶加載(lazy-load)和解鎖更多的功能。

Progressive Bootstrapping visual by Paul Lewis

僅加載可視區(qū)域內的代碼是其中的關鍵。PRPL和Progressive Bootstrapping模式均可以用來實現(xiàn)這一點。

結論

傳輸腳本的大小對低端網(wǎng)絡至關重要，而解析時間對于CPU有局限性的設備很重要。降低傳輸腳本的大小和減少解析消耗時間是有必要的。

有團隊發(fā)現(xiàn)采用嚴格的性能預算可以成功降低他們JavaScript的傳輸和解析/編譯的時間消耗。

(考慮一下在我們所做的架構決策下，JS有多大的空間可以讓我們的應用程序具有邏輯)

如果你正在建一個用于移動設備上的站點，請盡可能的在代表性硬件上開發(fā)，保持較低的JavaScript解析/編譯的時間成本，并采用性能預算來確保團隊對自身JavaScript的成本關注。