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

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

網(wǎng)絡(luò)

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

即使是在發(fā)達(dá)國家，這也可能是一個(gè)問題，因?yàn)橛脩魧?shí)際上用的有效網(wǎng)絡(luò)連接類型可能并不是3G、4G或者Wifi。表面上你可能連的是咖啡店的Wifi，但實(shí)際上連到的是只有2G速度的蜂窩熱點(diǎn)。

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

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%的加載時(shí)間。
4. 移除無用的代碼。用 Chrome DevTools代碼覆蓋率功能來查找未使用的JS代碼。對(duì)于精簡代碼，可參閱tree-shaking， Closure Compiler的高端模式(advanced optimizations)和類似于 lodash-babel-plugin的微調(diào)庫插件，或者像Moment.js這類庫的Webpack的ContextReplacementPlugin。用babel-preset-env & browserlist來避免現(xiàn)代瀏覽器中已有的轉(zhuǎn)譯(transpiling)功能。高級(jí)開發(fā)人員可能會(huì)發(fā)現(xiàn)仔細(xì)分析Webpack打包(bundle)有助于他們識(shí)別和調(diào)整不必要的依賴關(guān)系。
5. 緩存HTTP代碼來減少網(wǎng)絡(luò)傳輸量。確定腳本最佳的緩存時(shí)間(例如：max-age)和提供驗(yàn)證令牌(Etag)來避免傳送無變化的字節(jié)。用Service Worker緩存一方面可以讓應(yīng)用程序網(wǎng)絡(luò)更加靈活，另一方面也可以讓你能夠快速訪問像V8代碼緩存這樣的功能。長期緩存可以去了解下Webpack帶哈希值文件名(filename hashing)。

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

解析/編譯

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

Bottom-Up/Call Tree允許我們?nèi)ゴ_切地查看解析/編譯所用時(shí)間：

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

但是，這為什么會(huì)是個(gè)問題?

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

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

相比于JavaScript，處理等字節(jié)的圖片所需要的時(shí)間成本很高(因?yàn)閳D片仍需要解碼!)但是在一般的移動(dòng)設(shè)備上，反而是JS更有可能對(duì)頁面的交互產(chǎn)生負(fù)面的影響。

(JavaScript字節(jié)和圖像字節(jié)耗費(fèi)的時(shí)間成本不同。圖像通常不會(huì)阻塞主線程，也不會(huì)在解碼和光柵化的時(shí)候阻止接口進(jìn)行交互。然而JS會(huì)因?yàn)榻馕?、編譯和執(zhí)行的時(shí)間消耗阻滯交互性。)

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

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

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

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

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

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

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

這就突出了在普通硬件(比如Moto G4)上測(cè)試的重要性，而不僅僅是在自己恰好有的手機(jī)上測(cè)試?；谧约嚎蛻粼械脑O(shè)備和網(wǎng)絡(luò)條件來進(jìn)行優(yōu)化是很重要的。

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

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

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

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

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

執(zhí)行時(shí)間

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

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

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

減少JavaScript交付成本的模式

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

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

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

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

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

JavaScript的其他消耗

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

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

Progressive Bootstrapping

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

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

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

Progressive Bootstrapping visual by Paul Lewis

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

結(jié)論

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

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

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

如果你正在建一個(gè)用于移動(dòng)設(shè)備上的站點(diǎn)，請(qǐng)盡可能的在代表性硬件上開發(fā)，保持較低的JavaScript解析/編譯的時(shí)間成本，并采用性能預(yù)算來確保團(tuán)隊(duì)對(duì)自身JavaScript的成本關(guān)注。