譯 the cost of JS

原文

當咱們構建的網頁大量依賴於Javascript，咱們有些時候須要研究那些不太容易看得見的消耗。在這篇文章中,我將介紹爲何一點規則能夠幫助若是你想讓你的網站加載&是交互式快速移動設備上。

Network 網絡

當大多數的開發者考慮Javascript的代價時，他們主要考慮的是下載和實行的消耗。在線上派遣更多的字節的JavaScript須要更長的時間用戶的鏈接。https://cdn-images-1.medium.c...*U00XcnhqoczTuJ8NH8UhOw.png

這是一個問題,即便在發達國家,做爲有效的網絡鏈接類型用戶可能不會是3g, 4g或WiFi。你多是在一個咖啡店連着2G的熱點。

你能夠減小網絡傳輸Javascript帶來的代價：

• 只傳輸用戶須要的 代碼分離能夠起效。
• 使用minify文件（ babel-minify or uglify-es for ES2015）
• 壓縮（Brotli, gzip or Zopfli ) Brotli對gzip在壓縮比例上效果顯著。 它幫助CertSimple節約了17%的JS字節和LinkedIn節約了4%的加載時間。
• 移除不須要的代碼 DevTools檢測代碼覆蓋率。對於單獨的代碼 如 tree-shaking, Closure Compiler的高級優化，庫插件 lodash-babel-plugin，Webpack的ContextReplacementPlugin像Moment.js 使用babel-preset-env & browserlist來避免在現代瀏覽器中已經被轉換的特性。高級開發人員可能會仔細分析他們的Webpack捆綁包，以幫助肯定減小沒必要要依賴。
• 緩存來減小網絡傳輸 肯定腳本的最佳生存期(max - age)&提供驗證令牌(ETag)，以免傳輸未更改的字節。服務人員緩存可使您的應用程序網絡具備彈性，並使您可以訪問V8的代碼緩存等特性。瞭解關於文件名散列的長期緩存。

工具(https://cdn-images-1.medium.c...*8Spf9To8dzTG3Xy9s57oVA.png)

Parse/Compile 解析

一旦下載下來，JavaScript最大的開銷之一就是使用JS引擎來解析/編譯此代碼。在Chrome DevTools中，解析和編譯是性能面板中黃色「腳本」時間的一部分。

自底向上/調用樹容許查看準確的解析/編譯時間:
https://cdn-images-1.medium.c...*GdrVt_BTTzzBOIoyZZsQZQ.png

爲何這是一個問題？
https://cdn-images-1.medium.c...*Dirw7RdQj9Dktc-Ny6-xbA.png

https://cdn-images-1.medium.c...*Dirw7RdQj9Dktc-Ny6-xbA.png

花很長時間解析/編譯代碼會極大地延遲用戶與站點交互的速度。您發送的JavaScript越多，在您的站點進行交互以前解析和編譯它的時間就越長。

https://cdn-images-1.medium.c...*6Y665hpxfWNMu2EXu3VGlw.png

Byte-for-byte, JavaScript is more expensive for the browser to process than the equivalently sized image or Web Font — Tom Dale

意思就是 對於瀏覽器來講，JS比同等大小的圖片和web字體更昂貴。

與JavaScript相比，處理至關大小的圖像須要花費大量的成本(它們仍然須要被解碼!)，可是在普通的移動硬件上，JS更有可能對頁面的交互性產生負面影響。

JS VS image: https://cdn-images-1.medium.c...*PRVzNizF9jQ_QADF5lQHpA.png

當咱們討論解析和編譯速度慢時，執行環境很重要，咱們討論的普通手機。用戶能夠是擁有慢CPU和GPU的手機沒有L2/L3緩存，甚至多是內存受限。

Network capabilities and device capabilities don’t always match up. A user with an amazing Fiber connection doesn’t necessarily have the best CPU to parse and evaluate JavaScript sent to their device. This is also true in reverse..a terrible network connection, but a blazing fast CPU. — Kristofer Baxter, LinkedIn

JavaScript中啓動性能,我注意到在低,高端的硬件上解析~ 1 mb解壓(簡單的)JavaScript的成本。在市場上最快的手機和普通手機之間解析/編譯代碼存在有2-5x的時間差別。

真實的網站如CNN，在高端手機iPhone8上花費約4s解析和編譯CNN的JS，而普通手機（moto G4) 花費約13s.這速度能夠顯著影響用戶與這個網站的交互。

這強調了平均測試硬件的重要性(如Moto G4)而不是你口袋裏的手機。然而環境問題:優化設備和網絡環境的用戶。

分析能夠提供深刻了解實際用戶訪問你的網站使用移動設備。這能夠提供機會了解真正約束CPU /GPU他們的操做。

Are we really sending down too much JavaScript?

使用HTTP存檔(~ 500 k網站)來分析JavaScript在移動設備上的狀態,咱們能夠看到50%的網站花費14秒去響應交互。這些網站僅僅爲了解析和編譯JS花了4秒。

https://cdn-images-1.medium.c...*sVgunAoet0i5FWEI9NSyMg.png

從頁面中刪除非關鍵的JavaScript能夠減小傳輸時間、cpu密集型解析和編譯以及潛在的內存開銷。這也有助於讓你的頁面更快捷。

執行時間 Execution Time

執行時間:https://cdn-images-1.medium.c...*ec0wEKKVl7iQidBks3oDKg.png
不只僅是解析和編譯花費時間。 JavaScript執行(運行代碼一次解析/編譯)的操做,必須在主線程上。 長的執行時間也能夠推出用戶於這個網站的交互時間。

If script executes for more than 50ms, time-to-interactive is delayed by the entire amount of time it takes to download, compile, and execute the JS — Alex Russell

爲了解決這個問題，Javascript能從小塊中獲益，以免鎖定主線程。探索你是否能減小在執行過程當中完成的工做量。

模式用於減小JS的代價

當你試圖保持解析JavaScript /編譯&網絡傳輸時間慢,模式像基於路徑分割或PRPL能夠起到幫助。

PRPL是經過積極互動的模式,優化代碼分隔和緩存。

PRPL 模式
https://cdn-images-1.medium.c...*VgdNbnl08gcetpqE1t9P9w.png

讓咱們來可視化下它帶來的影響。

咱們能夠分析普通手機上的網站加載時間和使用V8運行回調的漸進式應用。咱們能夠看到解析時間(橙色所示)是一個重要的部分,不少的這些網站自由支配本身的時間

wego 網站是使用了PRPL， 設法保持低解析時間的路線,讓互動很是快。面的許多其餘網站採用代碼分隔和績效預算試圖下降JS成本。

其餘花銷

JS在其餘方面影響網頁性能：

• 內存 頁面會出現閃避或因爲GC(垃圾收集)帶來的常常性暫停。當瀏覽器回收內存,JS執行停了下來，因此瀏覽器常常收集垃圾能夠暫停執行比咱們可能更頻繁。避免內存泄漏和頻繁的gc暫停繼續頁面閃避。
• 在運行過程當中，長時間運行的JavaScript能夠阻塞主線程致使頁面沒有響應。分割成小塊(使用requestAnimationFrame()或requestIdleCallback(調度))能夠最小化響應問題

進步的Bootstrapping

許多網站優化內容的可見性是以昂貴的交互爲代價。當你有大量的JS塊時，爲了得到快速的渲染，開發者經常採用server-side渲染方式。而後當JS最終被取出時，upgrade附加事件？？

請注意： 這有內在的花銷。1）一般發送更大的HTML響應,能夠推進咱們的交互性 2）可使用戶在一個恐怖谷理論？？ 一半的性能是不能實際交互的要等到JS徹底處理結束。

Progressive Bootstrapping多是一個好方法。發送一個最小功能的頁面（包含實行當前功能的JS/HTML/CSS）。當更多的資源到達時，應用能夠lazy-load 和釋放更多的特徵。

合理的加載代碼是一個聖盃。PRPL和漸進的引導模式能夠實現這種想法。

總結

傳輸大小對低端網絡相當重要。解析時間爲CPU綁定的設備是很重要的。保持低這些問題。

團隊發現採用嚴格的績效預算成功地減小了他們的JavaScript傳輸和解析/編譯時間。Alex Russell’s Can yo afford it?: Real-world Web Performance Budgets

若是你在構建一個目標設備是移動端的，盡力發展典型的硬件上,下降你的JavaScript解析/編譯時間,採用績效預算,以確保你的團隊可以關注他們的JavaScript成本。