CSR、SSR 或 SSG——为 React 应用选择最佳渲染策略
CSR、SSR 或 SSG——为 React 应用选择最佳渲染策略
CSR vs SSR vs SSG for React apps
在每个新的 React 项目开始时，一个问题不可避免地浮出水面——我们应该使用客户端渲染 (CSR)、服务器端渲染 (SSR) 还是生成静态站点 (SSG)。这是一个战略决策，取决于几个关键因素。
但首先，快速回顾一下！
客户端渲染
从本质上讲，CSR 只是意味着我们正在使用 Javascript 在浏览器中呈现我们应用程序的内容。想象一个标准的单页 React 应用程序构建[ 创建反应应用](https://reactjs.org/docs/create-a-new-react-app.html) 或类似的工具。当我们执行构建脚本时，我们可以期望在我们的 建造 文件夹（除其他外）是一个相对的准系统 索引.html 文件与我们的 Javascript 包一起（可能分成块）。
每当有人在他们的浏览器中访问我们的应用程序时，他们将只能看到（几乎是空的）的内容 索引.html 文件，直到下载并执行必要的 Javascript。之后，用户将能够查看我们应用程序的内容并与之交互。
此时，如果需要，可以从服务器获取附加数据并由应用程序显示。
静态站点生成
相比之下，当我们创建一个静态站点时，我们需要预先提供应用程序的所有内容和数据。原因是使用 SSG 意味着我们已经在构建步骤中生成了完整的 HTML 文件。
我们通过这种方法获得的好处是，用户无需等待任何 Javascript 下载并执行即可看到页面上的初始内容。另一方面，预先需要所有数据也意味着每当需要更改时，我们必须重新创建和重新部署整个构建。如果需要频繁更新，这很快就会变得很麻烦。
尽管如此，静态网站仍然是一个很好的工具。和像这样的框架 盖茨比 和 NextJS 使在 React 中创建它们变得越来越容易。
服务器端渲染
最后，服务器端渲染意味着我们使用服务器来渲染 HTML 文件的内容，并在请求时将它们提供给客户端。与 SSG 一样，用户无需等待 Javascript 下载并执行，即可开始查看页面。
一个重要的区别是，我们能够动态确定提供给客户端的内容，而不是已经生成静态文件。无需重建。权衡的是，我们获得的灵活性是以增加服务器为代价的，而且与其他选项相比，很可能增加了一些复杂性。
幸运的是，像 NextJS 做好使用 SSR 简化 React 应用程序开发的工作。
决策时间
现在我们对我们的选项有了基本的了解，让我们仔细看看我们如何在它们之间进行选择。
搜索引擎优化
SEO的重要性是一个关键考虑因素。如前所述，使用 CSR，初始 HTML 文件非常小，需要 Javascript 来呈现应用程序。这也意味着，在出现有意义的内容之前，使用 CSR 的初始加载时间会比使用替代方案的时间长。这对 SEO 不利。
相比之下，对于 SSR 和 SSG，初始 HTML 文件已经包含有意义的内容。这使得它们很容易被搜索引擎抓取和索引。此外，例如，在社交平台上共享链接时创建特定于页面的链接预览对于 SSR 和 SSG 来说是微不足道的，而对于 CSR 则完全不可能（除非我们使用像 预渲染.io 生成它们）。
SEO总是必须的吗？并非每个应用程序都需要进行搜索引擎优化。例如，如果整个应用程序都在登录之后，则 SEO 可能不相关。在这种情况下，无论如何只有登录用户才能访问内容，因此缺乏 SEO 并不是一个大问题。
动态内容
要考虑的第二个重要因素是我们正在构建的网站内容的动态性。 SSG 方法的主要缺点之一是，为了更新应用程序的内容，我们需要重新构建它。如果应用程序主要包含静态内容并且不经常更新，这可能会非常好。例如，SSG 的一个很好的用例是个人博客或营销网站。
然而，在许多情况下，我们的应用程序需要比这更具动态性。考虑一个仪表板应用程序，它需要为每个用户显示最新的个性化数据。尝试静态生成它是不切实际的。在这种情况下，选择 CSR 是一个更好的选择。有了它，我们可以在客户端获取特定用户的必要数据，显示并无缝更新。
这是另一种情况。如果我们正在建立一个新闻网站，内容既公开又不断更新。此外，如果还涉及一些用户生成的内容，例如文章下方的评论，该怎么办？再一次，SSG 在这种情况下并不理想。相反，最好利用 SSR，因为它能够提供动态的、非陈旧的、搜索引擎优化的 HTML 文件，并且可以轻松地根据每个请求反映更新。
⌛ 初始加载时间
初始加载时间可能是一个重要的 UX 考虑因素，特别是如果我们的用户处于互联网连接速度较慢的地方，或者我们希望该应用程序可以在（相对）旧设备上使用。使用 SSG 和 SSR，我们能够在屏幕上显示初始的有意义的 HTML。即使用户不能立即与之交互（我们需要 Javascript），但人们认为应用程序加载速度很快。值得注意的是，使用 CDN，静态生成的站点可能会比 SSR 执行得更好，因为内容已经生成和缓存。但是，我们也冒着它在请求时过时的风险。
另一方面，使用 CSR 意味着用户看到的只是空的 HTML 文件（或充其量是加载屏幕），直到必要的 Javascript 被下载、执行并能够呈现应用程序的内容。这可能会给用户留下应用程序太慢的初步印象。
基础设施
最后，重要的是要考虑我们构建和部署 React 应用程序的方式以及这可能带来的额外复杂性或成本。最简单的部署方法可能是我们的应用程序构建包含静态文件。这意味着我们可以直接将其部署在 CDN 服务上，并且我们的网站将上线。对于 CSR 和 SSG，情况正是如此。
使用 SSR，基础设施设置更加复杂。使用这种范例意味着我们需要一个服务器在每次请求时将页面预渲染为 HTML。即使服务喜欢 韦尔塞尔 使 NextJS 应用程序的部署几乎无缝，重要的是要记住，随着我们应用程序用户数量的增加，基础设施成本可能会随之增加。
结论
这是我们迄今为止讨论的内容的快速摘要。
那么我们应该选择哪种方法呢？像往常一样，没有一种适合所有解决方案的尺寸。选择应始终由我们的特定用例决定。
还可以为我们应用程序的不同部分混合和匹配这些方法。如果你想尝试组合它们，NextJS 是 特别灵活 在这方面。
快乐编码！ ✨
版权声明：本文为博主原创文章，遵循 CC 4.0 BY-SA 版权协议，转载请附上原文出处链接和本声明
