當我們建立嚴重依賴於JavaScript的網站時，我們不總是很容易看到我們傳送的內容所付出的代價。在這篇文章中，如果你希望你的網站在移動裝置上能夠快速載入和互動，我將介紹為什麼一些規則可以幫助你。
tl;dr：較少的程式碼=較少的解析/編譯+較少的傳輸+較少的解壓縮
網路
當大多數開發人員考慮JavaScript的成本時，他們會考慮下載和執行成本。通過線路傳送更多位元組的JavaScript需要的時間越長，使用者的連線也就越慢。
這可能是一個問題，即使在已開發國家，因為使用者有效的網路連線型別可能實際上並不是3G，4G或WiFi。你可能在咖啡店使用Wifi，但連線到的是2G的蜂窩熱點。
您可以通過以下方式降低 JavaScript的網路傳輸成本：
-
只傳送使用者需要的程式碼。程式碼拆分這時候就有用武之地了。
-
壓縮程式碼（ES515的 Uglify， ES2015的 babel- minify或uglify -es）
-
高度壓縮（使用Brotli〜q11，Zopfli或gzip的）。Brotli的壓縮比超過Gzip。它讓CertSimple節省了17％的JS壓縮位元組大小，LinkedIn節省了 4％的載入時間。
-
刪除未使用的程式碼。通過DevTools程式碼覆蓋來確定。對於剝離的程式碼，可以檢視tree shaking，閉包編譯器的高階優化和微調庫外掛如lodash-babel-plugin外掛或WebPack的ContextReplacementPlugin如Moment.js庫。使用babel-preset-env和browserlist來避免現代瀏覽器中已經存在的轉譯功能。高階開發人員可能會發現仔細分析Webpack捆綁包有助於識別修剪不需要的依賴關係。
-
使用HTTP快取以儘量減少網路跳轉。確定指令碼的最佳生命週期（max-age）和提供令牌驗證（ETag）以避免傳輸沒有變更的位元組。Service Worker快取可以使您的應用程式網路具有彈性，讓您可以快速訪問V8的程式碼快取等功能。瞭解有關檔名雜湊的長期快取。
解析/編譯
一旦JS下載完畢，JavaScript最大的一個成本就是JS引擎解析/編譯這段程式碼的時間。在Chrome DevTools中，解析和編譯是“效能”皮膚中黃色“指令碼”時間的一部分。
Bottom-Up/Call Tree允許檢視確切的解析/編譯時序：
Chrome DevTools“效能”皮膚>自下而上。通過啟用V8的執行時呼叫統計，我們可以看到分析和編譯階段花費的時間
但是，為什麼這會有問題呢？
花費很長時間解析/編譯程式碼會嚴重延遲使用者與網站互動的時間。傳送的JavaScript越多，在網站互動之前解析和編譯的時間就越長。
同樣多的位元組，瀏覽器處理JavaScript要比同等大小的影像或Web字型開銷更大。 – Tom Dale
與JavaScript相比，在處理等效大小的圖片時（涉及到大量的圖片仍然需要解碼！），涉及到大量的開銷，但是在一般的移動裝置上，JS更有可能對頁面的互動性產生負面影響。
JavaScript和影像位元組的開銷有很大的不同。影像通常不會阻塞主執行緒，也不會阻止介面在解碼和柵格化時進行的互動。然而JS由於解析，編譯和執行的成本會延遲互動性。
當我們談論解析和編譯變慢的時候，上下文很重要 – 我們在這裡談論的普通手機。指的是大部分使用者使用的CPU和GPU速度較慢的手機，無L2 / L3快取，甚至可能記憶體很小。
網路功能和裝置功能並不總是相匹配。使用光纖連線的使用者不一定有最好的CPU來解析和執行傳送到他們的裝置的JavaScript。反過來也是如此。一個糟糕的網路連線，但卻有一個快速的CPU。 – Kristofer Baxter，LinkedIn
在JavaScript啟動效能中，我注意到在低端和高階硬體上解析大約1MB已經被解壓的（簡單）JavaScript的開銷。在市場上最快的手機和普通手機之間解析/編譯程式碼的時間有2-5倍的差異。
在不同類別的桌面和移動裝置上解析一個1MB的JavaScript包（約有250KB 被gzip壓縮了）的解析時間。在檢視解析的開銷時，解壓後的資料要考慮到大約有250KB 被gzip壓縮的空間會被釋放出來當解壓縮大約1MB的程式碼的時候
那麼現實世界的網站如何呢，如CNN.com
在高階的iPhone 8上，解析/編譯CNN的JS需要花費大約4秒，而普通手機（Moto G4）則只需要13秒。這可以顯著影響使用者與本網站完全互動的速度。
蘋果的A11仿生晶片和非常普通的Android硬體中的Snapdragon 617的解析時間效能比較。
這突出了普通硬體（如Moto G4）測試的重要性，而不僅僅是口袋裡的手機。但是，使用環境很重要：優化您的使用者擁有的裝置和網路條件。
分析可以深入瞭解您的真實使用者訪問您的網站的移動裝置類別。這可以提供機會來了解他們正在使用的真正的CPU / GPU的限制。
我們是否真的傳送了太多的JavaScript？錯誤，這很有可能:)
使用HTTP Archive（最高大約50萬個站點）來分析移動裝置上JavaScript的狀態，我們可以看到，50％的站點需要14秒才能獲得互動。僅僅只是解析和編譯JS，這些網站就花費長達4秒。
在獲取和處理JS和其他資源所花費的時間中，因為感覺網頁已經可以使用，使用者可能會等待一段時間，這也許並不奇怪。但我們一定可以在這裡做得更好。
從網頁中刪除不重要的JavaScript可以減少傳輸時間，CPU密集型解析和編譯以及潛在的記憶體開銷。這也有助於讓您的網頁更快地互動。
執行時間
這不僅僅是解析和編譯，而且可能會帶來額外的開銷。JavaScript執行（一次解析/編譯執行程式碼）是在主執行緒上發生的操作之一。很長的執行時間也可以推出使用者可以與網站互動的時間。
如果指令碼執行時間超過50ms，則互動時間會被下載，編譯和執行JS所花時間延遲了 – Alex Russell
為了解決這個問題，JavaScript受益於small chunks，以避免鎖定主執行緒。探索是否可以減少執行過程中正在進行的工作量。
減少JavaScript傳送開銷的模式
當你試圖保持JavaScript的解析/編譯和網路傳輸時間很慢時，有一些模式可以幫助像基於路由的分塊(route-based chunking)或PRPL。
PRPL是一種通過程式碼分割和快取來優化互動性的模式：
讓我們看看它可以產生的影響。
我們使用V8的執行時呼叫統計來分析流行移動網站和Progressive Web Apps的載入時間。正如我們所看到的，解析時間（以橙色顯示）是許多這些站點花費時間的比較大的部分：
Wego是一個使用PRPL的網站，它設法保持較低的路由解析時間，能夠非常迅速地進行互動。上面的許多其他站點都採用程式碼分解和效能預算來降低JS的開銷。
其他開銷
JavaScript可以通過其他方式影響頁面效能：
-
記憶體。由於GC（垃圾收集），頁面可能經常會出現卡頓或暫停。當瀏覽器回收記憶體時，JS執行被暫停，所以經常進行垃圾收集的瀏覽器可以比我們想要的更頻繁地暫停執行。避免記憶體洩漏和頻繁的gc暫停，以保持頁面流暢。
-
在執行時，長時間執行的JavaScript可以阻止主執行緒導致無響應的頁面。將工作分成更小的部分（使用requestAnimationFrame（）或有計劃的使用requestIdleCallback（））可以最大限度地減少響應性問題。
漸進式引導
許多網站將內容可視性作為互動性的代價來優化。為了在有大的JavaScript包時獲得一個快速的首頁，開發者有時會使用伺服器端渲染;然後在JavaScript最終獲取時將其“升級”以附加事件處理程式。
小心 – 這有它自己的開銷。1）這通常會傳送一個更大的 HTML響應，這會延遲互動性，2）這會把使用者留在一個離奇的山谷中，其中有一半的實際功能是沒有辦法互動的，直到JavaScript執行完成。
漸進式引導可能是一個更好的方法。傳送一個最小功能的頁面（由當前路由所需的HTML / JS / CSS組成）。隨著更多的資源到達，該應用程式可以延遲載入和解鎖更多的功能。
Paul Lewis的漸進式引導視覺
根據所看到的載入程式碼是聖盃。PRPL和漸進引導是可以幫助實現這一點的模式。
結論
傳輸大小對低端網路至關重要。解析時間對於CPU受限的裝置很重要。保持這兩者的抵開銷。
團隊發現成功採用嚴格的效能預算來保持JavaScript傳輸和解析/編譯時間較短。請參閱Alex Russell的“ 您可以承受嗎？：真實世界的Web效能預算 ”，以獲取關於移動預算的指導。
考慮一下我們製作的架構決策可以為應用程式邏輯留下多少JS“空間”。
如果您正在構建針對移動裝置的網站，請儘可能在代表性硬體上開發，保持較低的JavaScript分析/編譯時間，並採用效能預算來確保您的團隊能夠關注其JavaScript成本。