客户端渲染与服务器端渲染：何时选择哪个？

网页渲染困境

客户端渲染 (CSR) 与服务器端渲染 (SSR) - 比较

选择适合自己的道路

网页渲染困境

关于网页渲染的讨论直到最近几年才开始出现。之前，网站和 Web 应用程序遵循一个共同的策略。它们在服务器端准备要发送到浏览器的 HTML 内容；然后在浏览器上将这些内容渲染为带有基于 CSS 样式的 HTML。

随着 JavaScript 框架的出现，Web 开发迎来了一种完全不同的方式。JavaScript 框架带来了减轻服务器负担的可能性。

借助 JavaScript 框架的强大功能，只需请求所需内容，即可直接从浏览器呈现动态内容。在这种情况下，服务器仅提供必要的基本 HTML 包装器。这种转换为访问者提供了无缝的用户体验，因为加载网页所需的时间非常短。此外，网页一旦加载，便不会再次重新加载。

在本文中，我们将讨论这些技术上不同的网页渲染方法。我将解释每种方法之间的主要区别，并为您推荐一种方案。

服务器端渲染

服务器端渲染（SSR）是在浏览器上渲染网页的常规方式。如上所述，渲染动态 Web 内容的传统方法遵循以下步骤：

1. 用户向网站发送请求（通常通过浏览器）

2. 服务器检查资源，遍历页面内的服务器端脚本后编译并准备 HTML 内容。

3. 编译后的 HTML 被发送到客户端的浏览器进行进一步渲染和显示。

4. 浏览器下载 HTML 并使网站对最终用户可见

5. 然后，浏览器下载 Javascript（JS），并在执行 JS 时使页面具有交互性

在这个过程中，获取动态内容、将其转换为 HTML 并发送到浏览器的所有负担都留在服务器上。因此，这个过程被称为服务器端渲染（SSR）。

提前渲染完整 HTML 的责任会给服务器的内存和处理能力带来负担。与没有动态内容需要渲染的静态网站的页面加载时间相比，这会增加页面加载时间。

客户端渲染

客户端渲染（CSR）是一种与网页在浏览器上显示处理方式不同的方法。在 CSR 中，编译动态内容并生成 HTML 的负担被转移到客户端浏览器。

这种方法由 JavaScript 框架和库（例如 ReactJS、VueJS 和 Angular）提供支持。客户端渲染场景的网页渲染流程通常遵循以下步骤：

1. 用户向网站发送请求（通常通过浏览器）

2. 可以使用 CDN（内容分发网络）代替服务器向用户提供静态 HTML、CSS 和支持文件

3. 浏览器下载 HTML，然后下载 JS，同时用户看到加载符号

4. 浏览器获取 JS 后，通过 AJAX 发出 API 请求来获取动态内容并进行处理以呈现最终内容

5. 服务器响应后，在客户端浏览器上使用 DOM 处理来呈现最终内容

由于该过程涉及在客户端获取和处理数据，因此该过程称为客户端渲染。

客户端渲染 (CSR) 与服务器端渲染 (SSR) - 比较

由于两种方法在内容处理方式上有所不同，因此每种方法都有其优势。让我们从用户和 Web 的角度比较一下 CSR 和 SSR。

网页加载时间

网页加载时间是指请求发送到服务器到在浏览器上呈现所需的时间。这对于网站或 Web 应用程序的用户体验 (UX)至关重要。CSR 与 SSR 的网页加载时间在两种情况下有所不同：

首页加载时间

首页加载时间是指用户首次加载您的网站所需的平均时间。在首次加载时，在 CSR 中，浏览器会一次性加载基础 HTML、CSS 和所有必需的脚本，然后将 HTML 编译为浏览器可用的内容。

这个时间通常比从服务器获取预编译的 HTML 和相应的脚本要长。因此，SSR 在首次页面加载时间方面通常花费的时间更少。

第二次及以后的页面加载时间

第二页加载时间是指从一个页面导航到另一个页面的平均时间。在这种情况下，由于所有支持脚本都已预先加载，因此 CSR 的加载时间更短（从而性能更佳）。除非需要加载惰性模块 JavaScript，否则它不会向服务器发送请求。

然而，对于 SSR 来说，首页加载过程中的完整请求周期会被重复。这意味着 SSR 对网页加载时间几乎没有任何影响。因此，在这种情况下，CSR 的响应速度更快。

这里需要注意的是，上述推论没有深入考虑网络方面。我们认为客户端和服务器在网络上具有相当的带宽。

缓存的影响

缓存已成为当今的必需品。为了加速大型 Web 应用程序，每个浏览器以及 Web 服务器都采用缓存机制，将可重用的脚本缓存在客户端计算机上。这不仅能提升 CSR 和 SSR 的整体加载时间，还能显著缩短服务器端渲染 (SSR) 的加载时间。然而，CSR 还有一个主要优势。

在 CSR 中，只要不需要延迟模块加载，基于 CSR 的 Web应用程序实际上也可以在没有互联网的情况下运行！（除非你调用 API 获取数据）。一旦加载完成，应用程序就不再需要向服务器发送请求。这使得 Web 应用程序可以像简单的桌面应用程序一样进行导航。

然而，在 SSR 中，请求始终会发送到服务器。因此，SSR 的页面加载时间无疑比 CSR 更长。即使对于 SSR，缓存也能提高内容渲染速度，因为浏览器会从缓存中检索脚本。下图展示了浏览器如何处理对缓存脚本的重复请求。

请注意，大多数脚本都是从内存或磁盘缓存加载的。这大大缩短了加载时间，并防止了服务器负载过重。

对SEO的影响

对于商业网站来说，针对搜索引擎进行优化至关重要。搜索引擎使用称为爬虫的自动化机器人来读取和理解您的网站。这些爬虫对您网站的元数据比实际内容更感兴趣。因此，您的网页必须反映搜索引擎所需的正确元数据。

使用CSR，网页内容使用 JavaScript 动态生成。这意味着从一个页面到另一个页面的元数据更改依赖于 JavaScript 的执行。过去，搜索引擎倾向于在爬虫程序爬行网站时不运行 JavaScript。然而，随着 Google 接受运行 JavaScript，这种趋势正在改变。

使用 CSR，您需要利用并付出额外的努力来确保页面元数据在不同页面之间保持一致。这需要使用 ReactJS 的插件（例如React Helmet），以及 Angular 框架的库模块（例如 @angular/browser 库中的 Meta）。您需要付出额外的努力来设置每个页面的元数据并将其渲染到客户端。

使用 SSR，完整的页面将使用正确的元数据进行编译，并且仅在获取最终 HTML 内容后才发送到前端。这确保了无论爬虫是否允许使用 JavaScript，页面元数据始终准确无误。这使得SSR 成为搜索引擎优化页面的更佳解决方案。

选择适合自己的道路

更少的选择总是最简单的。传统上，你只有一个选择——SSR。随着 CSR 的出现，一个问题出现了：哪一个才是适合你的应用程序或网站的？让我们来了解一下它们各自的优势。

动态内容加载

服务器通常驻留在具有更高计算能力和更高网络速度的机器上。凭借这种速度和能力，它在处理预期数量的请求时永远不会耗尽电量。因此，服务器前端的内容获取速度相对较快。

另一方面，客户端计算机的计算能力有限，可能需要更长的时间才能在客户端获取和渲染动态内容。这意味着渲染内容所需的总时间会更长。因此，如果您的网站涉及重复的动态内容渲染，那么 SSR 是比 CSR 更好的选择。

Web 应用程序用户体验 vs 网站用户体验

虽然 Web 应用程序和网站看起来几乎相同，但它们是两种不同的 Web 内容格式。Web 应用程序是一个完整的应用程序，可用于会计、CRM、人力资源管理、项目管理等用途。而网站则包含有关业务的信息内容。

与网站相比，Web 应用程序涉及更多的用户交互，因为用户在 Web 应用程序中执行数据输入并生成报告。在用户交互较多的场景中，确保点击时间短至关重要。因此，与 SSR 相比，CSR 更适合 Web 应用程序。

另一方面，对于网站来说，如果每次点击都能加载新的网页，客户就放心了，因为缓存通常会加快渲染速度。此外，SSR 还能确保爬虫获取正确的元数据——这使得SSR 比 CSR 更适合网站。

两全其美

看完以上内容后，你可能会想，有没有办法既能兼顾 SSR 快速的首次加载速度和更好的 SEO 性能，又能获得 CSR 近乎原生的体验。你很幸运！——有些框架可以采用混合方式，比如Gatsby。

它的本质是，虽然首页始终使用 SSR 加载，但它会在加载完成后缓存其他页面，以便其余页面进行预渲染和缓存，让您感觉在后续页面上使用了 CSR 方法！查看我们的网站，它也是使用 Gatsby 构建的。

结论

CSR 和 SSR 对于您计划提供给用户的用户体验至关重要。我希望本文能帮助您从功能和实践的角度理解这些概念。最终的选择权在您手中。请根据以上因素做出明智的选择。错误的选择可能会导致您重新开发整个网站或 Web 应用程序。正确的选择也可能减少您将来的代码管理工作。