服务端渲染SSR的理解
SSR服务端渲染Server Side Render就是当进行请求时，页面上的内容是通过服务端渲染生成的，浏览器直接显示服务端返回的HTML即可。
客户端渲染CSR
通常在构建一个普通的SPA单页应用时，就是构建的客户端渲染的应用，CSR客户端渲染Client Side Render就是当进行请求时，页面上的内容是通过加载的Js文件渲染出来的，Js文件动态运行在浏览器上面，服务端只返回一个HTML模板。
优点
- 使得服务器计算压力变轻。
- 做到了前后端分离，在团队开发中只要负责各自的任务即可，使开发效率有明显提升。
缺点
- 不利于
SEO、搜索引擎爬虫无法完整解析用户页面。 - 请求增多时用户等待时间变长，导致首屏渲染慢。
- 消耗的是用户浏览器的性能。
服务端渲染SSR
SSR服务端渲染Server Side Render就是当进行请求时，页面上的内容是通过服务端渲染生成的，浏览器直接显示服务端返回的HTML即可。对于传统服务端渲染，也称为后端模板渲染，如jsp或者php等，这是最早时期的web，是指客户端请求时，在服务器上使用模板引擎将模板与数据拼接成完整的HTML，再发送给客户端，客户端接收后直接解析HTML就可以在浏览器上展示出来，不需要额外的异步请求获取数据，如果要使web有交互性，客户端需要再用Js去操作DOM或者渲染其他动态的部分。
优点
- 更好的
SEO，由于搜索引擎爬虫抓取工具可以直接查看完全渲染的页面，如果SEO对站点至关重要，而页面又是异步获取内容，则可能需要服务器端渲染SSR解决此问题。 - 更快的内容到达时间
time-to-content，特别是对于缓慢的网络情况或运行缓慢的设备，无需等待所有的JavaScript都完成下载并执行，用户将会更快速地看到完整渲染的页面，通常可以产生更好的用户体验，并且对于那些内容到达时间time-to-content与转化率直接相关的应用程序而言，服务器端渲染SSR至关重要。
缺点
- 开发条件所限，浏览器特定的代码，只能在某些生命周期钩子函数
lifecycle hook中使用，一些外部扩展库external library可能需要特殊处理，才能在服务器渲染应用程序中运行。 - 涉及构建设置和部署的更多要求，与可以部署在任何静态文件服务器上的完全静态单页面应用程序
SPA不同，服务器渲染应用程序，通常需要处于Node.js server运行环境。 - 更大的服务器端负载，在
Node.js中渲染完整的应用程序，显然会比仅仅提供静态文件的server更加大量占用CPU资源CPU-intensive-CPU密集型，因此如果预料在高流量环境high traffic下使用，需要准备相应的服务器负载，并明智地采用缓存策略。
预渲染Prerendering
如果使用服务器端渲染SSR只是用来改善少数营销页面，例如/、/about、/contact等的SEO，那么你可能需要预渲染，无需使用web服务器实时动态编译HTML，而是使用预渲染方式，在构建时build time简单地生成针对特定路由的静态HTML文件。如果使用webpack，则可以使用prerender-spa-plugin轻松地添加预渲染。
优点
- 设置预渲染更简单，并可以将前端应用作为一个完全静态的站点。
缺点
- 只适合对于特定静态页面而应用。
总结
本质上对于渲染都是一样的，都是进行的字符串拼接生成HTML,两者的差别最终体现在时间消耗以及性能消耗上。客户端在不同网络环境下进行数据请求，客户端需要经历从Js加载完成到数据请求再到页面渲染这个时间段，导致了大量时间的消耗以及浏览器性能的消耗。而服务端在内网请求，数据响应快，不需要等待Js代码加载，可以先请求数据再渲染可视部分然后返回给客户端，客户端再做二次渲染,这样大部分消耗的是服务端的性能，客户端页面响应时间也更快。
SSR服务端渲染主要解决的是首屏渲染和SEO优化，是否需要SSR服务端渲染主要取决于SEO对于网站是否非常重要以及内容到达时间time-to-content对应用程序的重要程度。例如，如果你正在构建一个内部仪表盘，初始加载时的额外几百毫秒并不重要，这种情况下去使用服务器端渲染SSR将是一个小题大作之举。然而如果大量的访问流量来自于搜索引擎的抓取，那么服务端渲染SSR将是势在必行的解决方案，或者内容到达时间time-to-content要求是绝对关键的指标，在这种情况下服务器端渲染SSR可以帮助你实现最佳的初始加载性能。总而言之，开发需要根据实际场景寻找解决方案。