原文链接
The Web Page Rendering Dilemma
关于网页渲染的讨论是最近几年才出现的。早些时候，网站和网络应用程序有一个共同的策略要遵循。他们准备了要发送到服务器端浏览器的 HTML 内容；然后在浏览器中将该内容呈现为带有 CSS 样式的 HTML。
JavaScript 框架采用了一种完全不同的 Web 开发方法。 JavaScript 框架带来了减轻服务器负担的可能性。
借助 JavaScript 框架的强大功能，可以通过仅请求所需的内容来直接从浏览器呈现动态内容。在这种情况下，服务器只提供必要的基本 HTML 包装器。这种转换为访问者提供了无缝的用户体验，因为加载网页所需的时间很少。此外，一旦加载，网页就不会再次重新加载。
在本文中，我们将讨论这些技术上不同的网页渲染方法。 我将解释每种方法之间的主要区别，并为您建议一种方法。
服务器端渲染
服务器端渲染或 SSR 是在浏览器上渲染网页的传统方式。 如上所述，呈现动态网页内容的传统方式遵循以下步骤：
用户向网站发送请求（通常通过浏览器）
服务器在遍历页面内的服务器端脚本后检查资源、编译和准备 HTML 内容。
这个编译后的 HTML 被发送到客户端的浏览器以进行进一步的渲染和显示。
浏览器下载 HTML 并使网站对最终用户可见
浏览器然后下载 Javascript (JS) 并在执行 JS 时使页面具有交互性
注意，在服务器端渲染的第二个步骤，客户可以浏览从服务器发送过来的静态页面，但是无法互动，因为 JavaScript 尚未下载到客户端。
在这个过程中，获取动态内容、将其转换为 HTML 并将其发送到浏览器的所有负担都在服务器上。 因此，此过程称为服务器端渲染 (SSR)。提前渲染完整 HTML 的责任伴随着服务器的内存和处理能力的负担。 与没有动态内容要呈现的静态站点的页面加载时间相比，这会增加页面加载时间。
客户端渲染
客户端呈现或 CSR 是处理网页以在浏览器中显示的不同方法。在 CSR 中，编译动态内容并为它们生成 HTML 的负担转移到客户端的浏览器。
这种方法由 JavaScript 框架和 ReactJS、VueJS 和 Angular 等库提供支持。 客户端渲染场景的正常网页渲染流程遵循以下步骤：
用户向网站发送请求（通常通过浏览器）。
可以使用 CDN（内容交付网络）代替服务器来为用户提供静态 HTML、CSS 和支持文件。
浏览器先下载 HTML，然后再下载 JS。 同时，用户会看到一个加载符号。
浏览器获取 JS 后，通过 AJAX 发出 API 请求以获取动态内容并对其进行处理以呈现最终内容。
服务器响应后，在客户端浏览器中使用 DOM 处理呈现最终内容。
在 CSR 渲染的第三步，用户只能看到一个空白的屏幕。
由于此过程涉及在客户端获取和处理数据，因此该过程称为客户端渲染。
两种渲染模式的对比
由于这两种方法处理内容的方式不同，因此每种方法都有其优点。让我们从用户和 Web 的角度比较 CSR 与 SSR。
web page 加载时间
网页加载时间是从请求被发送到服务器到它在浏览器上呈现之间所花费的时间。 当涉及到您的网站或 Web 应用程序的用户体验 (UX) 时，这是一个重要方面。 CSR 和 SSR 的网页加载时间在两种情况下是不同的：
首页加载时间
第一页加载时间是用户第一次加载您的网站所用的平均时间。 在首次加载时，在 CSR 中，浏览器一次加载基本 HTML、CSS 和所有所需的脚本，然后将 HTML 编译为浏览器上可用的内容。
这一次通常不仅仅是从服务器获取预编译的 HTML 和相应的脚本。因此，当涉及到第一页加载时间时，SSR 通常需要更少的时间。
接下来页面的加载时间
第二个页面加载时间是从一个页面导航到另一个页面所花费的平均时间。 在这种情况下，由于 CSR 的所有支持脚本都是提前加载的，因此 CSR 的加载时间更快。 除非需要加载惰性 JavaScript 模块，否则它不会向服务器发送请求。
但是，对于 SSR，在第一页加载中遵循的完整请求周期是重复的。 这意味着 SSR 对网页加载时间几乎没有任何影响。 因此，在这种情况下，CSR 响应更快。
这里需要注意的是，上述推论并未深入考虑网络方面。 我们相信客户端和服务器在网络上具有相当的带宽。
对缓存的影响
为了加速繁重的 web 应用程序，每个浏览器和 web 服务器都采用缓存机制来缓存客户端机器上的可重用脚本。 这改善了 CSR 和 SSR 的加载时间。 然而，CSR 有一个主要的好处。
在 CSR 中，只要不需要延迟加载模块，基于 CSR 的 Web 应用程序也可以在没有互联网的情况下运行（除非您调用数据 API）。 加载后，应用程序不再需要向服务器发送请求。这允许浏览 Web 应用程序，就像一个简单的桌面应用程序。
然而，在 SSR 中，总是向服务器发送请求。 因此，与 CSR 相比，SSR 的页面加载时间无疑更长。缓存确实提高了 SSR 的内容渲染速度，因为浏览器需要从缓存中检索必要的脚本。下图描述了浏览器如何处理对缓存脚本的重复请求：
请注意，大多数脚本是从内存或磁盘加载的。 这大大缩短了加载时间并防止了服务器上的过度负载。
如何选择合适的渲染方案
Dynamic Content Loading
服务器通常驻留在具有更高计算能力和显着更高网络速度的机器上。 凭借这种速度和能力，它在处理预期数量的处理请求时永远不会耗尽资源。 结果，在服务器上获取内容变得相对更快。
另一方面，客户端计算机的计算能力有限，在客户端获取和呈现动态内容可能需要更长的时间。 这意味着获取呈现的内容所消耗的总时间会更长。 因此，如果您的网站涉及重复的动态内容呈现，SSR 是比 CSR 更好的选择。
Web Application UX vs Website UX
尽管它们看起来几乎相同，但 Web 应用程序和网站是两种不同的 Web 内容格式。 Web 应用程序是一个完整的应用程序，可用于会计、CRM、人力资源管理、项目管理等目的。另一方面，网站提供信息内容。
与网站相比，Web 应用程序涉及更多的用户交互。 在用户交互较高的场景中，确保用户交互不会花费很长时间是至关重要的。 因此，与 SSR 相比，CSR 更适用于 Web 应用程序。
另一方面，对于网站，如果每次点击都加载新网页，对于客户来说也能接受，因为缓存通常会负责加速渲染。 此外，SSR 还确保为爬虫提供正确的元数据——与 CSR 相比，这使得 SSR 更适合网站。
结论
CSR 和 SSR 对于您计划提供给用户的 UX 至关重要。 我希望本文能帮助您从功能和实用的角度理解这些概念。 最终的选择最终是你的。 考虑到上述因素，明智地选择。 错误的选择可能会让您重新开发整个网站或 Web 应用程序。 正确的选择可能会减少您将来的代码管理工作。
