8

我有一个小而有趣的开发应用程序。这是一个快速的实验，可以更多地了解 redux 和 react，我认为应用程序已经足够成熟，可以开始学习优化了。

我做了一些纯粹的组件优化尝试，但它们并没有改善首次加载的时间，所以我继续前进。我尝试的下一个优化是使用 react lazy 来延迟加载一些我第一次不需要的组件。例如，我有一个错误组件，仅当我必须显示一个不太可能的错误时才需要它，这就是我所做的，并且令人惊讶的是（并且根据灯塔）所有第一次度量（第一次交互的时间，第一次的时间）有意义的油漆等）变得更糟。

这是在尝试使用 react lazy 之前的报告截图：

没有反应懒惰

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

反应懒惰

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

检测到的问题

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

第一个没有代码拆分的包

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

第一个下载的块：

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

第一个带有反应延迟拆分的块（标记为 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

我的结论是，reactlazy 引入了显着的开销，只有在加载的组件的大小足够大时才会得到回报。但是，这是否意味着大型应用程序在第一次绘制时永远无法获得高分？我用 VUE 做了一些更大的应用程序，性能接近 90，所以我很确定我在这里做错了什么。

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

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

4

1 回答 1

2

“脚本评估”中最大的耗时1.672ms。所以，试着减少这个时间。

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

  2. 使用服务器端渲染。考虑使用可加载组件 （来自React doc的建议）。但是如果你使用慢速服务器（或低级别的兑现）有可能增加“Time to First Byte”的值；

  3. 在静态 HTML 文件中使用预渲染。

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

于 2019-05-01T15:53:16.537 回答