reactjs - 为什么 react 会延迟增加首次加载的时间

Question

我有一个小但开发起来很有趣的应用程序。这是一个快速的实验，旨在了解更多有关 redux 和 React 的知识，我认为该应用程序已经足够成熟，可以开始学习优化了。

我做了一些纯组件优化尝试，但它们没有改善首次加载的时间，所以我继续。 我尝试的下一个优化是使用 react 惰性来延迟加载一些我第一次不需要的组件。例如，我有一个错误组件，只有在必须显示不太可能的错误时才需要它，这就是我所做的，令人惊讶的是(根据灯塔)所有第一次指标(第一次交互的时间、第一次交互的时间)有意义的油漆等)变得更糟。

以下是尝试使用 React Lazy 之前的报告屏幕截图:

正如你所看到的，从性能的角度来看，没有太多需要改进的地方，但当我试图学习现代 react 时，我还是尝试了。这是我能够使用 React Lazy 拆分一个组件得到的最好结果:

如您所见，情况更糟。它检测到的问题并不都与缓存策略有关，它们是:

似乎主线程越来越忙于解析所有 JavaScript。这对我来说没有意义，因为进入 Chrome 开发工具并详细检查网络请求(在性能选项卡上)，结果包是并行下载的。然而，两个版本上的 bundle 大小几乎相同，只是应用程序的拆分版本有 5 个 block ，而不是 2 个:

第一个没有代码拆分的 bundle

URL
bundle.js
Duration
45.62 ms
Request Method
GET
Priority
High
Mime Type
application/javascript
Encoded Data
6.5 KB
Decoded Body
31.0 KB

第一个带有反应惰性分割的捆绑

URL
bundle.js
Duration
28.63 ms
Request Method
GET
Priority
High
Mime Type
application/javascript
Encoded Data
7.1 KB
Decoded Body
33.7 KB

第一个下载的 block :

Network request
URL
0.chunk.js
Duration
255.83 ms
Request Method
GET
Priority
High
Mime Type
application/javascript
Encoded Data
579 KB
Decoded Body
2.7 MB

第一个带有react惰性分割的 block (标记为5，但它实际上是第一个):

URL
5.chunk.js
Duration
276.40 ms
Request Method
GET
Priority
High
Mime Type
application/javascript
Encoded Data
559 KB
Decoded Body
2.6 MB

我的结论是，React Lazy 会带来巨大的开销，只有在加载的组件的大小足够大的情况下才会有返回。 然而，这是否意味着大型应用程序永远无法在第一次绘制时获得高分？ 我用 VUE 制作了一些更大的应用程序，其性能得分几乎为 90，所以我很确定我在这里做错了什么。

值得一提的是，第一个屏幕截图是从 github 页面提供的，而第二个屏幕截图是在本地提供的，但这不会影响手头的问题，不是吗？

该应用程序的非拆分版本的代码可在此处公开获取:https://github.com/danielo515/itunes

Answer 1

“脚本评估”最大耗时1.672ms。因此，尝试减少这个时间。

1. 分析 JavaScript 的大小，哪些库可以替换为较小的库 版本或使用纯 JavaScript。如果您使用 CRA，请尝试 Analyzing the Bundle Size或 webpack-bundle-analyzer。例如代替 lodash 也许你可以使用较小的库 lodash-es ;

2. 使用服务器端渲染。考虑使用 loadable-components (来自 React doc 的建议)。但如果您使用速度较慢的服务器(或兑现水平较低)，则可能会增加“Time to First Byte”的值；

3. 使用Pre-Rendering into Static HTML Files 。

此外，一个非常有用的网页速度分析工具是 webpagetest.org .