JavaScript的成本

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

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

網絡

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

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

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

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

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

解析/編譯

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

我們真的發送了太多的JavaScript了嗎？呃...真有可能:)

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

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

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

執行時間

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

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

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

減少JavaScript交付成本的模式

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

PRPL是一種通過激進的（aggresive）代碼分割和緩存來優化交互性的模式：

為了能將PRPL的影響以視覺化方式表現出來。

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

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

JavaScript的其他消耗

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

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

Progressive Bootstrapping

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

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

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

Progressive Bootstrapping visual by Paul Lewis

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

結論

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

有團隊發現采用嚴格的性能預算可以成功降低他們JavaScript的傳輸和解析/編譯的時間消耗。具體可參照Alex Russell的“ Can You Afford It?: Real-world Web Performance Budgets ” 一文中關于移動設備預算的指導。

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

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

更多相關學習

( 點擊觀看視頻 ，作者2017年在Chrome Dev Summit上的演講，其中涵蓋了本文內容，其后就Pinterest和Tinder這樣的制作網站進行了性能案例研究 ）

• JavaScript啟動性能
• 解決網站性能危機 ——Nolan Lawson
• 你付的起嗎？真實世界的性能預算 ——Alex Russell
• 評估web的框架和庫 ——Kristofer Baxter
• 用Brotli壓縮cloudflare的試驗結果 （注意，高質量的動態Broti可以延遲初始頁面的渲染，所以要仔細評估。取而代之地，你或許會想要用靜態壓縮。）
• 性能特點 ——Sam Saccone

 

 

來自：http://www.infoq.com/cn/articles/the-cost-of-javascript