一、CSR和SSR对比
在SPA之前的时代，我们传统的Web架构大都是SSR，如：Wordpress（PHP）、JSP技术、JavaWeb等这些程序都是传统典型的SSR架构，即：服务端取出数据和模板组合生成 html输出给前端，前端发生请求时，重新向服务端请求html资源。
SPA（CSR）:
SPA应用，到了Vue、React，单页面应用优秀的用户体验，逐渐成为了主流，页面整体是javaScript渲染出来的，称之为客户端渲染CSR。SPA渲染过程。由客户端访问URL发送请求到服务端，返回HTML结构（但是SPA的返回的HTML结构是非常的小的，只有一个基本的结构）。客户端接收到返回结果之后，在客户端开始渲染HTML，渲染时执行对应javaScript，最后渲染template，渲染完成之后，再次向服务端发送数据请求，注意这里时数据请求，服务端返回json格式数据。客户端接收数据，然后完成最终渲染。
CSR原理图
CSR多数是基于webpack构建的项目，编译出来的html文件，资源文件都被打包到js中，这样的页面是不利于搜索引擎优化(SEO, Search Engine Optimization)，并且内容到达时间(time-to-content) （或称之为首屏渲染时长）也有很大的优化空间
简单来讲，SPA虽然给服务器减轻了压力，也存在比较明显的两个缺点：
首屏渲染时间比较长：必须等待JavaScript加载完毕，并且执行完毕，才能渲染出首屏。
SEO不友好：爬虫只能拿到一个div元素，认为页面是空的，不利于SEO。
什么是SEO呢？SEO即通过各种技术（手段）来确保，你的Web内容被搜素引擎最大化收录，最大化提高权重，带来更多流量。大部分的搜索引擎仅能抓取URI直接输出的数据资源，对于 Ajax 类的异步请求的数据无法抓取
因此，对于那些展示宣传型页面，如官网，必须进行服务端渲染
SSR:
为了解决如上两个问题，出现了SSR解决方案，后端渲染出首屏的DOM结构返回，前端拿到内容带上首屏，后续的页面操作，再用单页面路由和渲染，称之为服务端渲染(SSR)。
SSR渲染流程是这样的，客户端发送URL请求到服务端，在服务端做出html和数据的渲染，渲染完成之后返回html结构，客户端拿到页面的html结构渲染首屏。所以用户在浏览首屏的时候速度会很快，因为客户端不需要再次发送ajax请求。并不是做了SSR我们的页面就不属于SPA应用了，它仍然是一个独立的spa应用。
SSR原理图
SSR是处于CSR与SPA应用之间的一个折中的方案，在渲染首屏的时候在服务端做出了渲染，注意仅仅是首屏，其他页面还是需要在客户端渲染的，在服务端接收到请求之后并且渲染出首屏页面，会携带着剩余的路由信息预留给客户端去渲染其他路由的页面。
vueSSR
将本来要放在浏览器执行创建的组件，放到服务端先创建好，然后生成对应的html将它们直接发送到浏览器，最后将这些静态标记"激活"为客户端上完全可交互的应用程序。
在浏览器第一次访问某个URI资源的时候（首屏），Web服务器根据路由拿到对应数据渲染并输出，且输出的数据中包含两部分：
路由页对应的页面及已渲染好的数据
完整的SPA程序代码
在首屏渲染完成之后，此时我们看到的其实已经是一个和之前的SPA相差无几的应用程序了，接下来我们进行的任何操作都只是客户端的应用进行交互，页面/组件由Web端渲染，路由也由浏览器控制，用户只需要和当前浏览器内的应用打交道就可以了。
vueSSR原理图
webpack将 Source 打包出两个bundle文件：其中 Server Bundle用于服务端渲染，服务端通过渲染器 bundleRenderer 将 bundle 生成首屏html片段；而 Client Bundle 用于客户端渲染，首屏外的交互和数据处理还是需要浏览器执行 Client Bundle 来完成
缺点：
开发条件所限。浏览器特定的代码，只能在某些生命周期钩子函数(lifecycle hook)中使用；一些外部扩展库(external library)可能需要特殊处理，才能在服务器渲染应用程序中运行。