图1：Web运用
做事端渲染SSR编程技能框架，基本上因此ASP、JSP及PHP等为范例代表的。后来，随着业务场景发展越来越多、交互越来越频繁等需求推动下，动态网站运用肯定是大势所趋，但做事端渲染SSR的“无论页面的数据或大或小变革都要做事端存取一次全体页面而使得做事端性能瓶颈凸显”等弊端越来越阻碍业务发展。在此期间，横空出世涌现过一个异步加载技能，即AJAX（Asynchronous Javascript And XML），用于缓解SSR的性能瓶颈弊端的方案是用AJAX技能实现“局部刷新页面内容”，而不是每次都全体页面刷新（即与做事器交互一次），但都前端开拓的繁芜度大大增加了。如果页面承载业务功能繁芜的话，那么这个页面的前端代码的繁芜度是可想而知的高。
再后来，以Angular、React、VUE等为范例代表的客户端渲染（CSR，Client Side Rendering）编程技能框架涌现了，它彻底破解了SSR的性能瓶颈问题，但带来了新的问题，比如首屏加载速率慢，SEO（Search Engine Optimization）不友好等问题。因此，虽然从SSR到CSR实现了超过式发展的主要一步，但并表示CSR要取而代之SSR，答案是否定的。实际上，要根据实际业务需求来定采取谁更得当，比如中台或后台系统是推举采取CSR机制的技能框架，而前台系统建议利用SSR机制的技能框架。
一、客户端渲染CSR
在说客户端渲染CSR之前，一定先得说说单页面运用SPA（Single Page Application）。Angular、React、VUE技能框架的核心便是一个SPA运用，全体运用只有一个HTML页面的运用，与后台做事器仅仅是数据上的交互，不会再要求其它HTML页面。故浏览器访问运用一开始会加载全部必需的HTML、CSS和JavaScript，所有的操作都在这个HTML页面上完成，后面的页面上互动动作与做事端数据交互都由JavaScript来掌握。并且，这一个HTML页面上的“静态”内容（查看页面源码办法）是一样的，动态内容完备都在页面DOM中交互完成，故用户是直不雅观看不到的。
图2：客户端渲染CSR
故此，客户端渲染CSR有首屏加载速率慢和SEO（Search Engine Optimization）不友好问题是劣势，其加载步骤，如下：
运行在客户真个JS，用户首次发送要求只能得到小部分的指引性HTML代码，譬如加载中的LOGO等内容。第二次要求会加载全部必需的HTML、CSS和JavaScript，直至加载完成后才在客户端完成DOM渲染而看到全体页面。用户在页面上做互动动作，只要不要求做事端数据的话，都完备在客户端完成，即用户交互速率快。二、做事端渲染SSR
做事器端渲染SSR的核心上风在于首屏渲染速率块，大略来讲，它不须要来回多次来回于客户端和做事端加载交互。然而，其性能等浩瀚成分会影响用户体验，比如说：网速，在线生动人数，做事器的物理位置等等。这就很好阐明在客户端渲染CSR遍及盛行之前须要网管的CDN（Content Delivery Network）加速支持缘故原由所在，CDN机制比较适宜静态网站加速，但不太适宜动态网站加速，尤其繁芜交互场景的动态网站。
图3：做事端SSR渲染
客户端渲染CSR则与做事端渲染SSR刚好相反，多次和做事器的交互导致首屏加载速率慢，但一旦这些要求完成之后，用户和页面之间的交互时体验就会好很多，比较适宜前端交互多的业务场景系统。
做事器端渲染SSR机制，便是将一个完全的HTML页面内容发送给客户端浏览器，客户端只卖力HTML的解析。只不过它会被网速等等客不雅观成分所约束造成用户体验不佳的情形。如果面临客户端和做事器多次交互且频繁的情形就显得非常的亏损，纵然在页面只是有稍加改动一点点的地方都须要重新要求到一个完全页面并且重新进行渲染。假设利用AJAX局部刷新机制的话，一定导致开拓繁芜度一下子提高了。因此，在SSR机制下，虽然首屏加载速率快，但期间页面加载不出来或卡顿征象涌现的概率比较大，而且不用地方的用户访问顺畅情形也不一定，因客户端与做事器之间的网络路径有关。
简而言之，两者的核心差异，便是页面完全HTML字符串拼接是放在做事端还是在客户端来完成的。此外，从其余一个视角来看，SSR强在首屏渲染速率快，而CSR强在客户端交互体验多的用户场景。还有，SSR强在SEO友好，而CSR强在数据安全性等。总之，这两者各有千秋、各有上风，芝麻和豆子都主要，紧张看用场场景。芝麻和豆子都可以榨油，豆子还可以做豆腐等豆制品，芝麻可以做芝麻丸、月饼等。
