[譯]通過 Lighthouse 瞭解 JavaScript 效能
不確定JavaScript 的開銷對於您那的使用者體驗來講是不是太高了？ Lighthouse 有 ofollow,noindex">JavaScript 執行時間審計 ，用來衡量 JavaScript 對於頁面載入效能的影響。
讓我們一起試試吧？現在它已經在 Chrome DevToolsAudits面板裡邊了。同樣可以通過訪問WebPageTest 來使用。
對於上面的內容站點，移動裝置上的瀏覽器需要 51s（哎呀，太慢了）才能處理完主包。算上網路傳輸時間，使用者可能需要等待一分鐘才能和這個頁面進行互動 :hourglass_flowing_sand::sleepy:
這是花在中等配置的移動裝置上的解析、編譯和執行指令碼的時間。dev.to（提供類似的內容體驗）能夠在對指令碼依賴最小的情況下載入他們的主包:heart:
我們怎樣才能優化原始網站 JS 的效能呢？
只有當用戶真正需要前，才傳輸 JavaScript。我們可以使用像程式碼分割的技術來實現對剩餘部分的懶載入。我使用 DevTools 的Code Coverage 功能提供幫助。
如果我開始記錄並載入上述網站，然後互動一段時間，我們可以看到可能不需要預載入大約 57% 的程式碼。對於可以按需載入的資源來說，這是很好的備選方案。
如果你之前沒有仔細看過 Lighthouse，那麼他會有很多有用的小模組，比如檢查你是否正確精簡或者壓縮指令碼；
如果你使用無頭瀏覽器進行自動化操作，那麼Puppeteer 還有一個很有用的 code-coverage example 示例，可以在頁面載入的時候視覺化 JS 程式碼覆蓋率的使用情況。
總結.. :gift:
JavaScript 會對您的使用者體驗產生巨大的影響; Lighthouse 可以在這裡有效的改善。為了保持較低的 JavaScript 傳輸和處理時間：
- 只發送你使用者需要的程式碼
- 精簡壓縮指令碼
- 移除未使用的程式碼和依賴
如果發現譯文存在錯誤或其他需要改進的地方，歡迎到 掘金翻譯計劃 對譯文進行修改並 PR，也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。
掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群，文章來源為掘金 上的英文分享文章。內容覆蓋 Android 、 iOS 、 前端 、 後端 、 區塊鏈 、 產品 、 設計 、 人工智慧 等領域，想要檢視更多優質譯文請持續關注 掘金翻譯計劃 、官方微博、 知乎專欄 。