或许我应该直接使用 create-react-app。

我最近一直在致力于改进我个人的一个副项目Conju-gator.com的性能，这是一个用于练习西班牙语动词变位的小型应用程序。

该应用使用 React 构建，并使用 webpack 作为打包工具。静态文件托管在 Amazon S3 上，前端通过 CloudFront 内容分发网络提供服务。在使用 React 开发时，通常会将所有源文件和依赖项打包成一个名为“bundle”的 JavaScript 文件。众所周知，提供的 JavaScript 文件数量过多是导致性能问题的一个常见原因，因为随着依赖项的增加，bundle 文件的大小也会迅速增长。

最初我并没有过多考虑性能问题，因为它看起来像是一个很小的项目，源文件很少，依赖项也不多，我认为性能问题是以后才需要考虑的。

然而，该网站确实依赖于相当多的动词数据来生成训练问题，这些数据最初是一个 JSON 文件，我将其导入并与源代码一起打包，因此可能会在某些时候导致性能问题。

我决定运行 Chrome 的 Lighthouse 性能审核工具（一个非常棒的工具），并以此作为基准来评估我的网站的性能，结果令我震惊的是，它的审核得分竟然是 0%！

我做错了什么

审计结果指出了几个我可以改进的关键领域：

• 代码未压缩
• JavaScript 负载过高
• 非必要的CSS（计算机软件服务）并未被推迟。
• 文件未采用有效的缓存策略进行服务。
• 文件在传输前未使用 gzip 或等效压缩软件进行压缩。

最后两点是需要在 S3/CloudFront 层面解决的问题，因为它们属于服务器设置。解决方案是在上传到 S3 的对象中添加元数据，以确保它们带有 max-age 缓存控制标头，并且可以进行 gzip 压缩。修复这两个问题后，我的审计结果提高了约 50%。

我最终使用Google Web Font Loader解决了非必要 CSS 过早加载的问题（本可以延迟加载），虽然我也发现了一些其他异步加载 CSS 的方法，这些方法可能也很有用。CSS 的更改对审核结果影响不大。

Webpack改进

不过，我想先谈谈前两个问题，因为它们都与包的大小有关。我当时上传了一个3000kb 的JavaScript 包，而推荐的大小是小于 250kb，你就能明白我的做法有多么不合理了。

首先，我的代码没有被压缩，这是一个很容易解决的错误，因为有一个webpack 插件可以帮你完成这项工作，或者如果你在生产模式下使用 webpack，那么压缩是默认的！

这是另一个问题——我在构建生产环境的打包文件时没有使用生产模式mode: "production"。Webpack配置中的一行代码就解决了许多问题——它只包含了生产环境所需的库部分，从而大幅减小了打包文件的大小，而且还免费实现了代码压缩。Webpack 的生产环境打包指南非常清晰实用，我真希望早点看到它！

经过进一步研究，我决定在生产环境中移除源映射（webpack 指南建议保留源映射以方便调试，但使用轻量级版本）。源映射维护着一个从打包后的代码到原始源文件的映射关系，这样控制台中的行号和文件名指向的就是原始文件，而不是打包后的文件。然而，我希望尽可能地精简打包后的文件大小，所以完全移除了源映射，如有需要我会重新启用它。

通过使用Webpack Bundle Analyser，我能够观察到我的打包文件大小逐渐减小，并了解其大小的来源。

当分析器显示我的 node_modules 目录与源代码相比占用的空间合理，并且生产环境中的整个包大小不到 250kb 时，我非常高兴。

最后，我决定从包中删除动词数据并异步获取它，尽管此时我的审计已经完成了大约 98%，而且虽然这进一步减少了我的包大小，但并没有给我带来任何 Lighthouse 性能审计方面的改进。

 反思

现在回想起来，我当时做的改动其实很简单，我真觉得自己当初没意识到软件包有多臃肿是件傻事。不过，当时我确实花了几个小时才理清所有问题，找到最佳解决方案。

我一度想：“我真希望一开始就直接用 create-react-app！”因为 CRA 会提供默认的 webpack 配置，这些配置肯定针对生产环境进行了优化，并且包含了所有我最初省略的内容，甚至更多。

然而，CRA 的 webpack 配置长达 400 多行，这也是我一直不太愿意使用 CRA 的原因之一。我喜欢了解我的配置在做什么，并且能够在需要时进行修改，而我一直觉得 CRA 应用的配置很难调试和维护。

您怎么看？您是否更倾向于选择一种经过优化、符合特定要求的配置，而牺牲一些自定义选项？

您是否有过优化单页 React 应用性能的经验？

还有其他性能方面的胜利吗？

🙌