[譯]the cost of javascript in 2018(1)

前言

爲了構建交互性網站，咱們須要發送js給咱們的用戶，但不少狀況下，咱們使用了太多js。
在移動端，常常看到只加載了個點擊連接或者滾動不了的狀況。

實話說，js仍然是移動端最昂貴的資源，由於其在很大程度上會延遲交互(即交互要在js資源生效以後纔可進行)。下圖展示了不一樣手機處理js的耗時，高端機和低端機的差異是至關的大，而用戶的機型不可控，因此必需要去優化咱們的加載策略。

今天咱們將展現給你們一些高效加載js的策略，以便提高用戶的體驗。

1、tl;dr:

1. 爲保持快速響應，只加載當前頁面相關的js

   優先考慮用戶所須要的，能夠經過code-spliting懶加載剩餘的資源，這樣能夠在加載和執 行上給咱們很大的提高，默認狀況下基於路由的code-spliting是最佳實踐(game-changers)

2. 擁抱性能預期並學會與之相處
   移動端而言，壓縮以後的代碼小於170k。未壓縮的仍然有0.7m。預期對成功是重要的。可是優化也不是隻着重於侷限於代碼上的優化，團隊風格、代碼結構和執行，都是很重要的。沒有預期目標的開發會帶來性能變差和失敗的風險

3. 學習如何審視和優化咱們的js bundles文件
   咱們極可能加載了所有的庫，儘管只使用了一小部分，並不須要其對於瀏覽器的polyfill和重複代碼

4. 每次交互都會開始新一次的Time-to-Interactive，基於此環境進行優化
   傳輸文體體積對於低端網絡設備和計算密集型設備而言是相當重要的

5. 若是客戶端的代碼對用戶體驗無益，從新審視是否必須
   可能服務端渲染確實更加快速，但更須要爲具體頁面使用的客戶端框架斟酌一番，若是沒有詳細考慮，那麼將是一場災難。

   2、網絡因用戶體驗而臃腫

當用戶訪問咱們的網站時，咱們可能發送了太多的文件，很大一部分是js腳本。從瀏覽器的視角來看，就像下面這張圖同樣。

儘管我十分喜歡js，但其始終是咱們網站中最昂貴的一部分，下面將會闡述爲何我這樣認爲。

當今的網頁接收的壓縮以後的js的資源大小平均爲350kb，解壓以後須要瀏覽器處理的大小超過1m。

注意：不肯定你的js bundle包是否影響了網站與用戶的交互，用Lighthouse試試看

處理這麼多的js腳本，知道移動設備具有可交互性，大概要超過14s的時間。

主要影響因素在於，移動設備上加載資源和cpu執行代碼的時間，固然越短越好。

那麼看下當前的網絡狀態：

上面的圖表展現了，全球來看不一樣地圖的4g可用程度和網絡的平均速度。能夠看到大部分的國家和地區，移動網絡是比咱們想象中要差的(圖上來看，我國真的是至關落後)。

對於中間網頁來講並不只僅是在350k的js須要下載以外，當下主流網站會下載更多的js腳本。

不論是桌面仍是移動端，咱們都要達到天花板了。有些網站會發送上兆的代碼給瀏覽器執行。那麼問題來了，咱們是否能承受如此多的js代碼

3、js的開銷

注意，若是加載太多的js，考慮code-splitting來拆分包，或者使用tree-shaking來減少js文件的paypload(reducing JS payloads using tree-shaking)

網站的腳本通常包括如下幾類：

• 客戶端的框架或者ui庫
• 一個狀態管理工具（例如 redux）
• Polyfills（對於現代瀏覽器來講並不須要）
• 完整的庫或者按需加載的部分(例如完整的lodash, Moment + locales)
• 一套ui組件（例如buttons headers）

加載頁面的過程像電影帶同樣分爲三個重要階段： Is it happening(是否發生)， Is it useful(是否有用)，is it usable(是否可用)。我的理解這裏的後二者的差異，在於有用即有意義信息是否展現，可用只是否可交互。具體以下圖所示：

根據上面的圖示，更容易理解
Is it happening （是否發生）
當前時間點，是否有響應或者提示信息顯示在頁面上（導航是否開始，服務端是否響應）

Is it useful(是否有用)
此時，應該已經顯示了文本或者內容，該過程用戶能夠獲取信息

is it usable(是否可用)
此時，用戶應該能夠進行正常的交互操做，即爲可用。

在前面就提到了可交互性(interactive),到底什麼是可交互性呢(原做者的圖真的十分形象，一眼就看到問題所在)：

對一個頁面而言，可交互性指的是快速對用戶的輸入作出相應，一個小體積的腳本payload可讓這個階段快速出現。

不管是點擊連接仍是滾動屏幕，若是用戶得不到相應的真是反饋，那麼用戶會抓狂的。

這種狀況常常發生在服務端渲染的時候，咱們會發送過多的js來重寫以實現額外的功能(例如事件處理等)
當瀏覽器運行不少咱們須要的事件時，極大可能會在主線程裏來實現，但是用戶的輸入操做也在主線程中響應。
將load過多的js放在主線程中進行(例如經過script標籤)正是一個問題。因此將js放入webworker或者在service worker中將會避免這種影響。(譯者注，即將耗時工做從主線程中分離)。

儘量的避免阻塞主線程，更多能夠查看Why web developers need to care about interactivity

當下，咱們正看到兄弟團隊在不一樣類型網站上飽受過多js阻塞交互之苦。

下面是一些谷歌搜索的例子：你能夠開始點擊ui，但若是頁面加載太多js，在真實響應以前，可能會有一些延遲。固然都但願頁面可以儘快可交互。

經過觀察谷歌新聞在不一樣機器上的可交互時間，發現不一樣設備之間的巨大差別，高端機在7s之內，而低端設備須要55s，那麼問題來了，具體的優化的目標應該定在哪裏呢？

具體而言，做者認爲基準應該是中等設備在慢3g網絡下5s內可交互。若是說你的用戶都在wifi下，那樣也不現實，適應性是重要的。

下面能夠看下經過減小js加載下降Time-to-Interactive的例子：

• Pinterest 將 JavaScript bundle 從 2.5MB 下降到小於 200KB，而 Time-to-Interactive 時間則從23秒降到5.6s. 收入增加44％，註冊增加753％，移動互聯網周活躍用戶增加103％。
• AutoTrader 將 JavaScript bundle 大小下降了 56% 並將達到 Time-to-Interactive 的時長縮短了一半。
• Nikkei 將 JavaScript bundle 大小下降了 43% 並將 Time-to-Interactive 耗時縮短了13秒。
  Let’s design for a more resilient mobile web that doesn’t rely as heavily on large JavaScript payloads.
  咱們須要設計一個不依賴於大量js文件的高適應性網站

可交互性影響不少事情，一樣也被不少因素影響，例如移動數據加載、WiFi或者旅途中間歇性鏈接。這些狀況下，你依然有不少js去解析。那麼用戶可能不會等待。

因此咱們須要去優化，在優化以前咱們須要瞭解下，爲何js如此的昂貴。可是原文畢竟太長，暫且放鬆一下告一段落，太長的文章你們也不會有耐心讀完，後事聽下回。

結束語

原文

The Cost of JavaScript In 2018

不少時候咱們都是爲了優化而優化，看到業界認同的優化策略就拿來用，可能少了那麼一點思考。爲何，如何用，是否適合本身，正好看到這篇詳細的文章，可能做者有點囉嗦，事無鉅細的在強調過多js的表現對網站的影響(私覺得，不必定正確)，或者說前面的鋪墊太長過久，策略比較靠後。不過我認爲這樣講清前因後果的文章會更好一點，好文共享吧。