摘要：高級開發(fā)人員可能會仔細(xì)分析他們的捆綁包，以幫助確定減少不必要依賴。在運(yùn)行過程中，長時間運(yùn)行的可以阻塞主線程導(dǎo)致頁面沒有響應(yīng)。然后當(dāng)最終被取出時，附加事件請注意這有內(nèi)在的花銷。發(fā)送一個最小功能的頁面包含實(shí)行當(dāng)前功能的。保持低這些問題。

原文

當(dāng)我們構(gòu)建的網(wǎng)頁大量依賴于Javascript，我們有些時候需要研究那些不太容易看得見的消耗。在這篇文章中,我將介紹為什么一點(diǎn)規(guī)則可以幫助如果你想讓你的網(wǎng)站加載&是交互式快速移動設(shè)備上。

當(dāng)大多數(shù)的開發(fā)者考慮Javascript的代價時，他們主要考慮的是下載和實(shí)行的消耗。在線上派遣更多的字節(jié)的JavaScript需要更長的時間用戶的連接。https://cdn-images-1.medium.c...*U00XcnhqoczTuJ8NH8UhOw.png

這是一個問題,即使在發(fā)達(dá)國家,作為有效的網(wǎng)絡(luò)連接類型用戶可能不會是3g, 4g或WiFi。你可能是在一個咖啡店連著2G的熱點(diǎn)。

你可以減少網(wǎng)絡(luò)傳輸Javascript帶來的代價：

只傳輸用戶需要的 代碼分離可以起效。

使用minify文件（ babel-minify or uglify-es for ES2015）

壓縮（Brotli, gzip or Zopfli ) Brotli對gzip在壓縮比例上效果顯著。 它幫助CertSimple節(jié)約了17%的JS字節(jié)和LinkedIn節(jié)約了4%的加載時間。

移除不需要的代碼 DevTools檢測代碼覆蓋率。對于多帶帶的代碼 如 tree-shaking, Closure Compiler的高級優(yōu)化，庫插件 lodash-babel-plugin，Webpack的ContextReplacementPlugin像Moment.js 使用babel-preset-env & browserlist來避免在現(xiàn)代瀏覽器中已經(jīng)被轉(zhuǎn)換的特性。高級開發(fā)人員可能會仔細(xì)分析他們的Webpack捆綁包，以幫助確定減少不必要依賴。

緩存來減少網(wǎng)絡(luò)傳輸 確定腳本的最佳生存期(max - age)&提供驗(yàn)證令牌(ETag)，以避免傳輸未更改的字節(jié)。服務(wù)人員緩存可以使您的應(yīng)用程序網(wǎng)絡(luò)具有彈性，并使您能夠訪問V8的代碼緩存等特性。了解關(guān)于文件名散列的長期緩存。

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

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

自底向上/調(diào)用樹允許查看準(zhǔn)確的解析/編譯時間:
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

花很長時間解析/編譯代碼會極大地延遲用戶與站點(diǎn)交互的速度。您發(fā)送的JavaScript越多，在您的站點(diǎn)進(jìn)行交互之前解析和編譯它的時間就越長。

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相比，處理相當(dāng)大小的圖像需要花費(fèi)大量的成本(它們?nèi)匀恍枰唤獯a!)，但是在普通的移動硬件上，JS更有可能對頁面的交互性產(chǎn)生負(fù)面影響。

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

當(dāng)我們討論解析和編譯速度慢時，執(zhí)行環(huán)境很重要，我們討論的普通手機(jī)。用戶可以是擁有慢CPU和GPU的手機(jī)沒有L2/L3緩存，甚至可能是內(nèi)存受限。

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的成本。在市場上最快的手機(jī)和普通手機(jī)之間解析/編譯代碼存在有2-5x的時間差異。

真實(shí)的網(wǎng)站如CNN，在高端手機(jī)iPhone8上花費(fèi)約4s解析和編譯CNN的JS，而普通手機(jī)（moto G4) 花費(fèi)約13s.這速度可以顯著影響用戶與這個網(wǎng)站的交互。

這強(qiáng)調(diào)了平均測試硬件的重要性(如Moto G4)而不是你口袋里的手機(jī)。然而環(huán)境問題:優(yōu)化設(shè)備和網(wǎng)絡(luò)環(huán)境的用戶。

分析可以提供深入了解實(shí)際用戶訪問你的網(wǎng)站使用移動設(shè)備。這可以提供機(jī)會了解真正約束CPU /GPU他們的操作。

Are we really sending down too much JavaScript?

使用HTTP存檔(~ 500 k網(wǎng)站)來分析JavaScript在移動設(shè)備上的狀態(tài),我們可以看到50%的網(wǎng)站花費(fèi)14秒去響應(yīng)交互。這些網(wǎng)站僅僅為了解析和編譯JS花了4秒。

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

從頁面中刪除非關(guān)鍵的JavaScript可以減少傳輸時間、cpu密集型解析和編譯以及潛在的內(nèi)存開銷。這也有助于讓你的頁面更快捷。

執(zhí)行時間:https://cdn-images-1.medium.c...*ec0wEKKVl7iQidBks3oDKg.png
不僅僅是解析和編譯花費(fèi)時間。 JavaScript執(zhí)行(運(yùn)行代碼一次解析/編譯)的操作,必須在主線程上。 長的執(zhí)行時間也可以推出用戶于這個網(wǎng)站的交互時間。

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能從小塊中獲益，以避免鎖定主線程。探索你是否能減少在執(zhí)行過程中完成的工作量。

當(dāng)你試圖保持解析JavaScript /編譯&網(wǎng)絡(luò)傳輸時間慢,模式像基于路徑分割或PRPL可以起到幫助。

PRPL是通過積極互動的模式,優(yōu)化代碼分隔和緩存。

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

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

我們可以分析普通手機(jī)上的網(wǎng)站加載時間和使用V8運(yùn)行回調(diào)的漸進(jìn)式應(yīng)用。我們可以看到解析時間(橙色所示)是一個重要的部分,很多的這些網(wǎng)站自由支配自己的時間

wego 網(wǎng)站是使用了PRPL， 設(shè)法保持低解析時間的路線,讓互動非?？?。面的許多其他網(wǎng)站采用代碼分隔和績效預(yù)算試圖降低JS成本。

JS在其他方面影響網(wǎng)頁性能：

內(nèi)存 頁面會出現(xiàn)閃避或由于GC(垃圾收集)帶來的經(jīng)常性暫停。當(dāng)瀏覽器回收內(nèi)存,JS執(zhí)行停了下來，所以瀏覽器經(jīng)常收集垃圾可以暫停執(zhí)行比我們可能更頻繁。避免內(nèi)存泄漏和頻繁的gc暫停繼續(xù)頁面閃避。

在運(yùn)行過程中，長時間運(yùn)行的JavaScript可以阻塞主線程導(dǎo)致頁面沒有響應(yīng)。分割成小塊(使用requestAnimationFrame()或requestIdleCallback(調(diào)度))可以最小化響應(yīng)問題

許多網(wǎng)站優(yōu)化內(nèi)容的可見性是以昂貴的交互為代價。當(dāng)你有大量的JS塊時，為了獲得快速的渲染，開發(fā)者常常采用server-side渲染方式。然后當(dāng)JS最終被取出時，upgrade附加事件？？

請注意： 這有內(nèi)在的花銷。1）通常發(fā)送更大的HTML響應(yīng),可以推動我們的交互性 2）可以使用戶在一個恐怖谷理論？？ 一半的性能是不能實(shí)際交互的要等到JS完全處理結(jié)束。

Progressive Bootstrapping可能是一個好方法。發(fā)送一個最小功能的頁面（包含實(shí)行當(dāng)前功能的JS/HTML/CSS）。當(dāng)更多的資源到達(dá)時，應(yīng)用可以lazy-load 和釋放更多的特征。

合理的加載代碼是一個圣杯。PRPL和漸進(jìn)的引導(dǎo)模式可以實(shí)現(xiàn)這種想法。

傳輸大小對低端網(wǎng)絡(luò)至關(guān)重要。解析時間為CPU綁定的設(shè)備是很重要的。保持低這些問題。

團(tuán)隊(duì)發(fā)現(xiàn)采用嚴(yán)格的績效預(yù)算成功地減少了他們的JavaScript傳輸和解析/編譯時間。Alex Russell’s Can yo afford it?: Real-world Web Performance Budgets

如果你在構(gòu)建一個目標(biāo)設(shè)備是移動端的，盡力發(fā)展典型的硬件上,降低你的JavaScript解析/編譯時間,采用績效預(yù)算,以確保你的團(tuán)隊(duì)能夠關(guān)注他們的JavaScript成本。