众所周知，如今Web应用早已被广泛应用各行行业的业务场景之中，反观桌面应用越来越少了或轻量化啦。Web应用的编程技术，起初开发静态网站到后来的动态网站，此时的静态网站也好，动态网站也好，都是服务端渲染（SSR，ServerSideRendering）实现的。
服务端渲染SSR编程技术框架，基本上是以ASP、JSP及PHP等为典型代表的。后来，随着业务场景发展越来越多、交互越来越频繁等需求推动下，动态网站应用肯定是大势所趋，但服务端渲染SSR的“无论页面的数据或大或小变化都要服务端存取一次整个页面而使得服务端性能瓶颈凸显”等弊端越来越阻碍业务发展。在此期间，横空出世出现过一个异步加载技术，即AJAX（AsynchronousJavascriptAndXML），用于缓解SSR的性能瓶颈弊端的方案是用AJAX技术实现“局部刷新页面内容”，而不是每次都整个页面刷新（即与服务器交互一次），但都前端开发的复杂度大大增加了。如果页面承载业务功能复杂的话，那么这个页面的前端代码的复杂度是可想而知的高。
再后来，以Angular、React、VUE等为典型代表的客户端渲染（CSR，ClientSideRendering）编程技术框架出现了，它彻底破解了SSR的性能瓶颈问题，但带来了新的问题，比如首屏加载速度慢，SEO（SearchEngineOptimization）不友好等问题。因此，虽然从SSR到CSR实现了跨越式发展的重要一步，但并表示CSR要取而代之SSR，答案是否定的。实际上，要根据实际业务需求来定采用谁更合适，比如中台或后台系统是推荐采用CSR机制的技术框架，而前台系统建议使用SSR机制的技术框架。
一、客户端渲染CSR
在说客户端渲染CSR之前，必然先得说说单页面应用SPA（SinglePageApplication）。Angular、React、VUE技术框架的核心就是一个SPA应用，整个应用只有一个HTML页面的应用，与后台服务器仅仅是数据上的交互，不会再请求其它HTML页面。故浏览器访问应用一开始会加载全部必需的HTML、CSS和JavaScript，所有的操作都在这个HTML页面上完成，后面的页面上互动动作与服务端数据交互都由JavaScript来控制。并且，这一个HTML页面上的“静态”内容（查看页面源码方式）是一样的，动态内容完全都在页面DOM中交互完成，故用户是直观看不到的。
故此，客户端渲染CSR有首屏加载速度慢和SEO（SearchEngineOptimization）不友好问题是劣势，其加载步骤，如下：
运行在客户端的JS，用户首次发送请求只能得到小部分的指引性HTML代码，譬如加载中的LOGO等内容。
第二次请求会加载全部必需的HTML、CSS和JavaScript，直至加载完成后才在客户端完成DOM渲染而看到整个页面。
用户在页面上做互动动作，只要不请求服务端数据的话，都完全在客户端完成，即用户交互速度快。
二、服务端渲染SSR
服务器端渲染SSR的核心优势在于首屏渲染速度块，简单来讲，它不需要来回多次往返于客户端和服务端加载交互。然而，其性能等众多因素会影响用户体验，比如说：网速，在线活跃人数，服务器的物理位置等等。这就很好解释在客户端渲染CSR普及流行之前需要网管的CDN（ContentDeliveryNetwork）加速支持原因所在，CDN机制比较适合静态网站加速，但不太适合动态网站加速，尤其复杂交互场景的动态网站。
客户端渲染CSR则与服务端渲染SSR刚好相反，多次和服务器的交互导致首屏加载速度慢，但一旦这些请求完成之后，用户和页面之间的交互时体验就会好很多，比较适合前端交互多的业务场景系统。
服务器端渲染SSR机制，就是将一个完整的HTML页面内容发送给客户端浏览器，客户端只负责HTML的解析。只不过它会被网速等等客观因素所约束造成用户体验不佳的情况。如果面临客户端和服务器多次交互且频繁的情况就显得非常的吃亏，即使在页面只是有稍加改动一点点的地方都需要重新请求到一个完整页面并且重新进行渲染。假设使用AJAX局部刷新机制的话，必然导致开发复杂度一下子提高了。因此，在SSR机制下，虽然首屏加载速度快，但期间页面加载不出来或卡顿现象出现的概率比较大，而且不用地方的用户访问顺畅情况也不一定，因客户端与服务器之间的网络路径有关。
简而言之，两者的核心区别，就是页面完整HTML字符串拼接是放在服务端还是在客户端来完成的。此外，从另外一个视角来看，SSR强在首屏渲染速度快，而CSR强在客户端交互体验多的用户场景。还有，SSR强在SEO友好，而CSR强在数据安全性等。总之，这两者各有千秋、各有优势，芝麻和豆子都重要，主要看用途场景。芝麻和豆子都可以榨油，豆子还可以做豆腐等豆制品，芝麻可以做芝麻丸、月饼等。
*技术营销人（祝融）写于码书网，百家号原创首转发。
联系电话：