漫談JavaScript開銷

摘要： 本文來自於 Google Chrome 的一位工程師，致力於研究WEB響應速度。即便是手機效能得到了大幅提升的2018年，JavaScript 的成本消耗在移動端依然不可小覷，那麼JavaScript都為我們的使用者帶來了哪些消耗？又有哪些優化方法？ 文中包含 YouTube視訊，Twit...

本文來自於 Google Chrome 的一位工程師，致力於研究WEB響應速度。即便是手機效能得到了大幅提升的2018年，JavaScript 的成本消耗在移動端依然不可小覷，那麼JavaScript都為我們的使用者帶來了哪些消耗？又有哪些優化方法？

文中包含 YouTube視訊，Twitter, 請科學上網。

構建互動式網站涉及到向用戶傳送JavaScript，大部分站點，JS指令碼非常多。你是否在一個看起來載入好的移動頁面上嘗試點選或滾動頁面時卻沒有任何響應？

在移動端，JS檔案依然是最至關重要的資源，因為它可以極大的延遲使用者與我們頁面的互動。

今天我們將介紹一些提高JavaScript效率(效能)的策略，為使用者提供良好的體驗。

概括

• 為了快速載入，只加載當前頁面需要的JavaScript

  優先載入使用者需要的內容，並且通過ofollow,noindex" target="_blank">code-splitting 延遲載入其他的內容。這是處理檔案載入和使用者互動（之間的平衡）的最佳方法。基於路由堆疊的程式碼分割是遊戲改變者 。

• 學會效能預估，開發中時刻關注效能

  在移動端，一個壓縮後的JS檔案應該在170KB以內。這部分程式碼（170KB）未壓縮的情況下有.7MB。（效能）預估對一個成功的網站至關重要，然而，不能指望它神奇的孤立的修復所有效能問題。團隊文化，團隊文化，以及團隊執行力 ，這些同樣重要。一個沒有（效能）預估的網站構建會導致效能倒退和失敗。

• 學會如何審查並精簡你的JavaScript程式碼包

  大部分情況下，你只需要庫的小部分功能但是你卻引入了整個庫，其中包含著大部分瀏覽器的polyfills或者重複程式碼。

• 每次交流都是下一次交流的開始；在交流中尋找最佳優化

  傳輸（檔案的）大小對於低端行動網路至關重要，而裝置的CPU 對於 JavaScript 解析時間至關重要。

• 如果客戶端渲染沒有提升使用者體驗，你需要反思一下否真的有必要這麼做。

  也許伺服器端渲染的 HTML 會更快。考慮只在絕對需要客戶端渲染的頁面上才使用客戶端框架。如果做得不好，伺服器渲染和客戶端渲染都會成為一場災難。

WEB 因使用者“體驗”而膨脹

當用戶訪問您的站點時，您可能會發送大量檔案，其中許多是指令碼。 從Web瀏覽器的角度來看，這看起來有點像這樣：

雖然我非常喜歡JavaScript，但它始終是您網站中開銷最大的部分。我想解釋一下這個主要問題。

目前一箇中等WEB網站需要傳輸 350KB 左右的壓縮JavaScript。瀏覽器需要處理這部分程式碼解壓後大小超過了1MB。

注意：如果你不確定你的 JavaScript 包是否會延遲使用者與你網站的可互動速度？可以通過Lighthouse

來自HTTP存檔狀態的JavaScript報告的統計資料 ，2018年7月 ,突出顯示中間網頁傳輸壓縮後的 JavaScript 資源約為 350KB。這些頁面最多需要15秒才具備可互動性

根據經驗，在移動裝置上這麼多JavaScript下載完成到使用者可互動需要超過14S的時間。

其中一個重要因素是在行動網路上下載程式碼和在移動裝置的CPU上解析需要多長時間。

看看全球的行動網路狀態。

在特定指標中表現更好的國家的顏色更深。未包括的國家是灰色的。同樣值得注意 的是，即使在美國，農村寬頻速度也比城市地區慢20％。

OpenSignal的這張圖表 顯示了4G網路在全球範圍內的可靠性以及每個國家/地區的平均連線速度使用者體驗。 我們可以看到，許多國家的連線速度仍然比我們想象的要低。

不僅僅像之前我們說的一箇中等網站需要一定時間來來下載350KB的指令碼，事實上我們訪問一個流行網站時，他們下載的指令碼遠比這多得多：

壓縮的JS包大小資料來自“Bringing Facebook.com and the web up to speed” 像Google表格這樣的網站會突出顯示為傳輸最多5.8MB的指令碼（解壓縮時）。

這些網站需要瀏覽器下載和解析的程式碼達到了數兆（MB）位元組，桌面和移動頁面上都達到了這個上限。想問的是，你能接受這麼的JavaScript嗎？

JavaScript有成本

注意：如果您下載的指令碼太多，請考慮使用程式碼分割 來分解包或使用tree-shaking減少JS有效負載 。

當今的網站通常會在他們的JS包中包含以下內容：

• 客戶端的框架或者 UI 庫；
• 狀態管理解決方案（例如 Redux）；
• Polyfills（通常被用於不需要它們的現代瀏覽器）；
• 完整的庫 VS. 僅需要的內容（例如，所有lodash，Moment +語言環境）
• 一套 UI 元件（按鈕，標題，側邊欄等）

這段程式碼使用的越多，頁面載入所需的時間就越長。

載入一個網頁就像一個有三個關鍵時刻的電影故事。

分別是：載入是否被觸發？載入的內容是否是有用？以及載入的內容是否可用？

載入是否被觸發是你能夠將一些內容傳輸到螢幕的那一刻。 （頁面是否開始跳轉？服務端是否開始響應？）

載入的內容是否是有用是您繪製文字或內容的時刻，允許使用者從中獲取有價值的資訊並與之互動。

然後，載入的內容是否可用是當用戶可以開始與網頁進行有意義地互動併發生某些事情。

我之前提到了一個術語 “互動”，但他到底意味著什麼呢？

一個可互動頁面，他必須儘可能快的響應使用者的輸入。一個小的JavaScript可以確保網站的響應快速發生。

無論使用者點選了一個連結還是滾動頁面，他們都需要看到有實際的事情響應了他們的操作。如果無法得到相關的體驗會使使用者感到沮喪:person_frowning:。

這種情況經常發生在伺服器端端渲的頁面，然後隨後傳送一堆 JavaScript 來“潤滑”介面（附加事件處理程式和額外行為）

當瀏覽器執行許多可能需要的事件時，它可能會在處理使用者輸入的同一執行緒上進行。這個執行緒被稱為主執行緒。

將過多的JavaScript載入到主執行緒（通過 <script> 等）是個問題。將JS通過API/Web_Workers_API/Using_web_workers" rel="nofollow,noindex" target="_blank">Web Worker 或Service Worker 進行快取不會產生相同的負面等待互動（Time-to-Interactive）影響。

這是一個使用者可以點選某些UI的示例。 通常，他們可能會選中一個複選框或點選一個連結，一切都會正常工作。 但是如果我們模擬阻塞主執行緒，那麼任何事情都無法發生。 他們無法檢查該複選框或單擊連結，因為主執行緒被阻止。

避免儘可能地阻塞主執行緒。有關更多資訊，請參閱“為什麼Web開發人員需要關注互動性” 。

我們看到了我們的合作團隊在許多型別的網站上都碰到 JavaScript 影響互動性的情況。

太多（主執行緒）JavaScript可以延遲可見元素的互動性。 這對許多公司來說都是一個挑戰。

以上是Google搜尋中的一些示例，您可以從一開始使就使用這些UI，但如果某個網站執行過多的JavaScript，則可能會在實際發生某些事情之前出現延遲。 這會讓使用者感到有點沮喪。 理想情況下，我們希望所有互動儘快響應。

通過測試Google新聞在移動裝置上的可互動時間，我們觀察到高階裝置大約7秒內實現互動，而低端裝置需要55秒，差異巨大。那麼，互動性的最佳目標（時間）是多少呢 ？

談到Time to Interactive ，我們認為您的基準應該是在中等移動裝置上的慢速3G連線可以在五秒左右就能進行互動。 “但是，我的使用者都在使用快速網路和高階手機！”……是嗎？ 你可能會使用“快速”的咖啡店WiFi，但實際上只能獲得2G或3G的速度。意外不驚喜不。

誰減少了 JavaScript 並減少了他們的可互動時間？

• Pinterest 將他們的 JavaScript 包從 2.5MB 降低到小於 200KB，而可互動時間從23秒降到5.6s 。收入增長44％，註冊增長753％，移動網際網路周活躍使用者 增長103％

• AutoTrader 將 JavaScript bundle 大小降低了 56% 並將達到 Time-to-Interactive 的時長縮短了約50％ 。

• Nikkei 將 JavaScript 包大小降低了 43% 並將可互動耗時縮短了14秒 。

讓我們設計一個更具通用性的移動網站，不依賴於大型JavaScript。

互動會受到很多事情影響。它可能受影響於載入您的網站在移動資料計劃，或咖啡店WiFi，或只是他們旅途中的間歇性網路連線。

當這種情況發生時，而你的網站有很多JavaScript 需要處理，使用者會結束等待頁面呈現內容。或者，頁面呈現某些東西，在他們能進行任何互動前需要等待很長時間。

理想情況下，減少傳輸JavaScript可以緩解這些問題。

為什麼JavaScript 開銷如此高昂？

要解釋JavaScript為何有如此大的開銷，我想向您介紹將內容傳送到瀏覽器的過程中都發生了什麼。 使用者在瀏覽器的位址列中鍵入URL：

一條請求被髮送到伺服器，然後伺服器返回html。 然後，瀏覽器會解析該html並提取必要的CSS，JavaScript和影象。 然後，瀏覽器必須獲取並處理所有這些資源。

上面的場景準確描述了Chrome在處理您傳送的所有內容時所發生的事情（是的，它是一個巨大的表情符號工廠）。

這裡面臨的挑戰之一是 JavaScript 最終成為瓶頸。理想情況下，我們希望能夠快速繪製畫素，然後讓頁面可互動。但如果 JavaScript 是一個瓶頸，你最終只能看到一些你無法與之互動的東西。

我們希望阻止JavaScript成為現代網站體驗的瓶頸。

作為一個開發者我們需要時刻記在心中的是，如果我們想要JavaScript變快，我們需要讓下載，解析，編譯，執行整個過程變得更快。

這意味著我們不僅要保證快速的網路傳輸，還要保證快速的指令碼處理能力。

如果您花費很長時間在JavaScript引擎中解析和編譯指令碼，那就會延遲使用者與您網站的互動時間。

為了提供一些關於此的資料，這個是V8 （Chrome 的 JavaScript 引擎）在處理包含指令碼的頁面時花費時間的細分統計圖：

橙色代表了主流網站解析JS檔案所需要的時間。黃色是編譯的時間。兩者加起來，頁面需要花費高達30%的時間來處理JavaScript -這些開銷是真實存在的。

從Chrome 66開始，V8在後臺執行緒上編譯程式碼 ，將編譯時間縮短了20％。 但是解析和編譯仍然非常昂貴，並且很少看到大型指令碼能在50ms內執行完成，即使是線上程外編譯也是如此。

關於JavaScript另一個需要注意的是每一位元組都是不相等的。一個200KB的指令碼和一個200KB的影象所造成的開銷是完全不一樣的。

它們可能需要相同的時間來下載，但是在處理時開銷並不相同。

一個JPEG圖片要顯示在螢幕上需要經過解碼，柵格化和繪製。一個JavaScript包需要下載然後解析，編譯，執行-並且引擎需要完成許多其他步驟 。請注意，這些成本並不完全相同。

人們開始重視 JavaScript 開銷問題的一個重要的原因是移動端。

移動裝置就是一個頻譜

如果我們足夠幸運，可能會擁有一部高階或中端手機。 現實情況是並非所有使用者都擁有這些裝置。

他們可能使用低端或中端的手機，這些裝置之間的差異也可能非常明顯；散熱、快取記憶體大小、CPU、GPU – 基於您使用的裝置，您最終經歷的JavaScript等資源的處理時間可能完全不同。即便在美國也存在低端手機的使用者 。

以下是分析2018年可用硬體解析JavaScript所需時間的細分：

最上面高階裝置，如iPhone 8，它可以相對快速地處理指令碼。 下面更多的是普通手機，如 Moto G4 和 < $100 的阿爾卡特 1X。 注意處理時間的差異？

隨著時間的推移，Android手機越來越便宜，而不是更快 。 這些裝置通常CPU較差，具有微小的L2 / L3快取記憶體大小。如果您希望他們都擁有高階硬體，那麼普通使用者就會流失。

讓我們通過來自現實網站的指令碼來檢視這個問題的更實用版本。 這 CNN.com 的JS處理時間：

在iPhone 8（使用A11晶片）上處理CNN的JavaScript比在普通手機上花費少9秒。 這可以讓可互動時間快9秒。

既然WebPageTest支援阿爾卡特1X（在美國銷售約100美元的手機，在釋出時售罄），我們還可以看看在中低端硬體上載入CNN的過程。 通過對比三類機型的 filmstrips 片段，能看出低端機型甚至都不能簡單的用慢來形容了。

這提示我們，不要再理所當然的認為使用者都是使用快速網路和高效能裝置。

部分使用者可能無法使用高速的網路或者擁有最新款的手機，因此我們開始在真實的網路和真實的手機上進行測試變得至關重要。不可確定性確實是一個問題。

“可變性對使用者體驗的影響是致命的”——Ilya Grigorik。高階裝置有時候可能也會變得很慢。高速網路也會變慢，可變性最終會導致所有東西變慢。

當差異可能會破壞使用者體驗時，使用緩慢的基線進行開發可確保每個人（快速和慢速設定）都能獲益。 如果您的團隊可以檢視使用者的分析並準確瞭解您的使用者實際訪問您網站的裝置，這些將會提示您應該在辦公室中使用哪些裝置來測試您的網站。

webpagetest.org/easy 在【移動】配置項下預配置了很多 Moto G4。如果您無法購買自己的中端級硬體進行測試，這將非常有用。

這裡有很多配置檔案，你可以通過這些配置檔案使用已經預先配置好的主流裝置。例如，我們有一些中端裝置像 Moto G4可以用來測試。

在代表性網路上測試同樣非常重要。即使我之前說過中低端手機是多麼的重要，Brian Holt 說過，瞭解每一位使用者非常重要 。

並非每個站點都需要在低端手機上的2G上表現良好。也就是說，在整個頻譜範圍內實現高水平的效能並不是一件壞事。

您可能在頻譜的較高階或頻譜的不同部分擁有廣泛的使用者。請依據您網站背後的資料，以便您可以合理地判斷這些問題的重要性。

如果您希望JavaScript更快，需要注意低速網路的下載時間。您可以做的改進包括：減少程式碼，縮小原始碼，使用壓縮（如gzip ，Brotli ，和Zopfli ）。

使用快取解決使用者重複訪問。對CPU慢的手機，解析時間至關重要。

如果您是後端或全棧開發人員，您可以很容易獲得有關CPU，磁碟和網路的開銷。

當我們構建的網站越來越依賴JavaScript時，我們有時會以一種我們不太容易看到的方式為我們傳送的內容付出代價。

怎樣傳送更少的JavaScript

最直接的方式是我們傳送最少的指令碼給使用者，同時仍然給他們一個完整的體驗。程式碼分割 是一個可行的方案。

程式碼分割的思想是，它不向使用者傳送一個單一的龐大的JavaScript檔案包——像一個巨大的完整的披薩——如果一次只發送一小個片段會怎樣？只要讓當前頁面的功能可用就可以了。

程式碼拆分可以在頁面級別、路由級別或元件級別完成。很多現代庫和框架都通過Webpack 和Parcel 等打包工具來實現程式碼拆分。React 、Vue.js 和Angular 都提供了提供了這方面的指南。

// before.js
import OtherComponent from './OtherComponent';

const MyComponent = () => (
<OtherComponent/>
);

// after.js
import Loadable from 'react-loadable';

const LoadableOtherComponent = Loadable({
loader: () => import('./OtherComponent'),
loading: () => <div>Loading...</div>,
});

const MyComponent = () => (
<LoadableOtherComponent/>
);

使用React Loadable 在React應用中新增程式碼拆分 – 一個高階的元件，它在React友好的API中包裝動態匯入，以便在給定元件的應用程式中新增程式碼拆分。

許多大型團隊最近在使用程式碼分割方面取得了巨大成功。

為了儘可能快的讓使用者與他們的頁面發生互動，Twitter 和Tinder 在重構他們的移動站點時，最先使用了程式碼拆分，他們的站點的可互動時間提高的50%。

像Gatsby.js (React),Preact CLI 和PWA Starter Kit 這些技術框架嘗試強制使用好的預設配置，以便在中端移動硬體上快速載入和獲取互動。

許多這些網站還做的另一件事是：將審計分析 JavaScript 作為其工作流程的一部分。

值得慶幸的是，JavaScript生態系統有許多很棒的工具可以幫助進行程式碼包分析。

使用Webpack Bundle Analyzer 、Source Map Explorer 和Bundle Buddy 這些工具來分析程式碼包，尋找進行程式碼拆分的點。

這些工具視覺化JavaScript包的內容：它們突出顯示您可能不需要的大型庫，重複程式碼和依賴項。

來自 Benedikt Rötsch 的“讓你的Webpack包瘦身”

包檔案的審計分析通常會突出顯示可重置的“重”依賴項（如 Moment.js 及其語言環境），以便獲得更輕的替代方案（例如date-fns ）。

如果您使用webpack，您可能會發現我們在這個倉庫中提到的公共庫 會很有用。

測量，優化，監控和重複。

如果你不確定你的JavaScript 整體上是否有任何效能問題，請檢視Lighthouse ：

Lighthouse 最近添加了許多新的、您可能不瞭解的但是又有用的效能審計分析

Lighthouse 是內嵌在 Chrome 開發者工具中的一款工具。它也可以作為Chrome 擴充套件程式 使用。它為你提供了深入的效能分析，並提供一些潛在可以提高效能的建議。

我們最近為Lighthouse添加了標記 “JavaScript boot-up time（JavaScript 啟動時間）”的功能。這個分析突出顯示那些可能需要花費很長時間進行解析/編譯的指令碼，這會延遲可互動的時間。您可以據此拆分或優化你的程式碼。

你可以做的另外一件事是確保你沒有把無用的程式碼傳送給使用者。

使用Chrome DevTools中的Coverage選項卡 查詢未使用的CSS和JS程式碼。

Code coverage(程式碼覆蓋率) 是DevTools中的一項功能，它允許您在頁面中發現未使用的JavaScript（和CSS）。 在DevTools中載入頁面，coverage選項卡將顯示被執行的程式碼數量與載入的數量。 您只需提供使用者需要的程式碼即可提高頁面效能。

提示：通過覆蓋記錄，您可以與您的應用進行互動，DevTools將更新您使用的包的數量。

這對於找出可以進行拆分的指令碼以及延遲載入非關鍵指令碼來說非常有用。

如果你正在尋找一種為使用者提供高效的 JavaScript 分發模式，請檢視PRPL模式 。

PRPL（Push、Render、Precache和Lazy-Load）是一種模式，用於對每個路由進行程式碼拆分，然後利用Service Worker 預先快取未來路由需要用到的JavaScript和邏輯，並按需延遲載入。

這意味著當用戶導航到體驗中的其他檢視時，它很可能已經存在於瀏覽器快取中，因此他們在啟動指令碼和獲取互動方面的成本降低了很多。

如果你關注效能，或者您曾經為您的網站做過效能補丁，那麼你會發現有時候你修復可某個問題，但是過了幾周後又出現了，發現團隊中有人正在開發某個功能，無意中破壞了這個修復。就想這樣：

幸運的是，我們有很多方法可以處理這個問題，其中一個方法就是制定效能預算 。

效能預算是至關重要的，因為它們使每個人保持一致。它們創造了一種共享熱情的文化，以不斷改善使用者體驗和團隊責任。

預算定義了可衡量的約束，讓團隊去實現效能目標。因為你不能突破預算的限制，所以每走一步都要考慮好效能，而不是事後再來解決。

根據Tim Kadlec 的經驗，效能預算的指標可包括：

• 里程碑時間 – 基於載入頁面的使用者體驗的時間（例如，可互動時間（ Time to Interactive ））。您常常希望對幾個里程碑時間進行配對，以便在頁面載入期間準確地表現完整內容。
• 基於質量的指標 – 基於原始值（例如JavaScript的權重，HTTP請求的數量）。 這些都專注於瀏覽器體驗。
• 基於規則的指標 – 來自於一些評測工具的評分，如 Lighthouse 或 WebPageTest 。通常通過一個或者一系列分數來對你的網站評級。
  
  Alex Russell 釋出了關於效能預算的推特 ，其中有幾點值得注意：
• “領導階層的支援很重要。為保證良好的整體使用者體驗而暫停或擱置功能性的開發的意願來自管理者對技術產品的縝密思考。“
• “效能是由工具支援的文化。儘可能的讓瀏覽器優化HTML+CSS。將更多的工作轉移到JS會給您的團隊及其工具帶來負擔。“
• “效能預算不會讓你傷心。他們的存在是為了讓組織自我糾正。團隊需要效能預算來限制決策空間並幫助實現它們。“

每個參與人和其執行力都會關係到網站的使用者體驗。

效能指標通常是文化挑戰，而不是技術挑戰

在計劃會議和其他會議中討論效能。向業務利益相關者詢問他們的效能預期。他們是否瞭解效能如何影響他們關心的業務指標？詢問團隊如何計劃解決效能瓶頸問題。雖然這裡的答案可能不盡如人意，但至少對話開始了。

這是一個性能執行計劃：

• 建立您的效能願景。 這是一份關於業務利益相關者和開發人員認為“良好表現”的協議
• 設定效能預算。 從願景中提取關鍵績效指標（KPI），並從中設定切合實際的可衡量目標。例如“在5s內載入並可進行互動”。這裡可以不考慮JS大小指標。 例如“JS壓縮後保持 < 170KB”
• 建立關於KPI的定期報告。這可以是傳送給業務的定期報告，突出顯示進度和成果。

Andy Still的Web Performance Warrior 和 Lara Hogan的Designing for Performance 都是討論如何考慮如。何實現效能文化的優秀書籍。

那麼效能預算的工具有哪些呢？你可以通過Lighthouse CI 專案建立 Lighthouse 評分預算：

如果您的效能分數低於Lighthouse CI 的某個值，則防止 pull

請求被合併。Lighthouse Thresholds 是另一種基於配置的方法來設定預算。

許多效能監控服務支援設定效能預算和預算警報，包括Calibre ,Treo ,Webdash 和SpeedCurve ：

擁抱效能預算可以鼓勵團隊認真思考他們從設計階段早期到里程碑結束所做出的任何決策將產生怎樣的後果。

尋找進一步的參考？ U.S Digital Service通過設定類似“可互動時間”的目標和預算指標，記錄用 Lighthouse 跟蹤的效能的方法 。

接下來..

每個站點都應該可以訪問實驗和真實場景中效能相關的資料 。

要跟蹤 JavaScript 可能對 RUM（真實使用者監控）設定中的使用者體驗產生的影響，網路上有兩個東西，我建議大家去看看。

第一個是Long Tasks (長時間任務) ——一個API，幫助你收集真實世界中持續時間超過50毫秒並可能會阻塞主執行緒的任務。您可以記錄這些任務並將它們記錄到您的分析中。

第二個是First Input Delay(首次輸入延遲) (FID) ，是用於度量從使用者首次向網站發起互動（如當他們點選按鈕時）到瀏覽器能夠響應該互動的時間。FID是一個實驗性指標，不過現在已經有一個可用的polyfill ，你可以嘗試下。

在這兩者之間，您應該能夠從真實使用者那裡獲得足夠的遙測資料，以檢視他們遇到的JavaScript效能問題。

眾所周知，第三方 JavaScript 可能會對頁面載入效能產生嚴重影響。雖然這個觀點沒錯，但是是要認識到自己寫 JavaScript 對效能的影響也非常重要。如果我們要加快載入速度，需要同時消除雙方對使用者體驗產生的影響。

我們看到了幾個常見的漏洞，包括在文件頭部使用JavaScript來決定向使用者顯示那個版本的A/B測試。或者將A/B測試所有的JS都發送給使用者，但實際上只用了其中一個。

如果這是你目前遇到的主要瓶頸，我們還提供了一個有關載入第三方JavaScript的指南

。

總結

效能優化是一段長途旅行。許多小的變化可以帶來巨大的收益。

使使用者能夠以最少的阻力與您的站點進行互動。 執行最少量的JavaScript以提供真正的價值。 這可能意味著你需要採取漸進的步驟來實現目標。

最後，您的使用者會感謝您。

譯自The Cost Of JavaScript In 2018