🗂️ 👴🏽 🤞🏿 JavaScript价格2018 🍘 🏌️ 👩🏾‍🎓

交互式网站的用户体验可能包括向其发送JavaScript代码的步骤。通常-此代码过多。如果该站点使用大量JavaScript，则这尤其会影响移动用户。例如，您是否曾经浏览过看起来似乎已准备就绪但对链接的点击或滚动浏览的尝试没有反应的移动网页？

进入移动浏览器的JavaScript代码仍然是最昂贵的资源，因为从许多方面来看，它都可以将页面的转换延迟到可以与它们进行交互的状态。今天的JavaScript在系统上有什么样的负载？如何分析网站？如何加快交互式网页浏览器的加载和处理？埃迪·奥斯曼尼（Eddie Osmani）今天将发表其翻译，因此决定寻找这些问题的答案以及其他在2018年使用JavaScript开发网站的人提出的问题。

一般规定

看一下这份报告，该报告展示了处理各种设备的CNN JavaScript代码所需的时间。它是基于通过WebPageTest.org项目进行的测量而建立的（这是此报告的源数据表，沃尔玛网站上也有数据）。

处理各种设备的cnn.com JS代码所需的时间

如您所见，高端手机（iPhone 8）可以在大约4秒钟内处理JS代码。中档手机（Moto G4）大约需要13秒才能解决相同的问题。尽管使用了诸如阿尔卡特1X这样的现代设备，但预算仍需要约36秒。

今天，我们将一方面讨论Web开发人员可以应用的策略，以创建便捷，现代化的网站，另一方面，确保这些网站的JavaScript组件有效地加载，处理和运行。简而言之，这是我们谈话的重点，顺便说一下，这些要点是基于我最近的讲话：

为了使Web项目快速运行，您只需下载当前页面所需的JavaScript代码。使用代码拆分技术可以使您尽可能快地组织用户肯定需要的加载，并将延迟加载技术应用于其他代码片段。多亏了这种方法，页面才有机会比其他情况更快地加载，并迅速达到可以与之交互的状态。如果您使用的系统默认情况下使用基于路由的代码分隔，则将有所不同。
遵守为项目参数设置的限制，即所谓的“绩效预算”，并学会遵守这些限制。因此，例如，预期为移动设备设计的页面所需的压缩后的JS代码的大小不应超过170 Kb 。将此类材料转换为正常形式时，可获得大约700 Kb的代码。这样的限制对于项目的成功至关重要，但是，只有它们本身不能奇迹般地快速创建缓慢的站点。团队文化，结构和规则实施监控方法在这里发挥着作用。没有预算的项目开发会导致生产率逐渐下降，并可能导致不愉快的后果。
了解如何审核 JavaScript包（程序集）并减小其大小。客户很有可能必须下载完整版本的库，而只需要其中的一部分即可使项目正常工作。也许项目包含了不需要的浏览器的polyfill，并且不排除重复代码。
每次用户与站点的交互都是一个新的等待期的开始，之后便可以与站点进行工作（这就是所谓的“交互时间”，TTI，“交互时间”）。在这种情况下，优化值得考虑。对于慢速的移动网络，传输代码的大小非常重要，而解析JavaScript代码所需的时间则用于具有中等计算能力的设备。
如果使用客户端JavaScript无法改善用户体验，请考虑在这种情况下是否使用JS。也许在这种情况下，在服务器上呈现HTML代码会更快。考虑限制客户端Web框架的使用，考虑仅将其用于形成没有它就无法做到的页面。如果这些技术使用不当，则在服务器上进行渲染和在客户端上进行渲染都会成为严重问题的根源。

现代Web项目和JavaScript过度使用的问题

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

这就是浏览器的感觉，充满了文件

无论我多么喜欢JavaScript，我都不得不承认，它始终是浏览器要处理的网站上最昂贵，最困难的部分。实际上，我想谈谈为什么JavaScript可以成为网站的主要问题。

JavaScript是网站上最难的部分

根据7月 JavaScript存档有关使用JavaScript的报告，如今，平均每个网页使用大约350 KB的压缩后的JavaScript代码。这段代码被解压成浏览器需要处理的1 MB脚本。为了使移动用户能够与这样的页面进行交互，他将不得不等待14秒以上。

包含350 KB压缩JS代码的平均页面在大约15秒内在移动设备上变为交互式

如果您不清楚您的JavaScript捆绑包对用户与您的网站进行交互要等待多长时间的影响，请查看Lighthouse工具。

在等待页面准备好在移动设备上工作时，移动网络上数据的下载时间及其在非快速处理器上的处理做出了重大贡献。

让我们通过查看OpenSignal数据来分析移动网络领域的事务状态。下图左侧显示了世界上4G网络的可用性（该国领土涂成的颜色越深-可用性越高），数据传输速度在右侧显示（同样-越暗-速度越高）。该研究不包括领土为灰色的国家。值得注意的是，在农村地区，即使在美国，移动数据传输的速度也可能比城市慢20％。

4G网络可用性和数据速率

上面我们说过，下载和解析350 KB缩小和压缩的JS代码需要一定的时间。但是，如果您查看热门站点，事实证明它们会向用户发送更多代码。下图所示数据取自此处。它们是各种众所周知的Web资源（例如Google Sheets）的解压缩JavaScript包的大小，在桌面平台上，解压缩的JS代码的大小为5.8 MB。

各种资源的解压缩JavaScript程序集大小

如您所见，在台式机和移动平台上，浏览器有时都必须处理数MB的JS代码才能与各种站点一起使用。这里的主要问题是-您负担得起使用如此大量的JavaScript吗？

JavaScript不是免费的

根据Alex Russell的说法，需要大量JavaScript才能运行的网站根本无法为广大用户所访问。根据统计，用户不会等待（也不会等待）此类资源的加载。

你负担得起吗？

如果您必须向用户发送过多的JS代码，请考虑使用代码拆分技术将捆绑包分成小部分，或者使用树状摇晃算法减少代码量。

JS现代站点捆绑包通常包括以下内容：

客户端Web框架或用户界面库。
用于管理应用程序状态的工具（例如Redux）。
Polyfills（通常用于不需要它们的现代浏览器）。
库的完整版本，而不仅仅是实际使用的部分（例如，完整的Lodash库，该版本中的Moment.js库，支持所有区域标准）。
一组用户界面组件（按钮，标题，侧边栏等）。

以上所有因素均导致用户浏览器必须接受并处理的代码的整体大小。自然，代码越多-浏览器能够使页面进入工作状态所花费的时间越多。

加载网页的过程类似于在投影机中移动胶片，该过程捕获了三个关键步骤，可以回答以下问题：

这是发生了吗？（发生了吗？）。
这有什么用？（有用吗？）。
可以使用吗？（可以使用吗？）。

想象这些步骤的方法，如果我们继续与电影类比的话，这些步骤又可以分为较小的“帧”。

页面加载是一个过程。最近，Web行业的重点已转移到反映用户使用Web页面的用户体验的指标。现在，我们没有在全神贯注于onload或domContentLoaded ，而是想知道用户是否真的可以使用该页面。如果他单击页面上的某些内容，是否会立即做出反应？

网页加载过程

在步骤“这正在发生吗？” 该站点可能开始将一些数据传输到浏览器。您可以在此处询问有关用户浏览器对服务器的访问是否已固定（例如，通过单击某个链接）以及服务器是否已开始生成响应的问题。
在步骤“这有什么用？” 该网站显示一些文本或其他内容，这些内容首先使用户可以学习有用的内容，其次可以使用户感兴趣。
在步骤“可以使用吗？” 用户可以开始与网站进行全面互动，这可能导致某些事件。

互动页面及其问题

上面我们提到了交互时间（交互时间，TTI）。让我们更详细地讨论它。在下面的内容中，在由Kevin Schaaf制作的动画图形中，您可以看到页面（不是所有材料都已下载并处理）如何使用户认为他可以执行某些操作，但实际上是由于相应的JS代码尚未完全处理，因此无法执行此操作。

用户为准备就绪所需的时间太长的页面而烦恼

为了使页面具有交互性，它必须能够快速响应用户交互。支持页面的少量JS代码有助于减少准备页面所需的时间。

如果用户单击链接或滚动页面，则他需要看到响应其行为而发生的事情。如果页面没有响应用户的影响，则他们不喜欢它。

这是使用Lighthouse工具在测试环境中生成的报告，其中包含一组指标（还有交互时间），重点关注用户如何感知页面。

Lighthouse报告，其中包含反映用户对页面的感知的指标

当在某个项目中使用服务器渲染时，会发生与上图所示类似的事情，并且服务器上生成的结果以及用于“使”用户界面焕然一新的JS代码”的结果会传输到客户端（例如，，可以连接事件处理程序和负责页面行为的其他一些机制）。

当浏览器正在处理连接用户可能需要的事件的代码时，很可能所有这些都将在处理用户输入的同一线程中执行。这就是所谓的主流。

使用主线程加载过多的JavaScript代码（例如，在使用<script>时会发生这种情况），对交互时间产生不利影响。下载计划在Web Worker中运行或与Service Worker缓存的JS代码不会对TTI产生如此强烈的负面影响。

这是一个视频，显示了用户处理失败站点的示例。通常，用户可以安全地选择复选框或单击链接。但是，如果您模仿主线程的阻塞，则用户将无法执行任何操作-既不选中该复选框，也不单击该链接。

尽量减少可能阻塞主线程的情况。您可以在这里找到有关此内容的详细信息。

我们看到与我们合作的团队在许多类型的站点上都受到JavaScript在TTI上的影响。

JavaScript能够在交互模式下延迟可见元素的输出

对于许多公司来说，这种情况可能是一个严重的问题。上面是Google搜索引擎的一些示例。元素显示在屏幕上，看起来好像已经可以使用它们，但是如果过多的JS代码负责其功能，则它们会延迟进入操作模式。这可能对用户没有吸引力。理想情况下，用户可以与之交互的所有内容都应尽快运行。

TTI和移动设备

这是使用慢速3G网络连接时news.google.com的TTI。在这里，您可以看到构建此图所依据的数据。通过WebPageTest和Lighthouse进行测量。

适用于news.google.com的TTI

分析这些数据后，您可以看到最低和最高类别的设备之间存在严重差距。因此，TTI测试中功能最强大的设备约为7秒。最简单的-已经是55秒。

这里我们有一个关于TTI应该是什么的问题。我们相信您应该努力在不到5秒的时间内使连接到慢速3G网络的中档设备上的页面更具交互性。

值得在5秒内争取TTI

也许在这里您会说所有用户都拥有高端电话并已连接到快速网络。但是，真的是这样吗？也许有人在某个咖啡馆连接了“快速” Wi-Fi网络，但实际上，他只能使用2G或3G连接的速度特性。在评估用户的能力时，人们不能低估各种设备和访问他们使用的网络的方法。

JS代码精简对TTI的影响

以下是一些示例，这些示例说明如何减小JS页面代码的大小影响TTI。

Pinterest项目将 JS包从2.5 MB 减少到不到200 KB。互动时间从23秒减少到5.6秒。该公司的收入增长了44％，订阅数量增长了753％，移动版本网站的每周活跃用户数量增长了103％。
AutoTrader 将 JS捆绑包减少了 56％，从而使TTI减少了约50％。
Nikkei.com资源将JS捆绑包的大小减少了43％，这使TTI缩短了14秒。

这些结果表明，应该为灵活的移动环境设计站点，同时尝试确保它们不与大量的JavaScript代码绑定。

网站设计基于灵活的移动环境

TTI有很多工作要做。例如，使用移动设备查看其网络功能受某个收费计划限制的站点可能会影响此指标，TTI可能会受到以下事实的影响：用户通过公共（不是特别快速的Wi-Fi接入点）工作，或者移动用户处于不断运动中，定期失去网络。

当某人在与我们刚才描述的情况类似的情况下使用您的网站时，同时，为了确保资源正常工作，有必要下载并处理大量JS代码，对于用户而言，与该网站的交互会话可能最终是空的屏幕。或者，如果该站点仍至少在屏幕上显示某些内容，则可能需要很长的时间才能使用它。理想情况下，可以通过简单地减少站点工作所需的JS代码的大小来缓解此类问题。

为什么JavaScript如此昂贵？

为了理解为什么为页面准备JavaScript代码会给系统带来巨大的负担，让我们讨论一下服务器将数据发送到浏览器时会发生什么。

因此，这一切都始于用户输入要进入浏览器地址栏的站点的URL。

这一切都始于在浏览器的地址栏中输入URL

然后将请求发送到服务器，服务器将HTML标记返回给浏览器。浏览器解析此标记，并找到构成页面所需的资源：CSS，JavaScript，图像。然后，浏览器需要从服务器请求所有这些信息并进行处理。
在这种情况下，例如在使用Google Chrome浏览器时，一切都会发生。

整个过程的困难在于，最终，JavaScript成为整个系统的瓶颈。理想情况下，我们希望浏览器快速显示页面的图形表示，之后便可以与其进行交互。但是，如果JavaScript是瓶颈，那么在屏幕上显示某些内容后，用户将被迫无奈地检查自己无法使用的内容。

我们的目标是确保在用户与Web资源进行交互的现代方案中，JavaScript不再成为瓶颈。

如何加快使用JavaScript的速度？

JavaScript加速任务可以分为几个子任务。在与JS相关的所有事情上花费的时间是加载，解析，编译和执行代码的总和。

JavaScript的速度包括加载，解析，编译和执行代码的速度

所有这些都意味着我们在代码传输及其处理中都需要速度。
如果花太多时间在JS引擎中解析和编译脚本，这会影响用户与页面进行交互的时间。

考虑有关上述过程的一些数据。以下是有关V8 （Chrome中使用的JavaScript引擎）如何花费时间处理包含脚本的页面的更多信息。

加载页面时，解析和编译步骤在V8中花费的时间为10-30％

代表解析热门站点代码所需时间的片段以橙色突出显示。黄色代表编译时间。这两个阶段合在一起花费了处理页面JS代码所需的总时间的30％。 30％是一个严肃的数字。

在Chrome 66中，V8在后台线程中编译代码，最多可节省20％的编译时间。但是，解析和编译仍然是非常昂贵的操作，因此您很少会看到大型脚本在不到50毫秒的时间内开始执行。加载后，即使它是在后台线程中编译的。

JavaScript与其他资源有何不同？

应该记住的是，例如处理大小为200 Kb的脚本以及处理大小相同的图像所需的时间会有很大的不同。在此示例中，通过网络传输的数据量可能相同，传输时间也相同。不能说将数据转换为可以使用的东西所需的资源成本。

200 KB的JavaScript代码和相同大小的JPEG文件是两件事。

JPEG图像需要解码，光栅化和显示。 JS包是必要的，如果我们简单地考虑它，则可以加载，解析，编译，执行。实际上，引擎在处理JS代码的过程中必须解决其他问题。总的来说，应该记住，处理JavaScript代码需要花费更多的系统资源，而JavaScript代码的大小（以字节为单位）可与其他材料的大小相媲美。

最近引起人们极大关注的浏览器处理JavaScript代码速度问题的原因之一是移动技术的惊人普及。

移动网络和设备多样性

移动网络世界中有各种各样的设备。如果您尝试简单地按成本对它们进行分类，则它们是入门级手机，价格在30美元左右，中端设备价格在200美元以下，高端设备价格在1000美元左右。

各种移动设备

如果情况良好，则该站点将必须在中级和更高级别的设备上工作。然而，实际上，并非所有用户都具有这样的设备。

因此，大多数用户可以从初始和中间级别的设备在Internet上工作。此外，即使我们将自己限制在这两个级别上，它们所包含的设备的功能范围也可能很大。例如，其中一些处理器将全速运行，而其中一些处理器可降低频率以节省能源或防止设备过热。

可比处理器可能具有不同的缓存大小。最后，设备可以使用完全不同的处理器，更不用说其他系统组件了。结果，处理诸如JavaScript之类的资源所需的时间将在很大程度上取决于用于查看站点的设备的特性。此外，即使在美国，入门级电话也在世界范围内使用。

这是newzoo对当前使用的Android智能手机进行研究的结果。如您所见，Android OS已安装在所用手机的75.9％上，而预计在2018年将再增加3亿台设备。这些新设备中有许多将是预算友好的。

2018年的Android智能手机

让我们看看在各种现代设备上解析和编译JavaScript需要花费多长时间。这是原始数据。

处理（解析和编译）1 Mb未压缩的JS代码所需的时间（例如，使用gzip压缩的最小代码约为200 Kb）。 测量是在真实设备上手动进行的。

该图的顶部是顶级设备，例如iPhone 8，它们可以相对快速地处理脚本。如果降得更低，那么已经有中档设备了，例如Moto G4和非常简单的阿尔卡特1X。这些设备之间的区别是肉眼可见的。

随着时间的流逝，运行Android的手机变得越来越便宜，但并没有变得更快。通常，便宜的电话使用带有较小L2 / L3缓存的弱处理器。因此，如果您专注于顶级设备，则可以完全忽略没有此类设备的普通用户的需求。

例如，让我们返回一个我们已经接触过的真实网站。使用WebPageTest进行测量，这是源数据。

处理各种设备的cnn.com JS代码所需的时间

在iPhone 8（使用A11芯片）上，处理过程比中档手机快9秒钟。我们正在谈论的事实是，该网站将在iPhone 8上提前9秒钟进行互动。

现在，当WebPageTest支持Alcatel 1X（这款手机在美国以约100美元的价格出售，在销售开始时就已出售）时，我们可以看到cnn.com网站的“ 故事板 ”正在入门级和中端手机上加载。阿尔卡特1X使用3G网络在65秒内完全加载了站点。它甚至都不是“慢”。这是完全不能接受的。

使用Alcatel 1X，Moto G gen 1，Moto G4下载cnn.com

这项研究表明，我们可能应该停止考虑我们所有的用户都在使用功能强大的设备进行快速网络工作。因此，应在真实的网络和真实的设备上测试应用程序。站点必须运行的各种移动设备是一个实际问题。

不要以为所有用户都使用快速网络和功能强大的设备。

Ilya Grigorik说，波动是杀死用户体验的原因。即使快速的设备有时也会运行缓慢。快速的网络可能很慢。可变性绝对可以减慢任何事情。

尽管可变性可能会破坏用户体验，但是基于不是最高效的设备的Web项目的开发使您可以使“快速”和“慢速”用户都感到舒适。如果您的团队可以分析统计数据并了解用于您的站点的设备，这将提示您哪些设备可能值得保留在办公室并用于测试站点。

测试站点位于连接到真实网络的真实设备上

如果您自己的中端手机的选件不适合您，则WebPageTest项目可以在选择移动测试配置时访问自定义的Moto G4手机。那里还有其他配置。

此外，必须在典型用户所在的网络上执行测试。早些时候，我谈到了在入门级和中档手机上测试站点的重要性，而Brian Holt在此主题上发表了以下出色的评论：认识受众非常重要。他说，了解受众并针对受众需求优化应用程序性能至关重要。

了解你的听众

应该注意的是，并不是每个站点都可以在连接2G网络的入门级设备上正常工作。因此，面向生产设备的行为也是完全正常的行为。

以下是通过Google Analytics（分析）→受众群体→移动设备→设备获得的报告。它显示有关站点访问者的设备和操作系统的信息。

来自Google Analytics（分析）的报告

您的许多用户可能位于范围的顶部，或者可能分布在不同的范围内。最主要的是要知道使用哪些设备与您的站点一起使用，这将使您能够就什么重要，什么不重要做出明智的决定。

针对慢速网络和低功耗设备的优化

JavaScript — . : , , ( gzip , Brotli , Zopfli ).

,

.

JavaScript — .

—

-, , , , .

, , JavaScript, , , , .

JavaScript-,

, JS-, , , . , — ( code splitting ).

, JS- , , , . , .

—

, , , JS-, . , .

webpack Parcel . React , Vue.js Angular .

React

React- React loadable — , API, React, .

.

 import OtherComponent from './OtherComponent'; const MyComponent = () => ( <OtherComponent/> );

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