漫谈JavaScript开销

本文来自于 Google Chrome 的一位工程师，致力于研究WEB响应速度。即便是手机性能得到了大幅提升的2018年，JavaScript 的成本消耗在移动端依然不可小觑，那么JavaScript都为我们的用户带来了哪些消耗？又有哪些优化方法？

文中包含 YouTube视频，Twitter, 请科学上网。

构建交互式网站涉及到向用户发送JavaScript，大部分站点，JS脚本非常多。你是否在一个看起来加载好的移动页面上尝试点击或滚动页面时却没有任何响应？

在移动端，JS文件依然是最至关重要的资源，因为它可以极大的延迟用户与我们页面的交互。

今天我们将介绍一些提高JavaScript效率(性能)的策略，为用户提供良好的体验。

概括

• 为了快速加载，只加载当前页面需要的JavaScript

  优先加载用户需要的内容，并且通过 code-splitting 延迟加载其他的内容。这是处理文件加载和用户交互（之间的平衡）的最佳方法。基于路由堆栈的代码分割是 游戏改变者 。

• 学会性能预估，开发中时刻关注性能

  在移动端，一个压缩后的JS文件应该在170KB以内。这部分代码（170KB）未压缩的情况下有.7MB。（性能）预估对一个成功的网站至关重要，然而，不能指望它神奇的孤立的修复所有性能问题。 团队文化，团队文化，以及团队执行力 ，这些同样重要。一个没有（性能）预估的网站构建会导致性能倒退和失败。

• 学会如何审查并精简你的JavaScript代码包

  大部分情况下，你只需要库的小部分功能但是你却引入了整个库，其中包含着大部分浏览器的polyfills或者重复代码。

• 每次交流都是下一次交流的开始；在交流中寻找最佳优化

  传输（文件的）大小对于低端移动网络至关重要，而设备的CPU 对于 JavaScript 解析时间至关重要。

• 如果客户端渲染没有提升用户体验，你需要反思一下否真的有必要这么做。

  也许服务器端渲染的 HTML 会更快。考虑只在绝对需要客户端渲染的页面上才使用客户端框架。如果做得不好，服务器渲染和客户端渲染都会成为一场灾难。

WEB 因用户“体验”而膨胀

当用户访问您的站点时，您可能会发送大量文件，其中许多是脚本。 从Web浏览器的角度来看，这看起来有点像这样：

虽然我非常喜欢JavaScript，但它始终是您网站中开销最大的部分。我想解释一下这个主要问题。

目前一个中等WEB网站需要传输 350KB 左右的压缩JavaScript。浏览器需要处理这部分代码解压后大小超过了1MB。

注意：如果你不确定你的 JavaScript 包是否会延迟用户与你网站的可交互速度？可以通过 Lighthouse

来自 HTTP存档状态的JavaScript报告的统计数据 ，2018年7月 ,突出显示中间网页传输压缩后的 JavaScript 资源约为 350KB。这些页面最多需要15秒才具备可交互性

根据经验，在移动设备上这么多JavaScript下载完成到用户可交互需要超过14S的时间。

其中一个重要因素是在移动网络上下载代码和在移动设备的CPU上解析需要多长时间。

看看全球的移动网络状态。

在特定指标中表现更好的国家的颜色更深。未包括的国家是灰色的。同样 值得注意 的是，即使在美国，农村宽带速度也比城市地区慢20％。

OpenSignal的这张图表 显示了4G网络在全球范围内的可靠性以及每个国家/地区的平均连接速度用户体验。 我们可以看到，许多国家的连接速度仍然比我们想象的要低。

不仅仅像之前我们说的一个中等网站需要一定时间来来下载350KB的脚本，事实上我们访问一个流行网站时，他们下载的脚本远比这多得多：

压缩的JS包大小数据来自 “Bringing Facebook.com and the web up to speed” 像Google表格这样的网站会突出显示为传输最多5.8MB的脚本（解压缩时）。

这些网站需要浏览器下载和解析的代码达到了数兆（MB）字节，桌面和移动页面上都达到了这个上限。想问的是， 你能接受这么的JavaScript吗？

JavaScript有成本

注意：如果您下载的脚本太多，请考虑使用 代码分割 来分解包或 使用tree-shaking减少JS有效负载 。

当今的网站通常会在他们的JS包中包含以下内容：

• 客户端的框架或者 UI 库；
• 状态管理解决方案（例如 Redux）；
• Polyfills（通常被用于不需要它们的现代浏览器）；
• 完整的库 VS. 仅需要的内容（例如，所有lodash，Moment +语言环境）
• 一套 UI 组件（按钮，标题，侧边栏等）

这段代码使用的越多，页面加载所需的时间就越长。

加载一个网页就像一个有三个关键时刻的电影故事。

分别是：加载是否被触发？加载的内容是否是有用？以及加载的内容是否可用？

加载是否被触发是你能够将一些内容传输到屏幕的那一刻。 （页面是否开始跳转？服务端是否开始响应？）

加载的内容是否是有用是您绘制文本或内容的时刻，允许用户从中获取有价值的信息并与之交互。

然后，加载的内容是否可用是当用户可以开始与网页进行有意义地交互并发生某些事情。

我之前提到了一个术语 “交互”，但他到底意味着什么呢？

一个可交互页面，他必须尽可能快的响应用户的输入。一个小的JavaScript可以确保网站的响应快速发生。

无论用户点击了一个链接还是滚动页面，他们都需要看到有实际的事情响应了他们的操作。如果无法得到相关的体验会使用户感到沮丧:person_frowning:。

这种情况经常发生在服务器端端渲的页面，然后随后发送一堆 JavaScript 来“润滑”界面（附加事件处理程序和额外行为）

当浏览器运行许多可能需要的事件时，它可能会在处理用户输入的同一线程上进行。这个线程被称为主线程。

将过多的JavaScript加载到主线程（通过 <script> 等）是个问题。将JS通过 Web Worker 或 Service Worker 进行缓存不会产生相同的负面等待交互（Time-to-Interactive）影响。

这是一个用户可以点击某些UI的示例。 通常，他们可能会选中一个复选框或点击一个链接，一切都会正常工作。 但是如果我们模拟阻塞主线程，那么任何事情都无法发生。 他们无法检查该复选框或单击链接，因为主线程被阻止。

避免尽可能地阻塞主线程。有关更多信息，请参阅 “为什么Web开发人员需要关注交互性” 。

我们看到了我们的合作团队在许多类型的网站上都碰到 JavaScript 影响交互性的情况。

太多（主线程）JavaScript可以延迟可见元素的交互性。 这对许多公司来说都是一个挑战。

以上是Google搜索中的一些示例，您可以从一开始使就使用这些UI，但如果某个网站运行过多的JavaScript，则可能会在实际发生某些事情之前出现延迟。 这会让用户感到有点沮丧。 理想情况下，我们希望所有交互尽快响应。

通过测试Google新闻在移动设备上的可交互时间，我们观察到高端设备大约7秒内实现交互，而低端设备需要55秒，差异巨大。那么， 交互性的最佳目标（时间）是多少呢 ？

谈到 Time to Interactive ，我们认为您的基准应该是在中等移动设备上的慢速3G连接可以在五秒左右就能进行交互。 “但是，我的用户都在使用快速网络和高端手机！”……是吗？ 你可能会使用“快速”的咖啡店WiFi，但实际上只能获得2G或3G的速度。意外不惊喜不。

谁减少了 JavaScript 并减少了他们的可交互时间？

• Pinterest 将他们的 JavaScript 包从 2.5MB 降低到小于 200KB，而可交互时间从23秒降到5.6s 。收入增长44％，注册增长753％， 移动互联网周活跃用户 增长103％

• AutoTrader 将 JavaScript bundle 大小降低了 56% 并将达到 Time-to-Interactive 的时长缩短了约50％ 。

• Nikkei 将 JavaScript 包大小降低了 43% 并将可交互耗时缩短了14秒 。

让我们设计一个更具通用性的移动网站，不依赖于大型JavaScript。

交互会受到很多事情影响。它可能受影响于加载您的网站在移动数据计划，或咖啡店WiFi，或只是他们旅途中的间歇性网络连接。

当这种情况发生时，而你的网站有很多JavaScript 需要处理，用户会结束等待页面呈现内容。或者，页面呈现某些东西，在他们能进行任何交互前需要等待很长时间。

理想情况下，减少传输JavaScript可以缓解这些问题。

为什么JavaScript 开销如此高昂？

要解释JavaScript为何有如此大的开销，我想向您介绍将内容发送到浏览器的过程中都发生了什么。 用户在浏览器的地址栏中键入URL：

一条请求被发送到服务器，然后服务器返回html。 然后，浏览器会解析该html并提取必要的CSS，JavaScript和图像。 然后，浏览器必须获取并处理所有这些资源。

上面的场景准确描述了Chrome在处理您发送的所有内容时所发生的事情（是的，它是一个巨大的表情符号工厂）。

这里面临的挑战之一是 JavaScript 最终成为瓶颈。理想情况下，我们希望能够快速绘制像素，然后让页面可交互。但如果 JavaScript 是一个瓶颈，你最终只能看到一些你无法与之交互的东西。

我们希望阻止JavaScript成为现代网站体验的瓶颈。

作为一个开发者我们需要时刻记在心中的是，如果我们想要JavaScript变快，我们需要让下载，解析，编译，执行整个过程变得更快。

这意味着我们不仅要保证快速的网络传输，还要保证快速的脚本处理能力。

如果您花费很长时间在JavaScript引擎中解析和编译脚本，那就会延迟用户与您网站的交互时间。

为了提供一些关于此的数据，这个是 V8 （Chrome 的 JavaScript 引擎）在处理包含脚本的页面时花费时间的细分统计图：

橙色代表了主流网站解析JS文件所需要的时间。黄色是编译的时间。两者加起来，页面需要花费高达30%的时间来处理JavaScript -这些开销是真实存在的。

从Chrome 66开始，V8在 后台线程上编译代码 ，将编译时间缩短了20％。 但是解析和编译仍然非常昂贵，并且很少看到大型脚本能在50ms内执行完成，即使是在线程外编译也是如此。

关于JavaScript另一个需要注意的是每一字节都是不相等的。一个200KB的脚本和一个200KB的图像所造成的开销是完全不一样的。

它们可能需要相同的时间来下载，但是在处理时开销并不相同。

一个JPEG图片要显示在屏幕上需要经过解码，栅格化和绘制。一个JavaScript包需要下载然后解析，编译，执行-并且引擎需要完成许多 其他步骤 。请注意，这些成本并不完全相同。

人们开始重视 JavaScript 开销问题的一个重要的原因是移动端。

移动设备就是一个频谱

如果我们足够幸运，可能会拥有一部高端或中端手机。 现实情况是并非所有用户都拥有这些设备。

他们可能使用低端或中端的手机，这些设备之间的差异也可能非常明显；散热、高速缓存大小、CPU、GPU – 基于您使用的设备，您最终经历的JavaScript等资源的处理时间可能完全不同。 即便在美国也存在低端手机的用户 。

以下是分析2018年可用硬件解析JavaScript所需时间的细分：

最上面高端设备，如iPhone 8，它可以相对快速地处理脚本。 下面更多的是普通手机，如 Moto G4 和 < $100 的阿尔卡特 1X。 注意处理时间的差异？

随着时间的推移，Android手机越来越便宜，而不是更快 。 这些设备通常CPU较差，具有微小的L2 / L3高速缓存大小。 如果您希望他们都拥有高端硬件，那么普通用户就会流失。

让我们通过来自现实网站的脚本来查看这个问题的更实用版本。 这 CNN.com 的JS处理时间：

在iPhone 8（使用A11芯片）上处理CNN的JavaScript比在普通手机上花费少9秒。 这可以让可交互时间快9秒。

既然WebPageTest支持阿尔卡特1X（在美国销售约100美元的手机，在发布时售罄），我们还可以看看在中低端硬件上加载CNN的过程。 通过对比三类机型的 filmstrips 片段，能看出低端机型甚至都不能简单的用慢来形容了。

这提示我们，不要再理所当然的认为用户都是使用快速网络和高性能设备。

部分用户可能无法使用高速的网络或者拥有最新款的手机，因此我们开始在真实的网络和真实的手机上进行测试变得至关重要。不可确定性确实是一个问题。

“可变性对用户体验的影响是致命的”——Ilya Grigorik。高端设备有时候可能也会变得很慢。高速网络也会变慢，可变性最终会导致所有东西变慢。

当差异可能会破坏用户体验时，使用缓慢的基线进行开发可确保每个人（快速和慢速设置）都能获益。 如果您的团队可以查看用户的分析并准确了解您的用户实际访问您网站的设备，这些将会提示您应该在办公室中使用哪些设备来测试您的网站。

webpagetest.org/easy 在【移动】配置项下预配置了很多 Moto G4。如果您无法购买自己的中端级硬件进行测试，这将非常有用。

这里有很多配置文件，你可以通过这些配置文件使用已经预先配置好的主流设备。例如，我们有一些中端设备像 Moto G4可以用来测试。

在代表性网络上测试同样非常重要。即使我之前说过中低端手机是多么的重要， Brian Holt 说过， 了解每一位用户非常重要 。

并非每个站点都需要在低端手机上的2G上表现良好。也就是说，在整个频谱范围内实现高水平的性能并不是一件坏事。

您可能在频谱的较高端或频谱的不同部分拥有广泛的用户。请依据您网站背后的数据，以便您可以合理地判断这些问题的重要性。

如果您希望JavaScript更快，需要注意低速网络的下载时间。您可以做的改进包括：减少代码，缩小源代码，使用压缩（如 gzip ， Brotli ，和 Zopfli ）。

使用缓存解决用户重复访问。对CPU慢的手机，解析时间至关重要。

如果您是后端或全栈开发人员，您可以很容易获得有关CPU，磁盘和网络的开销。

当我们构建的网站越来越依赖JavaScript时，我们有时会以一种我们不太容易看到的方式为我们发送的内容付出代价。

怎样发送更少的JavaScript

最直接的方式是我们发送最少的脚本给用户，同时仍然给他们一个完整的体验。 代码分割 是一个可行的方案。

代码分割的思想是，它不向用户发送一个单一的庞大的JavaScript文件包——像一个巨大的完整的披萨——如果一次只发送一小个片段会怎样？只要让当前页面的功能可用就可以了。

代码拆分可以在页面级别、路由级别或组件级别完成。很多现代库和框架都通过 Webpack 和 Parcel 等打包工具来实现代码拆分。 React 、 Vue.js 和 Angular 都提供了提供了这方面的指南。

// before.js
import OtherComponent from './OtherComponent';

const MyComponent = () => (
  <OtherComponent/>
);

// after.js
import Loadable from 'react-loadable';

const LoadableOtherComponent = Loadable({
  loader: () => import('./OtherComponent'),
  loading: () => <div>Loading...</div>,
});

const MyComponent = () => (
  <LoadableOtherComponent/>
);

使用 React Loadable 在React应用中添加代码拆分 – 一个高阶的组件，它在React友好的API中包装动态导入，以便在给定组件的应用程序中添加代码拆分。

许多大型团队最近在使用代码分割方面取得了巨大成功。

为了尽可能快的让用户与他们的页面发生交互， Twitter 和 Tinder 在重构他们的移动站点时，最先使用了代码拆分，他们的站点的可交互时间提高的50%。

像 Gatsby.js (React), Preact CLI 和 PWA Starter Kit 这些技术框架尝试强制使用好的默认配置，以便在中端移动硬件上快速加载和获取交互。

许多这些网站还做的另一件事是：将审计分析 JavaScript 作为其工作流程的一部分。

值得庆幸的是，JavaScript生态系统有许多很棒的工具可以帮助进行代码包分析。

使用 Webpack Bundle Analyzer 、 Source Map Explorer 和 Bundle Buddy 这些工具来分析代码包，寻找进行代码拆分的点。

这些工具可视化JavaScript包的内容：它们突出显示您可能不需要的大型库，重复代码和依赖项。

来自 Benedikt Rötsch 的 “让你的Webpack包瘦身”

包文件的审计分析通常会突出显示可重置的“重”依赖项（如 Moment.js 及其语言环境），以便获得更轻的替代方案（例如 date-fns ）。

如果您使用webpack，您可能会发现我们在这个仓库中提到的 公共库 会很有用。

测量，优化，监控和重复。

如果你不确定你的JavaScript 整体上是否有任何性能问题，请查看 Lighthouse ：

Lighthouse 最近添加了许多新的、您可能不了解的但是又有用的 性能审计分析

Lighthouse 是内嵌在 Chrome 开发者工具中的一款工具。它也可以作为 Chrome 扩展程序 使用。它为你提供了深入的性能分析，并提供一些潜在可以提高性能的建议。

我们最近为Lighthouse添加了标记 “JavaScript boot-up time（JavaScript 启动时间）”的功能。这个分析突出显示那些可能需要花费很长时间进行解析/编译的脚本，这会延迟可交互的时间。您可以据此拆分或优化你的代码。

你可以做的另外一件事是确保你没有把无用的代码发送给用户。

使用 Chrome DevTools中的Coverage选项卡 查找未使用的CSS和JS代码。

Code coverage(代码覆盖率) 是DevTools中的一项功能，它允许您在页面中发现未使用的JavaScript（和CSS）。 在DevTools中加载页面，coverage选项卡将显示被执行的代码数量与加载的数量。 您只需提供用户需要的代码即可提高页面性能。

提示：通过覆盖记录，您可以与您的应用进行交互，DevTools将更新您使用的包的数量。

这对于找出可以进行拆分的脚本以及延迟加载非关键脚本来说非常有用。

如果你正在寻找一种为用户提供高效的 JavaScript 分发模式，请查看 PRPL模式 。

PRPL（Push、Render、Precache和Lazy-Load）是一种模式，用于对每个路由进行代码拆分，然后利用 Service Worker 预先缓存未来路由需要用到的JavaScript和逻辑，并按需延迟加载。

这意味着当用户导航到体验中的其他视图时，它很可能已经存在于浏览器缓存中，因此他们在启动脚本和获取交互方面的成本降低了很多。

如果你关注性能，或者您曾经为您的网站做过性能补丁，那么你会发现有时候你修复可某个问题，但是过了几周后又出现了，发现团队中有人正在开发某个功能，无意中破坏了这个修复。就想这样：

幸运的是，我们有很多方法可以处理这个问题，其中一个方法就是制定 性能预算 。

性能预算是至关重要的，因为它们使每个人保持一致。它们创造了一种共享热情的文化，以不断改善用户体验和团队责任。

预算定义了可衡量的约束，让团队去实现性能目标。因为你不能突破预算的限制，所以每走一步都要考虑好性能，而不是事后再来解决。

根据 Tim Kadlec 的经验，性能预算的指标可包括：

• 里程碑时间 – 基于加载页面的用户体验的时间（例如，可交互时间（ Time to Interactive ））。您常常希望对几个里程碑时间进行配对，以便在页面加载期间准确地表现完整内容。
• 基于质量的指标 – 基于原始值（例如JavaScript的权重，HTTP请求的数量）。 这些都专注于浏览器体验。
• 基于规则的指标 – 来自于一些评测工具的评分，如 Lighthouse 或 WebPageTest 。通常通过一个或者一系列分数来对你的网站评级。
  
  Alex Russell 发布了关于性能预算的 推特 ，其中有几点值得注意：
• “领导阶层的支持很重要。为保证良好的整体用户体验而暂停或搁置功能性的开发的意愿来自管理者对技术产品的缜密思考。“
• “性能是由工具支持的文化。尽可能的让浏览器优化HTML+CSS。将更多的工作转移到JS会给您的团队及其工具带来负担。“
• “性能预算不会让你伤心。他们的存在是为了让组织自我纠正。团队需要性能预算来限制决策空间并帮助实现它们。“

每个参与人和其执行力都会关系到网站的用户体验。

性能指标通常是文化挑战，而不是技术挑战

在计划会议和其他会议中讨论性能。向业务利益相关者询问他们的性能预期。他们是否了解性能如何影响他们关心的业务指标？询问团队如何计划解决性能瓶颈问题。虽然这里的答案可能不尽如人意，但至少对话开始了。

这是一个性能执行计划：

• 创建您的性能愿景。 这是一份关于业务利益相关者和开发人员认为“良好表现”的协议
• 设定性能预算。 从愿景中提取关键绩效指标（KPI），并从中设定切合实际的可衡量目标。例如“在5s内加载并可进行交互”。这里可以不考虑JS大小指标。 例如“JS压缩后保持 < 170KB”
• 创建关于KPI的定期报告。这可以是发送给业务的定期报告，突出显示进度和成果。

Andy Still的 Web Performance Warrior 和 Lara Hogan的 Designing for Performance 都是讨论如何考虑如。何实现性能文化的优秀书籍。

那么性能预算的工具有哪些呢？你可以通过 Lighthouse CI 项目建立 Lighthouse 评分预算：

如果您的性能分数低于 Lighthouse CI 的某个值，则防止 pull

请求被合并。 Lighthouse Thresholds 是另一种基于配置的方法来设置预算。

许多性能监控服务支持设置性能预算和预算警报，包括 Calibre , Treo , Webdash 和 SpeedCurve ：

拥抱性能预算可以鼓励团队认真思考他们从设计阶段早期到里程碑结束所做出的任何决策将产生怎样的后果。

寻找进一步的参考？ U.S Digital Service通过设定类似“可交互时间”的目标和预算指标，记录 用 Lighthouse 跟踪的性能的方法 。

接下来..

每个站点都应该可以访问 实验和真实场景中性能相关的数据 。

要跟踪 JavaScript 可能对 RUM（真实用户监控）设置中的用户体验产生的影响，网络上有两个东西，我建议大家去看看。

第一个是 Long Tasks (长时间任务) ——一个API，帮助你收集真实世界中持续时间超过50毫秒并可能会阻塞主线程的任务。您可以记录这些任务并将它们记录到您的分析中。

第二个是 First Input Delay(首次输入延迟) (FID) ，是用于度量从用户首次向网站发起交互（如当他们点击按钮时）到浏览器能够响应该交互的时间。FID是一个实验性指标，不过现在已经有一个可用的 polyfill ，你可以尝试下。

在这两者之间，您应该能够从真实用户那里获得足够的遥测数据，以查看他们遇到的JavaScript性能问题。

众所周知，第三方 JavaScript 可能会对页面加载性能产生严重影响。虽然这个观点没错，但是是要认识到自己写 JavaScript 对性能的影响也非常重要。如果我们要加快加载速度，需要同时消除双方对用户体验产生的影响。

我们看到了几个常见的漏洞，包括在文档头部使用JavaScript来决定向用户显示那个版本的A/B测试。或者将A/B测试所有的JS都发送给用户，但实际上只用了其中一个 。

如果这是你目前遇到的主要瓶颈，我们还提供了一个有关加载 第三方JavaScript的指南

。

总结

性能优化是一段长途旅行。许多小的变化可以带来巨大的收益。

使用户能够以最少的阻力与您的站点进行交互。 运行最少量的JavaScript以提供真正的价值。 这可能意味着你需要采取渐进的步骤来实现目标。

最后，您的用户会感谢您。

译自 The Cost Of JavaScript In 2018