企业把对讲机放在他们的网站上是因为他们希望与用户进行实时通信。实时意味着一个快速反应的信使。为了帮助Messenger尽可能快地在web上加载，我们最近开始了优化其捆绑包大小的工作。快速加载时间很重要，因为它让Messenger感觉自己是网站的自然组成部分，而不是附加组件。它也有助于提高网站的整体速度，这对用户体验和谷歌搜索性能非常重要。最重要的是，一个快速加载的信使可以帮助企业在客户登陆网站时立即与他们建立联系。下面是我们如何使用webpack bundler功能来缩小对讲机信使的大小。我们所采取的步骤可以应用于任何JavaScript应用程序。更多功能=更大的捆绑大小对讲机信使是一个现代化的react.js公司包含许多组件、第三方库和样式表的应用程序。从历史上看，Messenger是一个包含所有应用程序代码和供应商代码的JavaScript文件。这个文件，叫做框架.js，是我们应用程序的入口点，我们将其称为Messenger捆绑包。随着这些年来推出了许多新的增强功能，捆绑包的大小已经慢慢增长。去年年底，我们提供了将近600kb的gzip JavaScript，比年初的400kb有所增加。

因为我们每天都向代码库发送特性，所以我们知道这个问题只会随着时间的推移而增加。信使里有什么？缩小捆绑包大小的第一步是查看代码库中占用空间最多的内容。这里是所有代码的可视化框架.js，由webpack bundle analyzer生成：

如您所见，Messenger包由三个主要部分组成。Node_模块，它们是我们使用的供应商库，如React、Redux和Lodash。App，其中包含我们的应用程序代码，主要是react.js公司组件样式表，包含sass编译的样式优化Messenger捆绑包一旦我们了解了Messenger捆绑包的不同部分及其各自的大小，我们就确定了将产生最大影响的更改。我们寻找重复的或很少执行的代码，以及可以异步加载的代码。以下是我们所做的主要改变。1拆分供应商包在对讲机上，我们每天都部署几十个新版本的信使。每次部署时，我们都会生成一个新的Messenger捆绑包，网站访问者必须重新下载。由于供应商软件包约占我们捆绑包的40%，而且它们不经常更改，所以我们采取的第一步是将它们拆分成一个单独的捆绑包。Webpack支持现成的包拆分。将其配置为将供应商软件包拆分为单独的捆绑包，如下所示：

如果Web包配置中有多个条目，则可以使用以下代码将单个条目作为目标：chunk:chunk=>块.名称===[您的输入]通过此更改，我们现在加载应用程序包(框架.js)和供应商捆绑包(供应商.js)单独使用Messenger访问网站时。浏览器将缓存供应商捆绑包，如果捆绑包没有更改，返回的访问者将不再重新下载该捆绑包。2按路径拆分应用程序在缩小了供应商捆绑包的大小之后，我们进一步研究了我们的应用程序包，并决定尝试按路径拆分应用程序。为此，我们引入了一个稍加修改的可加载组件。此组件允许我们在加载供应商捆绑包时显示Messenger的加载状态。如果网络请求失败，组件将负责重试，并在需要时显示错误状态。这是我们简化的应用程序组件的外观：

使用Loadable拆分Messenger组件的代码如下所示：

由于将Messenger拆分为单独的捆绑包会有延迟成本，因此我们现在在用户悬停在Messenger启动器上时预加载Messenger捆绑包，而不是等待他们单击启动器。当站点执行其他网络请求时，这将消除大多数不需要的延迟。

三。重构样式表随着供应商软件包和应用程序代码的优化，现在是时候看看我们的Sass样式表了，它占了框架.js捆绑。

我们的Messenger中的样式在历史上是通过经典的CSS文件和Sass预处理器完成的。我们无法区分哪些样式属于哪个组件，所以很难对它们进行捆绑拆分。这意味着我们必须挂载整个样式表，即使我们只是呈现启动器。我们的Sass样式表有超过4000条规则，浏览器必须一直下载和解析这些规则，即使大多数样式表规则没有被使用。所以我们决定在JS中引入CSS方法来编写CSS。在JavaScript文件中编写样式有很多好处，但最重要的好处是能够静态链接样式和组件。通过确定哪些样式在编译时属于哪个组件，我们现在可以使用情感库将它们捆绑在一起。使用情感，您可以在模板文本中声明样式，并且只有在使用它们的组件被呈现时才装载这些样式。由于样式是React组件，因此我们可以免费获得捆绑分裂支持。"从不与Messenger交互的用户无需下载可能会降低网站体验的无关代码"随着这一变化，网站访问者在打开Messenger之前不再下载Sass样式表。从不与Messenger交互的用户将不需要下载可能会降低网站体验的无关代码。现在，我们已经将我们的启动器迁移到了情感上，因为重构整个代码库需要一些时间。一旦我们将整个代码库转换为情感，就可以删除Sass样式表。同时，我们将Sass样式表分割成一个单独的包，并且只有在渲染组件还没有转换为情感时才加载它。4进一步优化供应商捆绑包我们的vendor依赖项现在在一个单独的bundle中，但是在vendor bundle中，仍然有机会减小各种包的大小。我们发现了几个实例，我们导入的是整个库，而不是实际使用的函数子集。通过实现动态导入和其他代码更改，我们已经能够减少各种供应商软件包的大小。例如：内部通信翻译包：这个包是我们的内部库，它为所有支持的语言环境生成翻译。整个库几乎是60kb，但是95%的库大部分时间是未使用的，因为我们一次只能显示一个语言环境。通过使用动态导入默认情况下只包含英语区域设置，我们可以将包的大小减少55 kbgzipped.是的导入这些翻译的逻辑如下：

PSL：这个包是所有公共域名后缀的列表，我们用它来确定设置cookies的最佳域。但由于顶级域有许多边缘情况，这是由于公司id，我们最近决定向服务器添加所有可能的tld的列表，并检查那里的逻辑。因此，我们可以删除PSL包并保存36kb的gzip数据。Sentry：这个包用于收集我们应用程序中的错误，但由于错误对我们来说非常罕见，我们决定在默认情况下停止绑定此客户端，并保存25KB的gzip压缩数据。

如果您使用redux raven中间件，则需要将其删除，因为它将始终包含Sentry客户端。但是，您可以创建自定义中间件来存储操作并在错误弹出时填充breadcrumb。Lodash：我们将整个Lodash模块捆绑在一起，但实际上在Messenger中只使用了Lodash函数的一个子集。因此，我们使用的Lodash包的大小从25kb缩减到11.7kb，使用babel插件Lodash来选择我们使用的特定模块。它要求我们做一些小的重构，因为不支持链序列。CSS包：我们加载整个包来解析和stringify CSS。然而，我们实际上只使用parseapi。树震动在CSS模块中不起作用，因为它在中没有sideEffects属性包.json. 在将导入从CSS改为CSS/lib/parse之后，我们将gzip压缩的文件大小从10kb减小到1.7kb。下划线：我们使用下划线导入throttle，这是不必要的，因为我们已经使用Lodash并且可以从Lodash导入throttle。新的Eslint规则将防止意外导入下划线。面向未来的信使包大小由于这些变化结合在一起，我们能够为我们的客户提供更快的Messenger体验。现在在web上加载Messenger只需要240KB，而现在只需要将近600KB。在移动设备上，节省的400KB可以节省最多5秒的加载时间