ssr的意思是服务端渲染，前端还没有流行的时候，之前的网站是在服务端拼接HTML字符串，将其返回呈现在页面

vue ssr主要是解决以下两个问题：

1.seo
SEO和爬虫都是根据url返回的数据来进行的，所以我们需要用户请求url的时候，返回的是有数据填充的的页面，spa应用查看网页源代码，也就是爬虫seo获取的数据，是一个没有数据的壳子

2.首屏渲染
像vue这样的单页面应用，首屏渲染是单页面spa的通病，打包出来的dist过大，会导致首屏加载缓慢

vue ssr优点：
vue ssr做的是在页面中请求url的时候，会从服务端渲染返回一个渲染好的html字符串，将首屏所需要的数据异步请求，填充发到前端展示，而不是发一个壳子，ssr是一份代码运行在两个环境里面（服务端、客户端），服务端先运行好之后，把模板渲染成html页面，然后返回给前端，前端再载入js文件，完成激活，后续的操作就是spa了，这样第一个页面是服务端渲染的带数据的，seo爬虫就能获取到数据，同时因为首屏只渲染一个页面，后续激活spa是发生在浏览器端，首屏渲染问题也得到解决。

vue ssr缺点：
在配置过程中比较复杂，需要配置两个入口文件，一个是服务端首屏渲染所需要的，第二个是前端激活所需要的，有nuxt.js可以更容易实现ssr

相比于单纯的spa，服务端渲染加重了服务器的负担，当用户量多的时候，因为需要在后端创建全新的vue实例，所以比单纯请求数据浪费性能。
虽然 Vue 的服务器端渲染(SSR)相当快速，但是由于创建组件实例和虚拟 DOM 节点的开销，无法与纯基于字符串拼接的模板的性能相当。在 SSR 性能至关重要的情况下，明智地利用缓存策略，可以极大改善响应时间并减少服务器负载，对组件页面接口进行缓存。

前后端同构，在后端就需要写前端vue的代码，与前后端分离相违背，这个可以通过webpack打包实现，只需要配置入口文件以及相应的逻辑就可以。

缓存和运维的问题。

应用场景：
并不是所有的网站都需要SEO，比如企业内部网站，后天管理系统等。
一些vue老项目，重构成本太大，首屏渲染可以通过路由懒加载，按需加载的方式，修改对应的问题，不全盘扳倒重写。
在服务器返回结果之前，可以做处理判断是否是爬虫，来决定进行预渲染