原文链接
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 响应更快。
这里需要注意的是，上述推论并未深入考虑网络方面。 我们相信客户端和服务器在网络上具有相当的带宽。
对缓存的影响