-
服务端渲染（吐）
服务端在返回 html 之前，在特定的区域，符号里用数据填充，再给客户端，客户端只负责解析 HTML 。
服务端渲染
也被称为 fat-server, thin-client 模式
服务端渲染
-
客户端渲染（填）
html 仅仅作为静态文件，客户端端在请求时，服务端不做任何处理，直接以原文件的形式返回给客户端客户端，然后根据 html 上的 JavaScript，生成 DOM 插入 html。
客户端渲染
也被称为 fat-client, thin-server 模式
客户端渲染
异同
渲染本质一样，都是字符串拼接，将数据渲染进一些固定格式的html代码中形成最终的html展示在用户页面上。
-
拼接字符串必然引起性能的消耗。
服务端渲染性能消耗在服务端，当用户量比较多时，缓存部分数据以避免过多数据重复渲染。 客户端渲染，如当下火热的 spa 框架，Angular、React、Vue，在首次渲染时，大多是将原 html 中的数据标记（如 {{ text }} ）替换。客户端渲染较难的一点是数据更新以后，页面响应式更新时如何节省资源，直接 DOM 的读写，是很消耗性能的。 Vue 2.0 + 有 Vnode，进行 diff 后，渲染到页面上。
利弊
[图片上传失败...(image-b97b92-1542164471424)]
同构
为了解决客户端渲染首屏慢与 SEO 问题，同构开始出现。
同构：前后端共用 JS，首次渲染时使用 Node.js 来直出 HTML。一般来说同构渲染是介于前后端中的共有部分。
[图片上传失败...(image-825a-1542164471424)]
同构
同构优点有很多，balabalabala……
简单说下在使用 Vue SSR（nuxt）的一些坑：
服务端必须是 node.js 或者专门跑个 node.js 来支持；
document 对象找不到，由于前端使用的 window，在 node 环境不存在；
数据预获取时，组件尚未实例化（无法使用 this ），于是在 created 生命钩子调用 method 里的方法行不通，数据请求及格式化等操作都应该放置在专门的数据预取存储容器（data store）或"状态容器（state container）"中处理；
string-based 模板性能肯定要比 virtual-dom-based 模板的性能好。string-base 模板只要填数据即可，virtual-dom-based 模板需要经历 Vue 模板语法 ---> Vnode ---> 拼接字符串 html 的过程。 有关性能的消耗对比，可以参考这篇文章 mp.weixin.qq... ；
缓存方面，只能做到页面级的缓存。如果用户特定（user-specific），即对于不同用户需要渲染不同内容，缓存是不可用的。
是否有其他解决客户端渲染不足之处的方法？
答案肯定是有的：
处理 SEO 问题时，使用 prerender... 、升级搜索引擎，以及其他。
白屏可以加 loading、Skeleton Screen 效果、以及其他。
总结
用户体验才是王道。
后端渲染（SSR、服务端渲染）
后端渲染HTML的情况下，浏览器会直接接收到经过服务器计算之后的呈现给用户的最终的HTML字符串，这里的计算就是服务器经过解析存放在服务器端的模板文件来完成的，在这种情况下，浏览器只进行了HTML的解析，以及通过操作系统提供的操纵显示器显示内容的系统调用在显示器上把HTML所代表的图像显示给用户。
前端渲染（SPA、单页面应用）
前端渲染就是指浏览器会从后端得到一些信息，这些信息或许是适用于题主所说的angularjs的模板文件，亦或是JSON等各种数据交换格式所包装的数据，甚至是直接的合法的HTML字符串。这些形式都不重要，重要的是，将这些信息组织排列形成最终可读的HTML字符串是由浏览器来完成的，在形成了HTML字符串之后，再进行显示。
题主所提到的几个技术，我认为模板这个词语并不能用来区分这些技术的本质，模板只是一种提供给程序来解析的一种语法，换句话说，模板是用于从数据（变量）到实际的视觉表现（HTML代码）这项工作的一种实现手段，而这种手段不论在前端还是后端都有应用。
以下为本人自己的想法：在性能上，我认为后端渲染最终会被前端渲染，因为后端渲染将所有的HTML生成集中在了一个服务器上，而前端渲染将这部分工作分发到各个终端上。另外，对于开发而言，这样能够避免后端开发人员过多的编写HTML代码，后端开发人员只需和前端开发事先商定好数据格式，后端就只需将数据生成，用数据交换格式包装，再发送出去就可以了，这样能够使开发人员之间的分工更加明确。
再附上稀土掘金上的一段理解：
SEO
很重要，所以要普及。
SEO： 搜索引擎优化（Search Engine Optimization），它是指通过站内优化，如：网站结构调整、网站内容建设、网站代码优化以及站外优化等方法，来进行搜索引擎优化。
简单说： 通过各种技术（手段）来确保，你的Web内容被搜素引擎最大化收录，最大化提高权重，带来更多流量。
常见关键词：白帽、黑帽、SEM、Backlink、Linkbait、PageRank、Keyword Stuffing...，总之都围绕着一个核心：SEO；流量是变现的快车道，SEO是低成本获取流量的最佳方法。
SPA
SPA：单页Web应用（single page web application，SPA），就是只有一张Web页面的应用，是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序。
简单说： Web不再是一张张页面，而是一个整体的应用，一个由路由系统、数据系统、页面（组件）系统...组成的应用程序，其中路由系统是非必须的。
大部分的Vue项目，本质是SPA应用，Angular.js、Angular、Vue、React...还有最早的"Pjax"均如此。
SPA时代，主要是在Web端使用了history或hash（主要是为了低版本浏览器的兼容）API，在首次请求经服务端路由输出整个应用程序后，接下来的路由都由前端掌控了，前端通过路由作为中心枢纽控制一系列页面（组件）的渲染加载和数据交互。
而上面所述的各类框架则是将以：路由、数据、视图为基本结构进行的规范化的封装。
最早的SPA应用，由Gmail、Google Docs、Twitter等大厂产品实践布道，广泛用于对SEO要求不高的场景中。
SSR
SSR： 服务端渲染（Server Side Render），即：网页是通过服务端渲染生成后输出给客户端。
在SPA之前的时代，我们的Web架构大都是SSR，如：Wordpress（PHP）、JSP技术、JavaWeb...或者DEDECMS、Discuz!等这些程序都是传统典型的SSR架构，
即：服务端取出数据和模板组合生成html输出给前端，前端发生请求时，重新向服务端请求html资源，路由也由服务端来控制。
其次，有个概念叫预渲染（Prerendering）。
如果你只是用服务端渲染来改善一个少数的营销页面（如 首页，关于，联系 等等）的SEO，那你可以用预渲染来实现。
预渲染不像服务器渲染那样即时编译HTML，它只在构建时为了特定的路由生成特定的几个静态页面，等于我们可以通过webpack插件将一些特定页面组件build时就编译为html文件，直接以静态资源的形式输出给搜索引擎。
但实际的商业应用中，大部分时候我们需要的是即时渲染，这也是我们今天讨论的主题。
Why
为什么要SSR，为了体验，还有SEO。
首先，用户可能在网络比较慢的情况下从远处访问网站 - 或者通过比较差的带宽。 这些情况下，尽量减少页面请求数量，来保证用户尽快看到基本的内容。
可以用Webpack的代码拆分避免强制用户下载整个单页面应用，但是，这样也远没有下载个单独的预先渲染过的HTML文件性能高。
对于世界上的一些地区人，可能只能用1998年产的电脑访问互联网的方式使用计算机。
而Vue只能运行在IE9以上的浏览器，你可能也想为那些老式浏览器提供基础内容 - 或者是在命令行中使用 Lynx的时髦的黑客。
在大部分的商业应用中，我们有SEO的需求，我们需要搜索引擎更多地抓取到我们的内容，更详细地认识到我们的网页结构，而不是仅对首页或特定静态页进行索引，这是SSR最重要的意义。
简单说就是，我们需要搜素引擎看到这样的代码：
而不是这样的代码：
且，我们还需要在SSR的基础上实现SPA，即：首屏渲染。
基本流程是：
在浏览器第一次访问某个URI资源的时候（首屏），Web服务器根据路由拿到对应数据渲染并输出，且输出的数据中包含两部分：
- 路由页对应的页面及已渲染好的数据
- 完整的SPA程序代码
在客户端首屏渲染完成之后，此时我们看到的其实已经是一个和之前的SPA相差无几的应用程序了，接下来我们进行的任何操作都只是客户端的应用进行交互，
页面/组件由Web端渲染，路由也由浏览器控制，用户只需要和当前浏览器内的应用打交道就可以了。
之前在各大SPA框架还未正式官方支持SSR时，有一些第三方的解决方案，如：prerender.io，
它们做的事情就是建立HTTP一个中间层，在判断到访问来源是蜘蛛时，输出已缓存好的html数据，此数据若不存在，则调用第三方服务对html进行缓存，往复进行。
另一方法是自行构建蜘蛛渲染逻辑，当识别UA为搜索引擎时，拿服务端已准备好的模板和数据进行渲染输出html数据，反之，则输出SPA应用代码；
我当时也考虑过此方法，但有很多弊端，如：
需要针对蜘蛛编写一套独立的渲染模板，因为大部分情况下SPA的代码是没法直接在服务端使用的
搜索引擎若检测到蜘蛛抓取数据和真实访问数据不一致，会做降权惩罚，也就意味着渲染模板还必须和SPA预期输出一模一样
所以，最好的方法是SPA能和服务端使用同一套模板，且使用同一个服务端逻辑分支，再简单说：最好Vue、Ng2...能直接在服务端跑起来。
作者：牧码人小鹏
链接：https://www.jianshu.com/p/14c3c4f61d90
來源：简书
简书著作权归作者所有，任何形式的转载都请联系作者获得授权并注明出处。
