Web应用服务端渲染编程技术框架，Side实现的实现

图 1：Web 应用程序

服务器端渲染SSR编程技术框架基本以ASP、JSP、PHP为代表。 后来，随着业务场景越来越多，交互越来越频繁，动态网站应用绝对是大势所趋。 然而，服务器端渲染的SSR“无论页面数据变化大还是小，都必须存储在服务器上”。 一次性获取整个页面等弊端凸显了服务器端的性能瓶颈，越来越阻碍业务发展。 在此期间，出现了一种异步加载技术，即AJAX（和XML）。 缓解SSR性能瓶颈的解决方案是使用AJAX技术“部分刷新页面内容”，而不是每次都刷新整个页面。 刷新（即与服务器交互一次），但前端开发的复杂度大大增加。 如果该页面承载着复杂的业务功能，那么该页面前端代码的复杂度可想而知。

后来出现了以React、VUE等为代表的客户端渲染（CSR，Side）编程技术框架。 它彻底解决了SSR的性能瓶颈问题，但带来了新的问题，比如首屏加载速度。 速度慢，SEO()不友好等问题。 因此，虽然是从SSR到CSR跨越式发展的重要一步，但并不意味着CSR将取代SSR。 答案是不。 事实上，需要根据实际业务需求来决定哪一种更适合。 例如，中台或后端系统推荐使用CSR机制的技术框架，前端系统推荐使用SSR机制的技术框架。

1. 客户端渲染CSR

在讲CSR的客户端渲染之前，我们首先要讲一下单页面应用SPA（Page）。 React和VUE技术框架的核心是SPA应用。 整个应用程序只有一个HTML页面应用程序。 它只与后台服务器进行数据交互，不会请求其他HTML页面。 因此，当浏览器访问应用程序时，所有必需的HTML、CSS和HTML都会在开始时加载。 所有的操作都是在这个HTML页面上完成的，后续页面的交互动作和服务器端数据交互都由它来控制。 而且，这个HTML页面上的“静态”内容（查看页面源代码）是一样的，而动态内容完全是在页面DOM中交互的，所以对用户来说是不直接可见的。

图 2：客户端渲染 CSR

因此，CSR的客户端渲染存在首屏加载慢、SEO不友好等缺点（ ）。 加载步骤如下：

对于运行在客户端的JS，用户在第一次发送请求时只能得到一小部分指导性的HTML代码，比如加载LOGO等内容。 第二个请求将在客户端加载所有必需的 HTML、CSS 和 DOM 渲染，直到加载完成并且可以看到整个页面。 用户在页面交互时，只要不请求服务器端数据，都是在客户端完成，用户交互速度快。

2. 服务端渲染SSR

服务端渲染SSR的核心优势在于首屏渲染速度。 简单来说，它不需要客户端和服务器加载交互之间的多次往返。 但它的性能以及其他很多因素都会影响用户体验，比如：网速、在线活跃人数、服务器的物理位置等。这就解释了为什么在客户端之前需要网管的CDN（CDN）加速支持—— CSR侧面渲染开始流行。 CDN机制比较适合静态网站加速，但不适合动态网站加速，尤其是交互场景复杂的动态网站。

图3：服务器端SSR渲染

客户端渲染CSR与服务器端渲染SSR正好相反。 与服务器的多次交互导致首屏加载缓慢，但是一旦这些请求完成后，用户与页面的交互体验就会好很多，更适合前端。 一个交互较多的业务场景系统。

服务器端渲染SSR机制是将完整的HTML页面内容发送给客户端浏览器，客户端只负责解析HTML。 只是会受到网络速度等客观因素的制约，导致用户体验不佳。 如果面对客户端和服务器之间多次且频繁的交互，那将是非常不利的。 即使页面只做了轻微的修改，你也需要重新请求一个完整的页面并重新渲染它。 假设采用AJAX部分刷新机制，开发复杂度必然会增加。 因此，在SSR机制下，虽然首屏加载速度很快，但在此期间大概率会出现页面加载不出来或者卡死的情况，并且由于客户端之间的差距，不同地方的用户能否顺利访问并不确定和服务器。 与网络路径有关。

简而言之，两者的核心区别在于页面完整的HTML字符串拼接是在服务器端还是在客户端完成。 另外，从另一个角度来看，SSR强在首屏渲染速度快，而CSR强在客户端交互体验多的用户场景。 另外，SSR 的优势在于 SEO 友好性，而 CSR 的优势在于数据安全性。 总之，两者各有千秋，各有优势。 芝麻和豆子都很重要。 主要还是看使用场景。 芝麻和豆类都可以用来榨油。 豆类还可以用来制作豆腐和其他豆制品。 芝麻可用来制作芝麻球、月饼等。