前端性能之JavaScript成本（2018）

關於原文

原文是在Medium上面看到的，Chrome工程師Addy Osmani發佈的一篇文章，這位的Medium上面的自我介紹裏面有一句Passionate about making the web fast，和這篇文章的主體能夠說很是契合了。

最近在作一個服務端渲染的項目，到底頁面性能的提高可以帶來多少的意義，或者到底有多少合理的方法來讓精雕細琢移動端的用戶體驗。

這篇文章主要是部份內容的翻譯，而且結合本身的一些想法，以備在項目架構的時候考慮到這些相關的東西。

原文內容會按照引用樣式排版

原文-The Cost Of JavaScript 2018

這篇文章很乾，幹到一張圖都不存在，因此想讀下去的請作好準備吧~，更推薦直接去讀原文哦！！

前言

首先，JavaScript仍舊是咱們發送到用戶移動設備上的最昂貴的資源，由於它能夠在很大程度上延遲用戶的交互。

JavaScript阻塞頁面上的交互動做，全部同步執行的JavaScript代碼不會中斷本身的執行來給忽然觸發的交互事件讓路，而且若是在交互的時候須要頁面樣式的變化，也是會被阻塞的。React 16中新加入的Fiber功能，就是爲了將同步的re-render操做分片，來讓頁面的交互能夠間歇進行而不是徹底阻塞。關於React Fiber的原理，能夠看這一篇：React 16.0 Fiber源碼解讀。

React在Release Note中也寫到了，React 16還有一大進步就是相比起15.6版原本說，其react庫壓縮到了5.3kb，gzip壓縮後能夠達到2.2kb，而react-dom庫也從141kb壓縮到了103.7kb，庫大小的減小也可以很好地提高React在客戶端的執行速度，在頁面首次渲染的時候加載更少的資源。

• 爲了保證速度，僅僅加載當前頁面必須的JavaScript；
• 提早作好性能預算，而且合理利用；
• 作好JavaScript打包以及代碼審計工做；
• 每個交互都是從一個新的「可交互時間」開始的，考慮如何在這種狀況下進行優化；
• 若是一段客戶端JavaScript並不可以提高用戶體驗，那麼就要問問你本身這段代碼是不是必須的。

原文的文章很長，因此放了一個tl;dr:在文章最前面，文章的五個重點都列出來了，如何壓榨每個Byte的JavaScript的性能，須要從多個方面考慮可精簡的JavaScript。

web因爲用戶「體驗」而膨脹

也許你根本就不知道本身頁面中的JavaScript到底佔據了多少物理資源來執行，尤爲是在移動設備上。目前的現代網頁平均會使用250KB的壓縮JavaScript，若是沒有壓縮的話，大概是1MB左右的腳本，這些腳本都須要瀏覽器來執行，不管是在移動設備仍是PC上面。

在公司網絡的環境下，使用lighthouse來對網易雲音樂的首頁進行檢測，從開始HTTP請求一直到頁面開始能夠交互的時間大概在3s左右，根據5s原則來講，已是一個很好的體驗了，不少元素的延遲加載起到了很好的做用。若是你想看到本身的網頁性能到底如何，可使用lighthouse快速生成一個網頁性能的檢測報告。

移動端用戶體驗隨着JavaScript阻塞交互事件超過14秒以上，逐漸消失。

致使移動端上面代碼阻塞時間的主要緣由是移動端CPU的性能以及網絡情況。

這裏顯示的中國並非4G覆蓋率很是低，而是沒有數據，可是能夠看到西歐、北美等地區的4G覆蓋率也只是60%~80%之間，並不可以達到基本全覆蓋，因此爲了這部分3G用戶的用戶體驗，縮減JavaScript壓縮後文件的大小也是必然的。

而且移動端設備的性能也是瓶頸之一，智能手機的普及率雖然比較高，可是質量良莠不齊，許多移動端設備還停留在1G甚至512RAM的狀況下。

大部分互聯網公司都會採用兩套web來實現移動端和桌面端，移動端採用高壓縮的頁面，來減小網絡時間和加載時間。

JavaScript存在成本

若是頁面有着過多的腳本，那麼就須要考慮code-spliting來分開bundle代碼，或者經過tree-shaking來減小JavaScript的包袱。

目前咱們的業務項目採用React+Node.js的SSR來進行SEO優化和首屏性能提高。咱們的JS Bundle中有着不少的JavaScript庫代碼：

• react&& react-dom等客戶端框架；
• 大型SPA可選的狀態管理解決方案：mobx、vuex、redux、rxjs；
• ES六、ES7等polyfills，爲瀏覽器廠商還債；
• @music等組件庫，包括Utils組件以及UI組件。

即便已經完成了code split，首屏加載中，上面的這些庫也會有一大部分被加載進來，形成整個項目的JavaScript冗餘。

整個頁面在加載的時候，有着幾個重要的時間節點。

是否開始有內容顯示在頁面上了。也就是用戶可以感覺到本身獲得了響應；

是否有完整的內容顯示在頁面上，也就是可交互的內容已經顯示了出來；

是否能夠開始進行交互了，也就是意味着用戶可以開始對頁面進行正常操做。

前兩個階段在服務端渲染的狀況下，大部分進行的仍是頁面的render操做，render是沒有太多辦法來對其進行加速的。因此爲了提高交互效果，第三階段是必須着力解決的。不可以產生交互的主要緣由是腳本尚未加載完成，致使了頁面阻塞。加速加載和執行，經過減小JavaScript包的大小是可行的方法。

另一種方法是經過SSR，爲用戶提供更快的首屏渲染速度，而且在以後，將JavaScript注入到頁面當中。

經過<script>標籤等主進程加載過多的JavaScript會形成阻塞問題，而採用Web Worker進程或者緩存來進行頁面腳本的執行可以獲得更短的阻塞時間。

咱們估測了Google News的移動端可交互時間，在高端設備上大約是7秒左右，而低端設備則達到了55秒。

中低端設備的JavaScript運行速度遠遠比我預期的要長不少，因爲生活和工做環境中較少接觸這類設備，因此這類用戶設備的比例是須要進行埋點獲取的，若是這類設備的比例較高（在國內是比較有可能發生的），那麼就須要爲這類用戶進行JavaScript的削減或者壓縮。

Pinterest將打包後的JavaScript從2.5MB壓縮到了小於200KB，響應時間從23秒下降到了5.6秒，這樣帶來的直接結果就是，他們的收入提高了44%而註冊量提高了753%Orz，移動端的周活提高了103%。

咱們須要作的重點是防止JavaScript成爲整個網站的瓶頸。

須要記住的是，若是想要讓JavaScript變得更快，那麼須要作到下面幾點：

• 下載快
• 解析快
• 編譯快
• 執行快

Parse/Compile

上面是各大網站在V8引擎上面的腳本執行時間圖，解析和編譯階段佔了總時間的大約10%~30%，在Chrome 66中，V8能夠在後臺線程編譯代碼，能夠將編譯時間減低到大約20%左右，可是也不多見到可以在50ms以內編譯完的JavaScript代碼。

另外一個要注意的事情就是，JavaScript的大小並不徹底意味着它的時間消耗，一個200KB的圖片和一個200KB的JavaScript所佔用的時間是徹底不一樣的。

二者的下載時間應該是差很少而且和大小強相關的，可是圖片須要解碼，柵格化以及繪製到屏幕上，而JavaScript代碼包須要解析，編譯以及執行。JavaScript的時間消耗基本是要大於圖片的，這個差距也取決於設備的CPU性能。

根據上述內容，**在進行性能測試的時候，儘可能讓環境惡劣起來，不要使用高速的網絡環境以及高性能設備來進行測試。**由於用戶設備和環境的均值多是你想象不到的。

可變性會殺死用戶體驗，高性能設備可能會變慢，高速網絡也可能會變慢，可變性最終會讓全部事情都變慢。

可變性須要讓開發人員下降開發時的基準線，來保證每個用戶的體驗。若是你的團隊可以經過一些策略來獲知全部訪問你的站點的用戶環境，那麼能夠很方便地對於站點的性能兼容性進行測試。在測試的時候，採用用戶中具備表明性的網絡和設備環境來進行測試。

It's important to know your audience.

• 對於網絡，低端網絡環境須要更小的JavaScript bundle。這就要求減小代碼的冗餘、縮小代碼體積、而且進行壓縮；
• 對於設備，作好對於重複訪問數據的緩存工做，解析時間對於低端設備來講是最重要的。

當咱們的站點愈來愈依賴於JavaScript的時候，咱們有時候就會爲了避免容易看見的發送到客戶端的代碼付出代價。

如何發送更少的JavaScript

這一點的關鍵在於如何發送最少限度的JavaScript到客戶端，而且可以保證用戶的正常體驗。Code-splitting是其中的重點。

目前來講，Code-splitting經常使用的方法就是在bundle代碼的時候，僅僅返回當前路由對應的相關代碼，而不返回整個龐大的代碼包。對於路由的切分以及庫的引入來講，這一個原則相當重要。不管什麼理由，都儘可能不要將其餘路由的代碼注入到當前訪問的路由當中。路由的懶加載是decrease你的JavaScript加載速度的重點。

import Loadable from 'react-loadable';
const LoadableOtherComponent = Loadable({
    loader: () => import('./OtherComponent'),
    loading: () => <div>Loading...</div>
});
const MyComponent = () => {
    <LoadableOtherComponent />
};
複製代碼

在React中添加code-splitting能夠經過React Loadable進行，這個庫是一個HOC，能夠動態加載須要的React組件，而不會在首次渲染的時候就將全部的頁面組件都加載進來，即便它暫時不會被使用。

如今也有不少庫能夠幫助你來定位本身的代碼包，來幫助你從代碼層面減小JavaScript代碼的長度。好比webpack bundle analyzer，source map explorer，bundle buddy。這些工具會審視你的代碼，而且找到其中的冗餘，大型庫以及一些未使用的依賴。

打包審查能夠着重於一些大型依賴，或者是給你一個較輕的低位替代。

措施，優化，監控以及重複

若是你不肯定本身的工程代碼是否存在這些問題，經過LightHouse能夠審查你的站點。

cnpm install -g lighthouse
lighthouse http://yoursites.com
複製代碼

快速生成一份站點的性能審查報告。

雲音樂主站的審查報告大概是這樣的，咱們的移動端主站大概須要3秒左右的時間可以獲得交互響應。

因爲這篇文章是從個人桌面上淘出來的，因此圖彷佛都掛掉了。。有興趣的能夠本身去跑一下雲音樂主站的代碼哦！

Code Coverage是一個用來發現你的頁面中的未使用JavaScript以及CSS的DevTools。使用這個工具能夠看到頁面中有多少代碼影響了加載性能，而且這些代碼讓你付出多少時間的代價。

這是主站測試環境下的代碼覆蓋率，能夠發現libs文件基本上有一半都未在使用。而CSS更加誇張，95%的代碼都沒有使用過。

PRPL原則

PRPL(Push、Render、Precache、Lazy-Load)模式適用於盡力將每個單獨路由的代碼拆開，而後利用service worker來pre-cacheJavaScript代碼，這些懶加載的代碼是與當前路由強相關的路由的邏輯代碼。

也就是說，咱們在進行路由加載的時候，僅僅加載一個純淨的路由頁面。當這個路由頁面渲染完畢以後，咱們經過一個路由相關的list來將其餘與當前路由有跳轉規則的路由頁面加載進來，經過service worker來在後臺線程進行懶加載與解析。而且根據咱們當前的環境，來進行優雅降級，若是設備不支持後臺線程，那麼就採用主線程來進行加載。

性能預算

性能預算是保證全部開發人員在一個頻道的關鍵，性能預算定義了一個常量，來讓團隊有着共同的性能目標。

性能預算通常包括下面幾個部分：

• Milestone timings（里程碑時間？）：這個時間通常基於加載頁面時候的用戶體驗，好比能夠開始交互的時候。這個時間通常是頁面完成加載的精確時間。
• Quality-based metrics：基於純粹的值，好比JavaScript的大小，HTTP請求的數量，這個值主要關注瀏覽器體驗。
• Rule-based metrics：經過LightHouse或者其餘頁面測試工具獲得的評分。

因爲如今的大型項目總都是由多個開發人員一塊兒進行開發的，這些開發人員對於頁面的性能並無一個統一的標準，經過上面三個標準，每一個人在加入了本身的代碼以後就能夠對於性能進行測試，來確認本身是否影響到了整個項目的性能預算。好比本身的庫致使了團隊的JavaScript代碼超量。這時，團隊的人就須要根據狀況來削減本身的代碼量。

下面的有點可怕，就放原文了：

Here’s an action plan for performance:

Create your performance vision. This is a one-page agreement on what business stakeholders and developers consider 「good performance」

Set your performance budgets. Extract key performance indicators (KPIs) from the vision and set realistic, measurable targets from them. e.g. 「Load and get interactive in 5s」. Size budgets can fall out of this. e.g 「Keep JS < 170KB minified/compressed」

Create regular reports on KPIs. This can be a regular report sent out to the business highlighting progress and success.

在GIT合併的時候設置LightHouse的檢測規則，若是致使了LightHouse評分下降，則blocked該次合併。在對於性能極致要求的業務狀況下，這個方法的確可以有效地提高業務代碼的質量。

Get fast, Keep fast

性能不是一蹴而就的，許多細小的變更均可能會帶來大的收益。