Web前端后端渲染
渲染
以Jade,YAML为代表的模板渲染引擎一般作用于服务器作为后端的视图部分。互联网早期，用户使用浏览器浏览的都是一些没有复杂逻辑的、简单的页面，
这些页面都是在后端将html拼接好的然后将之返回给前端完整的html文件，浏览器拿到这个html文件之后就可以直接解析展示了，而这也就是所谓的服务器端渲染了。因为后端拼接完了html，浏览器只需要直接渲染出来。
1、为什么会有服务端渲染和客户端渲染？
越来越复杂的 UI 意味着越来越多的渲染工作。目前，通常有两种选择：服务端渲染和客户端渲染。
以 Jade 和 YAML 为代表的模板渲染引擎一般作为后端视图部分作用于服务器。
使用直接处理HTML DOM 作用于前端，本质是客户端进行渲染。
最终用户看到的效果在两者之间是相同的。
最后，Web App 必须在 HTML 和 CSS 中实现，然后才能反映在用户界面中。
后端渲染归根结底就是将一些模板规范语言翻译成以上三种语言，传回给前端；而前端渲染则是将生成的整个逻辑代码传回前端，再由客户端生成用户界面。
一开始，Web App直接由几个HTML、CSS、JS组成，每个页面都需要特殊的逻辑，所以随着App规模的扩大，后端网站目录下的代码文件越来越多。没有同步，例如，您更改站点的布局样式。那么您可能需要修改数百个 HTML 文件。这谁能受得了？
聪明的工程师想，既然这么多的HTML都有一定的逻辑联系，为什么不用代码来生成代码呢？于是后端模板语言诞生了，这是前端狗的一大痛点，于是人们开始广泛使用模板语言，而不是手写的HTML。我认为模板语言的成功源于它成功地减少了前端工程师的工作量。
后端模板渲染的想法应该来源于“如何管理后端存储的数千个一致版本的前端页面？”的问题。通过代码生成代码本质上是一种编译。他们在HTML等基础语言的基础上做了更高层次的抽象包装，增强了易用性。各种模板语言大同小异，但大多都具备模板中模板的属性，完成继承等面向对象的特性。
大概，工程师当时没有考虑前端渲染的原因之一，就是他们认为的前端技术还没有兴起。现在CSS3和JS越来越流行，大大提高了前端的可操作性，尤其是Node.js出现之后，大大降低了JS工程师维护后端的成本。
从一些用户的角度来看，JS生成前端无非就是这个
var e = document.createElement('div');$('#container').append(e);
您需要先生成 DOM，然后再将其插入到其他 DOM 中。纯JS处理DOM确实比较麻烦，这可能也是客户端渲染没有发展起来的原因之一。
想想为什么后端模板语言方便简洁？因为它使用类似于 HTML 的语法。在 PHP 和 JSP 页面中，可以使用大量的 HTML 语法，并且只使用少量的变量注入和迭代注入。
使用 HTML 进行设计显然比纯 JS 更方便和直观。
那么我们可以借鉴一下，解决客户端渲染问题的最后一个技巧就是引入一个模板，这里我们称之为组件()。
Vue 对模板、新模板，甚至它们在 Web App 中的定位都有不同的看法。具体情况可以自行了解，这不是本文的重点。
由于前端也支持模板语言，也解决了之前的代码管理问题，而且之前的后端渲染引擎大部分也有基于JS的前端版本。
前端和后端真正解耦了。前端会专注于UI，后端会专注于数据处理，两端通过设计好的API进行交互。这将是一个趋势。
2、浏览器渲染和服务端渲染路由
在互联网的早期，用户使用浏览器浏览没有复杂逻辑的简单页面。这些页面都在后端与html拼接，然后在前端返回完整的html文件。浏览器得到了这个 html。之后就可以直接解析并显示文件了，这就是所谓的服务端渲染。随着前端页面复杂度的增加，前端不仅仅是一个普通的页面展示，还可能增加更多的功能组件，更加复杂。另外，当时ajax的兴起让业界开始佩服前后端开发模式分离，即后端不提供完整的html页面，而是提供了一些API，使得前端可以获取json数据，
客户端渲染和服务端渲染最重要的区别是谁来完成html文件的完整拼接。如果是在服务端做，然后返回给客户端，就是服务端渲染，如果是前端做的，还要多做一些工作来完成html的拼接，这就是客户端渲染。
客户端渲染路径：
- 请求一个html -> 2. 服务器返回一个html -> 3. 浏览器下载html中的js/css文件-> 4. 等待js文件待下载-> 5. 等待js加载完成初始化-> 6. js代码终于可以运行了，js代码向后端请求数据（ajax/）-> 7. 等待后端数据返回-> 8. 客户端将数据渲染为响应页面从无到有
服务端渲染路线：
- 请求一个html -> 2. 服务器请求数据（快速内网请求） -> 3. 服务器初始渲染（服务器性能好，速度更快） -> 4. 服务器返回内容正确的页面-> 5. 客户端请求js/css文件-> 6.等待js文件下载-> 7.等待js加载和初始化完成-> 8. 客户端完成剩余部分的渲染（小内容，快速渲染）
3、从后端渲染到前端渲染有什么变化？
将原本由服务端执行的渲染任务转移到客户端，大大减轻了大量用户访问时后端的压力。让后端专注于后端应该做什么，性能会大大提升，因为服务器确实减少了东西，现在随着客户端软硬件的发展，它可以处理大部分的渲染工作.
整个UI逻辑交给客户端后，一些有经验、有能力的用户可能会劫持UI，让他们看到一些不该看到的界面。这似乎违反了安全原则。但是“前端讲安全都是流氓”，后端不能信任前端传来的所有数据，记得做好过滤和验证。只要使用SSL，屏蔽XSS，后端没有发现漏洞，伪造身份劫持App还是比较困难的。
4、服务端渲染的优缺点是什么？
前端耗时较少。因为后端是拼接html的，浏览器直接渲染就可以了。
有利于SEO（搜索引擎优化）。因为后台有完整的html页面，更容易让爬虫爬取获取信息，更有利于seo。
无需占用客户资源。也就是说解析模板的工作完全交给了后端，客户端只需要解析标准的html页面，这样对客户端尤其是移动端占用的资源更少，也可以节省更多的时间。
后端生成静态文件。即产生缓存碎片，可以减少数据库查询浪费的时间，对于数据变化不大的页面非常高效。
不利于前后端分离，开发效率低。如果使用服务端渲染，无法进行分工协作，对于前端复杂度高的项目，不利于项目的高效开发。另外，如果是服务端渲染，一般是前端写一个静态的html文件，然后后端修改成模板，效率很低，经常需要前后端共同完成修改；或者前端直接完成html模板，然后交给后端。另外，如果后端改变了模板，前端也需要根据改变的模板调整css，增加了前后端联调的时间。
占用服务器端资源。即服务端完成对html模板的解析。如果请求很多，就会对服务器造成一定的访问压力。如果使用前端渲染，这些解析的压力就分散到了前端，这里确实是完全交给了一个服务器。
5、客户端渲染的优缺点是什么？
前端和后端是分开的。前端专注于前端UI，后端专注于api开发，前端有更多选择，无需遵循后端特定模板。
体验更好。比如我们把网站做成一个单页的Web应用程序（page web，SPA，它是一个加载单个HTML页面并在用户与应用程序交互时动态更新页面的Web应用程序）或部分内容转化为一个SPA，所以，尤其是移动端可以让体验更接近原生app。
前端响应慢。如果是客户端渲染，前端还需要进行字符串拼接的过程，这需要额外的时间，并且没有服务端渲染那么快。
不利于SEO。目前百度和谷歌的爬虫不识别SPA，只记录一个页面，所以SEO很差。因为服务端可能不会保存完整的html，但是前端使用js拼接dom，那么爬虫就爬不出来信息了。除非搜索引擎的SEO能增加爬虫能力，这样才能保证SEO。
5、使用服务端渲染还是客户端渲染？
不管业务场景如何，盲目选择使用哪种渲染方式都是流氓。比如一个企业级网站，主要功能是展示，不需要复杂的交互，需要很好的SEO，那么就需要使用服务端渲染；和后端管理页面类似，交互性比较强，不需要SEO考虑，那么就可以使用客户端渲染了。
另外，具体使用的渲染方式也不是绝对的。比如现在有的网站采用首屏服务端渲染，即对用户第一次打开的页面采用服务端渲染，这样可以保证渲染速度。页面渲染在客户端，完成了前后端分离。
6、对于前后端分离，如何进行SEO优化？
如果前后端分离，那么前端就是通过js修改dom，让html拼接完成，然后展示，或者用SPA，这样就几乎没有SEO了。那么这种情况下如何做SEO优化呢？
我们可以自己提交，让蜘蛛主动抓取，但是遇到中间的url，如果到达指定页面后只有meta js怎么办？这里我们可以用进行简单的优化，比如打印出当前页面信息的一些关键信息点，但是普通用户不需要这些，会造成额外的负担，前端可以判断是否支持，但后半部分不能。我们不得不借助百度的UA（用户代理）判断、使用或代理，对访问过的页面进行特殊处理，以达到被收录的效果。但是这个效果还是不好。. .
目前Vue和Vue都提供了SSR，即服务端渲染，是针对seo不好的解决方案。
7、前后端分离怎么理解？
其实在今天，前后端分离一定是必然或趋势，因为web1.0时代的早期网页都是简单的网页，但现在网页越来越向app移动，而前后端分离是实现app的必然结果。所以，我们可以把html、css、app组合起来，然后浏览器充当虚拟机来运行这些程序，即浏览器成为了app和客户端的运行环境。总的来说，目前的前端在增加。越往桌面应用或者手机端应用发展，比如电脑端的QQ可以在服务器端渲染吗？当然不是！因此，前后端分离成为必然。
如何判断网页是不是服务端渲染
看网页刷新后第一个请求（type为document），如果返回内容是包含有真实数据的html格式文本，就是服务端渲染，否则是客户端渲染
大厂的网站基本都是两者结合，如b站首页，搜索页面采用服务端渲染提升SEO，个人空间这种不需要的就直接客户端渲染
二、客户端渲染与服务端渲染本质的区别：
2.1、传输数据不同 （Chrome > 控制台 > Network > Preview > 查看传输内容）
客户端渲染：传递JSON对象、由浏览器渲染视图；
服务端渲染：传递完整HTML返回给浏览器渲染；
2.2、SEO优化问题（Chrome > 右击 > 检查网页源代码）
单页面应用：客户端渲染、源代码中无法获取到动态渲染的数据、不利于SEO爬虫
服务端渲染：首次渲染的html中携带所有服务器端返回的数据，原代码中包含所有数据，利于SEO优化；
如何在页面中快速的判断出来？
1、鼠标右键查看源代码，在页面中看到的内容在源代码中也可以查看到，则是服务端渲染得到的
2、鼠标右键查看源代码，页面中看到的内容在源代码中不可以查看到，则是客户端渲染得到的
方法一
若页面做整体的刷新，即网址发生改变，就是服务器渲染
若页面做了局部刷新，即网址没发生改变，就是客户端渲染
前端渲染和后端渲染的区别
服务端渲染是通过后端模板引擎编译成html,css,js,然后回传给前端来进行显示；而前端渲染则是将整个生成逻辑代码全部回传前端，再由客户端生成用户界面。
客户端渲染和服务器端渲染的最重要的区别就是究竟是谁来完成html文件的完整拼接，如果是在服务器端完成的，然后返回给客户端，就是服务器端渲染，而如果是前端做了更多的工作完成了html的拼接，则就是客户端渲染。
快速判断是前端渲染还是后端渲染
- 鼠标右键查看源代码，在页面中看到的内容在源代码中也
可以查看到，则是服务端渲染得到的
这说明页面中的内容是通过服务器渲染返回得到的，这样做的目的有利于seo - 鼠标右键查看源代码，页面中看到的内容在源代码中
不可以查看到，则是客户端渲染得到的
说明页面中的内容是通过客户端发送请求得到的，即这种情况就是通过客户端渲染的
前端渲染 客户端渲染
ajax请求到的数据再渲染到页面上
1
2查看原网页 ctrl+f找不到的都是前端渲染
1- 好处：html写的页面一般都是前端渲染
- 缺点：不利于seo优化，不利于搜索引擎爬虫到当前项目
后端渲染 服务器端渲染
- 后端数据和模板相结合后发送到前端
- 缺点： 耗费服务器性能
- 好处：利于seo优化 利于搜索引擎爬虫到当前项目
前后端渲染对比
| ~ | 后端渲染 | 前端渲染 |
|---|---|---|
| 页面呈现速度 | 快，受限于用户的带宽 | 主要受限于带宽和客户端机器的好坏，优化的好，可以逐步动态展开内容，感觉上会更快一点。 |
| 流量消耗： | 少一点点（可以省去前端框架部分的代码） | 多一点点（一个前端框架大概50KB）当然，有的用后端渲染的项目前端部分也有在用框架。 |
| 可维护性： | 差（前后端东西放一起，掐架多年，早就在闹分手啦） | 好，前后端分离，各施其职，代码一目明了。 |
| seo友好度： | 好 | 差，大量使用ajax，多数浏览器不能抓取ajax数据。 |
| 编码效率 | 低（这个跟不同的团队不同，可能不对） | 高，前后端各自只做自己擅长的东西，后端最后只输出接口，不用管页面呈现，只要前后端人员能力不错，效率不会低。 |
早期，页面都是直接由html，css，js实现的，每一个页面彼此之间相当于是独立的，当网站应用足够大的时候，需要修改网站的内容时，我们需要更改很多的代码，非常麻烦，不变维护。
后来，程序员使用代码生成代码，就是后端的模板引擎，人们开始广泛使用模板代替手写html，大大减少的前端的工作量。通过代码生成代码，其实就是编译，基于html等基础语言，做出了更高层次的抽象封装，增加了易用性。
再后来h5,c3崛起，再加上客户端硬件性能的提升，我们开始通过前端模板引擎，来在客户端渲染页面。
对待模板，angular，vue，react的态度都不一样。
前后端真正解耦，前端专注于UI视图,后台专注于数据处理，通过设计好的api交互，这是未来的趋势。
同构渲染
及解决什么问题？
- 要解决的问题：
首屏渲染慢、不利于seo问题，当搜索引擎爬取html的时候是没内容的，因为要客户端js解析完生成html
为了解决以上问题，则提出了同构渲染，借鉴了传统的服务端渲染，称之为现代化的服务端渲染或同构渲染。
- 同构渲染：
- 基于React、Vue等框架，客户端渲染和服务器端渲染的结合
- 在服务器端执行一次，用于实现服务器端渲染（首屏直出）
- 在客户端再执行一次，用于接管页面交互
- 核心解决SEO和首屏渲染慢的问题
- 拥有传统服务端渲染的优点，也有客户端渲染的优点
最后，提供给大家一个很好辨认页面中哪些是客户端渲染， 哪些是服务端渲染的方法： 打开页面的网络源代码， 能够搜到的就是服务端渲染，搜不到的就是客户端渲染。
客户端渲染
当此渲染为客户端渲染时，在客户端所进行的操作步骤如下所示：
- 收到服务端响应的字符串。
- 从上到下依次进行相关的解析，在解析的过程中，如果发现ajax请求，则再次发起新的请求。
- 拿到ajax响应的结果。
- 使用模板引擎进行渲染。
在客户端渲染中，其至少会发起两次请求。
- 第一次请求拿到相关的页面。
- 第二次请求拿到相关的动态数据。
优点：
页面显示速度比较快。
缺点：
内容的显示速度偏慢。
服务端渲染
在服务端读取相关所需渲染的页面文件，然后使用模板引擎渲染，在发送给客户端之前，服务端就已经将相关的页面进行了渲染处理了。
对于服务端渲染来说，只请求了一次。
缺点：
服务端压力变大，待需解析的内容越多，所进行解析的速度越慢。
客户端渲染和服务端渲染的区别
- 服务端渲染比客户端渲染更快。
- 客户端渲染与服务端渲染相比，客户端渲染能够更快的看到相关的页面，但是会有一个等待过程；而服务端渲染所进行渲染的就是直接的结果，客户端不需要再做任何处理。
- 客户端异步渲染是很难被爬虫抓取到的，爬虫爬不到相关的数据信息，不利于SEO搜索引擎优化。
- 服务端渲染可以被爬虫抓取到，即服务端渲染利于SEO搜索引擎优化。
客户端渲染和服务端渲染的判别方法
- 查看相关的网页源代码，如果在源代码中能够看到相关的数据，则表明其为服务端渲染。
- 查看相关的网页源代码，如果在源代码中不能够看到相关的数据，则表明其为客户端渲染，即其是随后在客户端动态追加的。
- 当请求新的数据信息时，页面没有进行刷新，则表明其是客户端渲染。
- 当请求新的数据信息时，页面进行了刷新，则表明其是服务端渲染。
- 若相关的数据请求是异步的，则表明其为客户端渲染。
客户端渲染和服务端渲染使用场景
- 需要考虑SEO搜索引擎优化，则使用服务端渲染。例如相关的商品希望被用户所搜索到。
- 不需要考虑到SEO搜索引擎优化，则使用客户端渲染。例如相关的评论为了用户体验，且不需要SEO优化。
前端领域中，随着Vue，React，Angular等框架的流行，前端工程化、模块化成为了当下主流技术方案。这类框架构建的SPA单页应用具有用户体验好、渲染性能好、可维护性高等有点，但是也存在以下两个方面的问题：
- 首屏加载时间长
SPA应用采用客户端渲染，用户需要等待客户端js解析完成之后才能看到页面，这样会导致首屏加载时间变长，用户体验差。
- 不利于SEO
由于SPA应用采用客户端渲染，在js未完成解析之前，网站HTML是没有内容的，这样导致搜索引擎爬取站点HTML时获取不到内容。
为了解决这两个问题，业界提出了一种新的解决方案，如下图：
利用服务端渲染解决首屏加载慢和不利于SEO的缺陷，首屏渲染完成之后，客户端渲染接管页面重新成为单页应用以保证良好的用户体验。这种方式称为现代化服务端渲染方式或者同构渲染。
与传统服务端渲染区别
传统服务端渲染，如JSP可以总结为以下几步：
- 客户端发送请求
- 服务端根据请求查找模板并获取数据。
- 执行渲染
- 生成html返回客户端展示
这种传统服务端渲染方式，会存在以下缺点：
- 前后端完全耦合，不利于开发维护。
- 前端发挥空间小。
- 服务端压力大。
- 用户体验一般。
而同构渲染只是在首屏渲染的时候和传统服务端类似，都是返回渲染好的html页面，但是，同构渲染中，当客户端展示渲染好的html页面后，客户端渲染会接管页面的控制权，也就是后续的渲染都是由客户端进行的，这样可以保证良好的用户体验。
同构渲染缺点
与单页应用相比，由于首屏渲染采用的是服务端渲染，所以存在以下缺点：
- 开发条件有限，开发有限制（服务端只能使用nodejs，而且并不是所有的工具包都能在服务端渲染中使用）。
- 涉及构建和部署的要求高（需要部署客户端和服务端，不能再和单页应用一样，部署静态站点即可）。
- 更多的服务端负载。
一. 什么是渲染
这里所说的渲染指的是把(数据 + 模板)拼接到一起的这个事儿。
例如对于我们前端开发者来说最常见的一种场景就是:请求后端接口数据，然后将数据通过模板绑定语法绑定到页面中，最终呈现给用户。这个过程就是我们这里所指的渲染。
渲染本质其实就是字符串的解析替换，实现方式有很多种;但是我们这里要关注的并不是如何渲染，而是在哪里渲染的问题
二. 客户端渲染
概述
随着前端技术栈和工具链的迭代成熟，前端工程化、模块化也已成为了当下的主流技术方案，在这波前端技术浪潮中，涌现了诸如 React、Vue、Angular 等基于客户端渲染的前端框架，这类框架所构建的项目就是单页应用(SPA)，他们属于客户端渲染。
优点
用户体验好、渲染性能好、可维护性高等。
缺点
首屏加载时间过长
与传统服务端渲染直接获取服务端渲染好的 HTML 不同，单页应用使用 JavaScript 在客户端生成 HTML 来呈现内容， 用户需要等待客户端JS 解析执行完成才能看到页面 ，这就使得首屏加载时间变长，从而影响用户体验。不利于 SEO
当搜索引擎爬取网站 HTML 文件时， 单页应用只有一些基本的html骨架和资源路径，它的HTML 没有内容，因为他它需要通过客户端 JavaScript解析执行才能生成网页内容 ，而目前的主流的搜索引擎对于这一部分内容的抓取还不是很好。
三. 服务端渲染
概述
最早期， Web 页面渲染都是在服务端完成的，即服务端运行过程中将所需的数据结合页面模板渲染为 HTML，响应给客户端浏览器 。 所以浏览器呈现出来的是直接包含内容的页面 。这种方式的代表性技术有:ASP、PHP、JSP，再到后来的一些相对高级一点的服务端框架配合一些模板 引擎。
优点
首屏加载时间短、利于 SEO。
缺点
- 应用的
前后端部分完全耦合在一起，在前后端协同开发方面会有非常大的阻力; 前端没有足够的发挥空间，无法充分利用现在前端生态下的一些更优秀的方案;- 由于内容都是在服务端动态生成的，所以
服务端的压力较大; - 相比目前流行的 SPA 应用来说，
用户体验一般;
但是不得不说，在网页应用并不复杂的情况下，这种方式也是可取的。
四. 同构渲染(现代化的服务端渲染)
概述
同构渲染 =【服务端渲染】 + 【客户端渲染】。isomorphic web apps(同构应用):isomorphic/universal，基于 react、vue 框架，客户端渲染和服务器端渲染的结合，在服务器端执行一次，用于实现服务器端渲染(首屏直出)，在客户端再执行一 次，用于接管页面交互，核心解决 SEO 和首屏渲染慢的问题。
相关技术
- React 生态中的
Next.js - Vue 生态中的
Nuxt.js - Angular 生态中的
Angular Universal
工作流程
- 客户端发起请求
- 服务端渲染首屏内容 + 生成客户端 SPA 相关资源
- 服务端将生成的首屏资源发送给客户端
- 客户端直接展示服务端渲染好的首屏内容
- 首屏中的 SPA 相关资源执行之后会激活客户端 Vue
- 之后客户端所有的交互都由客户端 SPA 处理
优点
首屏渲染速度快、有利于 SEO
缺点
开发成本高。- 涉及构建设置和部署的更多要求。与可以部署在任何静态文件服务器上的完全静态单页面应 用程序 (SPA) 不同，服务器渲染应用程序，
需要处于 Node.js server 运行环境。 更多的服务器端负载。在 Node.js 中渲染完整的应用程序，显然会比仅仅提供静态文件的 server 更加大量占用 CPU 资源 (CPU-intensive - CPU 密集)，因此如果你预料在高流量环境 (high traffic) 下使用，请准备相应的服务器负载，并明智地采用缓存策略
五. 总结
在对你的应用程序使用服务器端渲染 (SSR) 之前，你应该问的第一个问题是，是否真的需要它。这主要 取决于内容到达时间 (time-to-content) 对应用程序的重要程度。例如，如果你正在构建一个内部系统，初始加载时的额外几百毫秒并不重要，这种情况下去使用服务器端渲染 (SSR) 将是一个小题大作之 举。然而，内容到达时间 (time-to-content) 要求是绝对关键的指标，在这种情况下，服务器端渲染 (SSR) 可以帮助你实现最佳的初始加载性能。
事实上，很多网站是出于效益的考虑才启用服务端渲染，性能倒是在其次。 假设 A 网站页面中有一个 关键字叫“前端性能优化”，这个关键字是 JS 代码跑过一遍后添加到 HTML 页面中的。那么客户端渲染模 式下，我们在搜索引擎搜索这个关键字，是找不到 A 网站的——搜索引擎只会查找现成的内容，不会帮 你跑 JS 代码。A 网站的运营方见此情形，感到很头大:搜索引擎搜不出来，用户找不到我们，谁还会用我的网站呢?为了把“现成的内容”拿给搜索引擎看，A 网站不得不启用服务端渲染。 但性能在其次，不代表性能不重要。
服务器端渲染和客户端渲染的区别？
什么是服务器端渲染和客户端渲染？
互联网早期，用户使用浏览器浏览的都是一些没有复杂逻辑的、简单的页面，这些页面都是在后端将html拼接好的然后将之返回给前端完整的html文件，浏览器拿到这个html文件之后就可以直接解析展示了，而这也就是所谓的服务器端渲染了。而随着前端页面的复杂性提高，前端就不仅仅是普通的页面展示了，而可能添加了更多功能性的组件，复杂性更大，另外，彼时 ajax的兴起 ，使得业界就开始推崇前后端分离的开发模式，即后端不提供完整的html页面，而是提供一些api使得前端可以获取到json数据，然后前端拿到json数据之后再在前端进行html页面的拼接，然后展示在浏览器上，这就是所谓的客户端渲染了，这样前端就可以专注UI的开发，后端专注于逻辑的开发。
两者本质的区别是什么？
客户端渲染和服务器端渲染的最重要的区别就是究竟是谁来完成html文件的完整拼接， 如果是在服务器端完成的，然后返回给客户端，就是服务器端渲染，而如果是前端做了更多的工作完成了html的拼接，则就是客户端渲染。
服务器端渲染的优缺点是怎样的？
优点：
- 前端耗时少。 因为后端拼接完了html，浏览器只需要直接渲染出来 。
- 有利于SEO。 因为在后端有完整的html页面，所以爬虫更容易爬取获得信息，更有利于seo。
- 无需占用客户端资源 。即解析模板的工作完全交由后端来做，客户端只要解析标准的html页面即可，这样对于客户端的资源占用更少，尤其是移动端，也可以更省电。
- 后端生成静态化文件 。即生成缓存片段，这样就可以减少数据库查询浪费的时间了，且对于数据变化不大的页面非常高效 。
缺点：
- 不利于前后端分离，开发效率低。 使用服务器端渲染，则无法进行分工合作，则对于前端复杂度高的项目，不利于项目高效开发。另外，如果是服务器端渲染，则 前端一般就是写一个静态html文件 ，然后 后端再修改为模板 ，这样是非常低效的，并且还常常需要前后端共同完成修改的动作； 或者是前端直接完成html模板，然后交由后端 。另外，如果后端改了模板，前端还需要根据改动的模板再调节css，这样使得前后端联调的时间增加。
- 占用服务器端资源 。即服务器端完成html模板的解析，如果请求较多，会对服务器造成一定的访问压力。而如果使用前端渲染，就是把这些解析的压力分摊了前端，而这里确实完全交给了一个服务器。
客户端渲染的优缺点是怎样的？
优点：
- 前后端分离 。前端专注于前端UI，后端专注于api开发，且前端有更多的选择性，而不需要遵循后端特定的模板。
- 体验更好 。比如，我们将网站做成SPA或者部分内容做成SPA，这样，尤其是移动端，可以使体验更接近于原生app。
缺点：
- 前端响应较慢 。如果是客户端渲染，前端还要进行拼接字符串的过程，需要耗费额外的时间，不如服务器端渲染速度快。
- 不利于SEO 。目前比如百度、谷歌的爬虫对于SPA都是不认的，只是记录了一个页面，所以SEO很差。因为服务器端可能没有保存完整的html，而是前端通过js进行dom的拼接，那么爬虫无法爬取信息。 除非搜索引擎的seo可以增加对于JavaScript的爬取能力，这才能保证seo。
使用服务器端渲染还是客户端渲染？
不谈业务场景而盲目选择使用何种渲染方式都是耍流氓。 比如企业级网站，主要功能是展示而 没有复杂的交互 ，并且需要 良好的SEO ，则这时我们就需要使用服务器端渲染；而类似后台管理页面，交互性比较强，不需要seo的考虑，那么就可以使用客户端渲染。
另外，具体使用何种渲染方法并不是绝对的，比如现在一些网站采用了 首屏服务器端渲染 ，即对于用户最开始打开的那个页面采用的是服务器端渲染，这样就保证了渲染速度，而其他的页面采用客户端渲染，这样就完成了前后端分离。
对于前后端分离，如果进行seo优化？
如果进行了前后端分离，那么前端就是通过js来修改dom使得html拼接完全，然后再显示，或者是使用SPA，这样，seo几乎没有。那么这种情况下如何做seo优化呢？
我们可以自行提交 sitemap ， 让蜘蛛主动去爬取 ，但是遇到了sitemap中的url，达到指定页面之后只有元js怎么办呢？这是我们可以使用标签来进行简单的优化，比如打印出当前页面信息的一些关键的信息点，但是正常用户并不需要这些，会造成额外的负担，且前端可以判断是否支持JavaScript，而后段不行，只好根据百度的spider做UA判断，使用phantomjs或者nginx代理，来对spider访问的页面进行特殊的处理，达到被收录的效果。但这种效果还是不好。。。
而目前的react和vue都提供了SSR，即服务器端渲染，这也就是提供seo不好的解决方式了。
究竟如何理解前后端分离？
实际上，时至今日，前后端分离一定是必然或者趋势，因为早期在web1.0时代的网页就是简单的网页，而如今的网页越来越朝向app前进，而前后端分离就是实现app的必然的结果。所以，我们可以认为html、css、JavaScript组成了这个app，然后浏览器作为虚拟机来运行这些程序，即浏览器成为了app的运行环境，成了客户端，总的来说就是当前的前端越来越朝向桌面应用或者说是手机上的app发展了，而比如说电脑上的qq可以服务器端渲染吗？肯定不能！所以前后端分离也就成了必然。而我们目前接触额前端工程化、编译（转译）、各种MVC/MVVM框架、依赖工具、npm、bable、webpack等等看似很新鲜、创新的东西实际上都是传动桌面开发所形成的概念，只是近年来前端发展较快而借鉴过来的，本质上就是开源社区东平西凑做出来的一个visual studio。
服务端渲染和客户端渲染的区别
客户端渲染
就是我们的页面开始是没内容的，加载js后，js会生成和操纵dom，最后由浏览器渲染出页面，这一系列的操作都是在浏览器完成的。（前端去后端取数据生成DOM树。）
加载出来的是一个空的页面，该页面加载了app.js这个文件，该js文件会产生和操作Dom，最终浏览器渲染和绘制页面。
客户端渲染的优点：
1、前后端分离，开发效率高。
2、用户体验更好，我们将网站做成SPA（单页面应用）或者部分内容做成SPA，当用户点击时，不会形成频繁的跳转。
客户端渲染的缺点：
1、前端响应速度慢，特别是首屏，这样用户是受不了的。
2、不利于SEO优化，因为爬虫不认识SPA，所以它只是记录了一个页面。
Server Side Rendering（服务端渲染）
SSR 目的是对搜索引擎更友好，客户端渲染搜索引擎无法抓取页面相关内容，也就是用户搜不到网站的相关信息，排名就会比较靠后。（DOM树在服务端生成，然后返回给前端。）
原理：将 html 在服务端渲染，合成完整的 html 文件再输出到浏览器。
适用场景：客户端的网络比较慢，客户端运行在老的或者直接没有 JavaScript 引擎上
服务端渲染的优点：
1、尽量不占用前端的资源，前端这块耗时少，速度快。
2、有利于SEO优化，因为在后端有完整的html页面，所以爬虫更容易爬取信息。
服务端渲染的缺点：
1、不利于前后端分离，开发的效率降低了。
2、对html的解析，对前端来说加快了速度，但是加大了服务器的压力。
直观的区分服务端渲染和客户端渲染：
源码里如果能找到前端页面中的内容文字，那就是在服务端构建的DOM，就是服务端渲染，反之是客户端渲染。
客户端渲染与服务端渲染
什么是服务器端渲染和客户端渲染？
1 | 互联网早期，用户使用浏览器浏览的都是一些没有复杂逻辑的、简单的页面，这些页面都是在后端将html拼接好的然后将之返回给前端完整的html文件，浏览器拿到这个html文件之后就可以直接解析展示了，而这也就是所谓的服务器端渲染了。而随着前端页面的复杂性提高，前端就不仅仅是普通的页面展示了，而可能添加了更多功能性的组件，复杂性更大，另外，彼时ajax的兴起，使得业界就开始推崇前后端分离的开发模式，即后端不提供完整的html页面，而是提供一些api使得前端可以获取到json数据，然后前端拿到json数据之后再在前端进行html页面的拼接，然后展示在浏览器上，这就是所谓的客户端渲染了，这样前端就可以专注UI的开发，后端专注于逻辑的开发。 |
两者本质的区别是什么？
1 | 客户端渲染和服务器端渲染的最重要的区别就是究竟是谁来完成html文件的完整拼接，如果是在服务器端完成的，然后返回给客户端，就是服务器端渲染，而如果是前端做了更多的工作完成了html的拼接，则就是客户端渲染。 |
如何在页面中快速的判断出来？
1 | 1、鼠标右键查看源代码，在页面中看到的内容在源代码中也可以查看到，则是服务端渲染得到的 |