原文链接

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 应用程序。正确的抉择可能会缩小您未来的代码管理工作。

更多 Jerry 的原创文章，尽在：” 汪子熙 ”: