[译]通过 Lighthouse 了解 JavaScript 性能

不确定JavaScript 的开销对于您那的用户体验来讲是不是太高了？ Lighthouse 有 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 、 前端 、 后端 、 区块链 、 产品 、 设计 、 人工智能 等领域，想要查看更多优质译文请持续关注 掘金翻译计划 、官方微博、 知乎专栏 。