資訊專欄INFORMATION COLUMN
摘要：目前我們的業務項目采用的來進行優化和首屏性能提升。可變性需要讓開發人員降低開發時的基準線，來保證每一個用戶的體驗。對于路由的切分以及庫的引入來說，這一個原則至關重要。快速生成一份站點的性能審查報告。
The Cost Of 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；
ES6、ES7等polyfills，為瀏覽器廠商還債；
@music等組件庫，包括Utils組件以及UI組件。
即使已經完成了code split，首屏加載中，上面的這些庫也會有一大部分被加載進來，造成整個項目的JavaScript冗余。
整個頁面在加載的時候，有著幾個重要的時間節點。
是否開始有內容顯示在頁面上了。也就是用戶能夠感受到自己得到了響應；是否有完整的內容顯示在頁面上，也就是可交互的內容已經顯示了出來；
是否可以開始進行交互了，也就是意味著用戶能夠開始對頁面進行正常操作。
前兩個階段在服務端渲染的情況下，大部分進行的還是頁面的render操作，render是沒有太多辦法來對其進行加速的。所以為了提升交互效果，第三階段是必須著力解決的。不能夠產生交互的主要原因是腳本還沒有加載完成，導致了頁面阻塞。加速加載和執行，通過減少JavaScript包的大小是可行的方法。
另外一種方法是通過SSR，為用戶提供更快的首屏渲染速度，并且在之后，將JavaScript注入到頁面當中。
通過
上面是各大網站在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: () => Loading...
});
const MyComponent = () => {
在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該次合并。在對于性能極致要求的業務情況下，這個方法的確能夠有效地提升業務代碼的質量。
性能不是一蹴而就的，許多細小的變動都可能會帶來大的收益。
文章版權歸作者所有，未經允許請勿轉載,若此文章存在違規行為，您可以聯系管理員刪除。
轉載請注明本文地址：http://specialneedsforspecialkids.com/yun/108493.html
摘要：舉例來說即便某個失敗了，也不會導致的發生，這樣在不在乎是否有項目失敗，只要拿到都結束的信號的場景很有用。對于則稍有不同只要有子項，就會完成，哪怕第一個了，而第二個了，也會，而對于，這種場景會直接。 1. 引言 本周精讀的內容是：Google I/O 19。 2019 年 Google I/O 介紹了一些激動人心的 JS 新特性，這些特性有些已經被主流瀏覽器實現，并支持 polyfill...
摘要：雖然正則中可以匹配任何字符，但卻無法匹配換行符。精讀文中列舉的四個新特性是加入到正則中的。討論地址是精讀正則如果你想參與討論，請點擊這里，每周都有新的主題，周末或周一發布。 1. 引言 本周精讀的文章是 regexp-features-regular-expressions。 這篇文章介紹了 ES2018 正則支持的幾個重要特性： Lookbehind assertions - 后行...
摘要：下面我們從前端基礎和底層原理開始講起。對于和這三個對應于矢量圖位圖和圖的渲染來說，給前端開發帶來了重武器，很多小游戲也因此蓬勃發展。這篇文章受眾之大，后來被人重新整理并發布為，其中還包括中文版。 showImg(https://segmentfault.com/img/bVbjM5r?w=1142&h=640); 想閱讀更多優質文章請猛戳GitHub博客,一年百來篇優質文章等著你！ 這...
摘要：高級開發人員可能會仔細分析他們的捆綁包，以幫助確定減少不必要依賴。在運行過程中，長時間運行的可以阻塞主線程導致頁面沒有響應。然后當最終被取出時，附加事件請注意這有內在的花銷。發送一個最小功能的頁面包含實行當前功能的。保持低這些問題。 原文 當我們構建的網頁大量依賴于Javascript，我們有些時候需要研究那些不太容易看得見的消耗。在這篇文章中,我將介紹為什么一點規則可以幫助如果你想讓...
閱讀 3769·2021-09-02 09:53
閱讀 2749·2021-07-30 14:57
閱讀 3492·2019-08-30 13:09
閱讀 1179·2019-08-29 13:25
閱讀 810·2019-08-29 12:28
閱讀 1453·2019-08-29 12:26
閱讀 1129·2019-08-28 17:58
閱讀 3305·2019-08-26 13:28
