预渲染和SSR你会选择哪一个？为什么？

预渲染（Prerendering）

简述
用户请求前的服务器渲染；
核心：prerender-spa-plugin
构建阶段生成匹配预渲染路径的html文件（注意：每个需要预渲染的路由都有一个对应的html）
无需服务器实时动态编译，采用预渲染，在构建时针对特定路由简单的生成静态html文件；
优点

• 更好的SEO，更快的内容到达时间；
• 无需更改代码或添加服务器端
• 加载应用程序的路由，将结果保存在一个静态的html中
  缺点
• 不适用于渲染路由过多（不建议预渲染非常多的路由，因为这会严重拖慢你的构建进程）和动态路由（例如：/detail/参数，因为页面内容依据看它的参数而显得不同），只适用于几个简单的固定路由的场景；
• 若网站有过多的路由，预编译会非常慢，虽每次更新只需要一次但会需要更长的时间；
  适用场景
  只需改善少数页面的SEO，可以采用预渲染。

服务端渲染（SSR，Server Side Rendering）

简述
用户请求后的服务器渲染；
又称为后端渲染，服务器端在返回html前，在html特定的区域特定的符号里用数据填充，在返回给客户端，客户端只负责解析html；
在服务器上运行页面逻辑和呈现可以避免向客户端发送大量JavaScript，这有助于实现快速的交互时间（TTI）；
流程
浏览器-->服务器-->服务器执行渲染--> index.html（实时渲染的内容）-->Render--> bundle.js+images-->Render
优点

• 内容立即使用——因为将HTML发送给客户端，所以几乎会立即看到页面内容（前端耗时少，首次渲染快，更快的内容到达时间）；
• 无需获取其他客户端——理想情况下，服务器呈现过程将进行所有必需的调用以获取数据，因此不会从客户端进行任何其他服务调用；
• 非常适合SEO；
  缺点
• 服务器上的速度较慢——需要渲染两次页面：一次在服务器上，一次是在客户端上。同时也可能正在从服务器进行服务调用以呈现页面，所有这些都需要时间，因此可能会延迟HTML向客户端的初始发送（网络传输数据量大，占用部分服务器运算资源，用户体验差）；
• 库的支持性，代码兼容——与某些UI不兼容，如果你用的某些库中使用了window，那就需要自己想办法解决了，因为Node（服务端）中没有window或者document；
• 复杂度高——不容易维护，前端修改的部分html/css后端也要改；
• 服务器负载变大——相对于前后端分离，服务器只需要提供静态资源来说，服务器负载更大，所以要谨慎使用（比如一整套图表页面，相对于服务端渲染，可能用户不会在乎初始加载的前几秒，可以交由客户端使用类似于骨架屏，或者懒加载之类的提升用户体验）；
• 性能问题——每个请求都是n个实例的创建，不然会污染，消耗会变的很大；
  缓存node serve、nginx判断当前用户有没有过期，如果没过期的话就缓存，用刚刚的结果；
  降级：监控cpu、内存占用过多，就spa，返回单个的壳；
  适用场景
  1、需要更在乎SEO排名，对首屏速度要求较高的（当企业更在乎在搜索引擎的排名，使得用户尽可能看到与多访问自身网站时，可以考虑使用SSR【根据业务决定首屏加载速度的重要程度】）；
  2、已经存在的项目，改造起来工程量比较大
  考虑爬虫工具，比如puppeteer，让它直接从spa项目中爬出结果；
  判断当前的请求是不是爬虫，浏览器引擎；如果是内部用户的话直接把spa给它；
  3、全新的项目：用框架级别的例如：nuxt.js

SPA（单页面应用，single page application）

简述
是一种特殊的web应用，是加载单核HTML页面并在用户与应用程序交互时动态更新该页面，它讲所有的活动局限于一个web页面当中，仅在该web页面初始化时加载相应的HTML、JavaScript、CSS，一旦页面加载完成，SPA不会因为用户的操作而进行页面的重新加载或跳转，而是利用JavaScript动态变换HTML（采用的是div切换显示和隐藏）从而实现UI与用户的交互。在SPA应用中，应用加载之后不会再有整页刷新。相反，展示逻辑预先加载，并有依赖于内容Region（区域）中的视图切换来展示内容；
MVVM：经典的MVVM开发模式，前后端各负其责；
ajax：重前端，业务逻辑再本地操作，数据通过ajax同步提交；
流程： 浏览器 --> 服务器 --> index.html(白屏)--> bundle.js --> images--> render
优点

• 减轻服务器压力——服务器只用出数据就可以，不用管展示逻辑和页面合成，吞吐能力会提高几倍；
• 良好的交互体验——能提升页面切换体验，用户在访问应用页面是不会频繁地去切换浏览器页面的，从而避免了页面的重新加载；
• 前后端分离开发——单页web应用可以和RESTful一起使用，通过REST API提供接口数据，并使用ajax异步获取，这样有利于分离客户端和服务器端工作。更进一步，可以在客户端也分解为静态页面和页面交互两个部分；
• 共用一套后端程序代码——不用修改后端程序代码就可以同时用于web界面、手机端、平板等多种客户端；
  缺点
• SEO难度较高——由于所有的内容都在一个页面中动态替换显示，所以在SEO上其有天然的若是，所以如果你的站点对SEO很看中，且要用单页应用，name就做些静态页面给搜索引擎用吧；
• 初次加载耗时多——为实现单页web应用功能及显示效果，需要在加载页面的时候讲JavaScript、Css统一加载，部分页面可以在需要的时候加载。所以必须多JavaScript及CSS代码进行合并压缩处理；
• 前进、后退管理—— 由于单页web应用在一个页面中显示所有的内容，所以不能使用浏览器的前进后退功能，所有的页面切换需要自己建立堆栈管理，当然此问题也有解决方案，比如利用URI中的散列+iframe实现；
  适用场景
  对于有很多页面交互，并且对SEO需求不是很大的项目；

参考资料：
https://segmentfault.com/a/1190000023469150?utm_source=tag-newest
https://www.jianshu.com/p/e9eda98b9fc9