后端开发教程 - Java、Spring Boot 实战 - msg200.com
为什么我们的网站很慢——捆绑包大小的重要性
其背后的原因不是 Reactjs，不是框架、服务器、API，也不是互联网。
引擎盖下
故事要从一年前说起，当时我正在报道 React 和 React Native 应用优化相关的内容。
我在一个故事中介绍了超过15 种关于如何提高 React 应用程序性能的方法。
这就是软件开发的魅力所在——它永远不会停滞不前，也不会千篇一律。因为即使在一年后的今天，我又读到了一个新故事，讲述了包大小对应用程序性能的影响，以及一个令人费解的故事，让我理解了网站速度慢的原因。
就在鼻子下面
一年来，我报道了很多有关 React 应用程序优化的故事，但今天我对 React 应用程序有了新的视角。
鸟瞰视角——找到问题的根本原因
这不是什么高深的科学，但让我用这个故事来解释一下——
- 我们首先在 React.js 中创建一个应用程序
- 然后我们使用框架和包并添加代码
如果我们的高级开发人员要求我们改进 React 应用程序的性能，我们总是按照所谓的通用方向进行，如下所述
- 检查图像尺寸
- 检查互联网
- 检查 API
- 检查存储库的代码结构架构或大小
- 检查 Javascript 框架和语言曲折（例如在 reactjs 中重新渲染）等等。
但是如果我告诉你采用从下到上的方法呢？
让我们从这个问题开始——
浏览器如何加载网站？
- 服务器将应用程序包或响应（如 HTML）发送到浏览器
- 网站加载 HTML 文件，如果存在 javascript，则会获取、解析、编译和执行该文件。
- 接下来加载 CSS
- 最后，图片加载或延迟加载
太棒了，那么，整个网站运行缓慢的真正原因是什么呢？
当然，这些事情都需要时间，不是吗？
因此，如果我们排除 API 响应，那么在 HTML、CSS、JS 和 Image 中，唯一占用浏览器大部分执行时间的就是 Javascript。
要知道，图像和大尺寸文件并非每次都是罪魁祸首。
例如，下图表明，如果在浏览器中加载相同大小的图像和相同大小的 JavaScript，则 JavaScript 文件比图像需要更多的时间来处理。
图像需要 0.062 秒，JavaScript 需要 2 秒
自下而上的方法
检查 javascript 文件大小并尝试减小它，即使 JS 文件包含图像也尝试优化图像。
理解如何显著提升 bundle 的解析、编译和执行速度的核心原因。这几乎可以掩盖大部分应用程序运行缓慢的原因。
如果没有，那么是时候进一步排查根本原因了。依次检查图像优化、重新渲染、分片和 API 响应。
捆绑包大小的影响
现在大多数网站都集中在服务器端，包含的 JavaScript 代码比 HTML 和 CSS 代码要多。Bundle 文件发送到浏览器时，无论压缩还是解压，都会被解析、编译并执行。
想象一下，如果我向浏览器发送 100Kb 的应用程序包，而我发送 25kb 的应用程序包，您认为哪一个会花费时间？
出于好奇，上述 npm 包将通过在本地显示图像来帮助您分析捆绑包大小，如下所示。
打包文件越小，浏览器 CPU 和内存的负载就越小，网站运行速度就越快。很简单，并非高深莫测。
我们已经怀疑 JavaScript 可能是导致应用运行缓慢的罪魁祸首。此外，如果 App Bundle 中包含了大部分 JavaScript 代码，那么在浏览器上完全运行所需的时间就会更长。
因此，我们应该考虑最终的打包体积应该较小，因为浏览器会加载整个 JavaScript 文件。
JavaScript 的替代方案
当我理解了这一点后，我又想到了一个问题。
那么为什么我们在前端支持服务器端或基于 JavaScript 的应用程序？
为什么我们不能回到在前面编写 HTML 和 CSS 呢？
我得到的答案是否定的，在前端主要使用 HTML 和 CSS 并不正确，而且在每种情况下都没有用。
React 等框架由于可以在前端直接处理 javascript，因此有助于更轻松地开发 Figma、Gmail、电子商务和游戏等产品。
真实示例
我们提出了一个新概念，叫做“孤岛模型”。Astro 是一个全新的多页应用框架，它只负责向浏览器提供 HTML 文件。
但 Astro 不能用于每种产品，这实际上取决于产品类型，如果您想知道原因，下面就是它的故事。
Astro 不能用于需要管理大量状态、动画、电子商务和动态网站的应用程序。
归根结底，我们无法每次都仅使用 HTML 和 CSS 轻松开发出更高级、更复杂的产品。我们需要 JavaScript 来简化开发。
我建议不要切换。
改善捆绑包大小
让我们回到捆绑包大小的影响。
如何改善？
- 寻找代码分割，只加载所需的代码并尝试重用
- 使用加载器或 webpack 插件来最小化包的大小
- 删除未使用的依赖项
- 延迟加载依赖项，仅在被要求时加载
- 缓存输出
改进捆绑包的大小仍然不是一件容易的事。
您可以使用以下命令检查 next.js 包的大小。
yarn run build
它将提供捆绑包大小输出，您可以尝试进行更改并测量捆绑包大小的改进。
最有效的方法是在浏览器的“检查”选项卡中，在性能部分检查整个应用程序包。你可以谷歌搜索一下，因为它不太难理解，所以本文就不多说了。
尝试引入如下改变
- 代码拆分
- 使用 React Query 或 Service Worker 进行缓存
- 使用加载器最小化最终输出大小
- 您可以继续在本地测量捆绑包大小
- 然后在检查选项卡中检查最终性能。
google lighthouse测量的性能还会给出性能的百分比输出。
根本原因
JavaScript 的根本原因以及 JavaScript 的承载者是应用程序包 (App Bundle)。应用程序包之所以重要，是因为它的体积越大，占用的 CPU 和内存也就越多，执行所需的时间也就越多。
还要理解这一点，有时即使包大小还可以，应用程序仍然运行很快。在这种情况下——
- 要么是浏览器的 CPU 太慢了，这种情况通常发生在旧设备上
- 或者网络连接较差
仅此而已，也仅此而已。
最终行动计划
- 测试哪个手机应用程序，如果手机很慢则检查新手机上的应用程序。
- 确保网络连接良好
- 即使应用程序在所有具有良好互联网连接的手机上都很慢，也可以继续使用捆绑包大小。
- 如果捆绑包大小不是问题，请检查图像大小以及其他问题，例如重新渲染、HTML 解析、字体和 CSS 等。
通过自下而上的方法，我们有了解决整个应用程序性能问题的新方法。
最终判决
我希望将来能看到更多有助于遵循这种方法的工具，因为没有人谈论它。
我之所以能找到根本原因，是因为我读了谷歌工程经理
Addy Osmani写的这个故事
结论
我正在阅读更多有关应用程序性能的捆绑包大小以及我们的应用程序运行缓慢的根本原因的文章。
因为我已经完成了图片优化、React 渲染问题以及常规的应用优化工作。现在是时候深入研究这个问题的根源并尝试一下了。
如果您发现更多相关读物，请分享，我很乐意阅读。
下次再见，祝您有美好的一天。Shrey
iHateReading