服务器渲染和浏览器渲染的区别

何为渲染？
页面上的数据要发生更新，就是渲染。

这个工作放在服务器进行就是服务器渲染，放在浏览器进行就是浏览器渲染。

服务器端渲染，指的是后台语言通过一些模板引擎生成 html。

浏览器端渲染，指的是用 js 去生成 html，前端做路由。

浏览器端渲染路线：
请求一个 html。
服务端返回一个 html。
浏览器下载 html 里面的 js/css 文件。
等待 js 文件下载完成。
等待 js 加载并初始化完成。
由 js 代码向后端请求数据（ajax/fetch）。
等待后端数据返回。
客户端从无到完整地，把数据渲染为响应页面。 
服务端渲染路线：
请求一个 html。
服务端请求数据
服务器初始渲染。
服务端返回已经有正确内容的页面。
客户端请求 js/css 文件。
等待 js 文件下载完成。
等待 js 加载并初始化完成。
客户端把剩下一部分渲染完成。

　　越来越复杂的 UI 意味着越来越重的渲染工作。目前通常有两种选择：服务器渲染与客户端渲染。

　　以 Jade, YAML 为代表的模板渲染引擎一般作用于服务器作为后端的视图部分。 

　　而使用 JavaScript 直接 处理 HTML DOM 则是 作用于前端，性质是客户端执行渲染。

　　两者在最终用户看到的效果是一致的。 

　　Web App 最终都还是要落实到HTML，CSS，JavaScript上才能体现到用户界面上。 

　　归根结底，后端渲染是将一些模板规范语言翻译成如上三种语言回传给前端；而前端渲染则是将整个生成逻辑代码全部回传前端，再由客户端生成用户界面。

　　一开始，Web App 直接由若干 HTML，CSS， JS 组成，每一个页面需要特殊的逻辑，因此随着App规模的扩大，后端网站目录下的代码文件就越来越多，而且，彼此之间是没有同步的，比如你改了站点的布局风格。那么你很可能需要改动成百上千的HTML文件，这谁能忍?

　　聪明的工程师们想到，既然如此多的HTML具有一定的逻辑联系，何不使用代码生成代码？于是后端模板语言诞生了，这可是前端狗的一大痛点啊，于是人们开始广泛使用模板语言代替手写HTML。我认为，模板语言的成功源于它成功地减少了前端工程师的工作量。

　　后端模板渲染的思路应该是源自“如何管理数以千计的存储于后端的前端页面的版本一致？”这个问题的。通过代码生成代码，本质上是编译，他们基于HTML等基础语言作了更高层次的抽象封装，增强了易用性。各种模板语言大同小异，但大多都有模板中的模板这样的性质来完成继承这样的面向对象特性。

　　可能，当时工程师们没有考虑前端渲染的一大原因是 以JavaScript为代表的前端技术尚未崛起。现在HTML5，CSS3，JS 受到越来越广的普及使得前端的可作为性大大提升，特别是在Node.js出现以后 JS 工程师维护后端的成本大大降低。

在一些jQuery用户的角度看来，JS生成前端无非就是这样的

　　var e = document.createElement('div');
　　$('#container').append(e);

　　你需要先把DOM生成，然后再插入到其他的DOM里去。纯JS处理DOM确实是一件麻烦事，这可能也是客户端渲染迟迟没有发展起来的原因之一。

　　考虑一下为什么后端模板语言方便简洁？ 因为它用了与HTML类似的语法。在PHP，JSP页面里面你可以使用大量的HTML语法，只使用少量的变量注入与迭代注入。

使用HTML进行设计明显比纯JS更方便快捷并且直观。

　　那么可以借鉴地，解决客户端渲染问题的最后一个锦囊就是引入模板，在这里我们称之为组件(Component) 。

　　对待模板，新兴的Angular，React，Vue 意见不一，甚至他们对自己在Web App 的定位也不一样。 具体情况可以自己去了解，这并不是本文的重点。

　　随着前端也支持了模板语言，那么以前的代码管理问题也解决了，以往的后端渲染引擎也大多有了基于JS的前端版本。

　　前后端真正解耦，前端将专注于UI，后端将专注于数据处理，两端通过设计好的API进行交互，这会是一个趋势。

　　互联网早期，用户使用浏览器浏览的都是一些没有复杂逻辑的、简单的页面，这些页面都是在后端将html拼接好的然后将之返回给前端完整的html文件，浏览器拿到这个html文件之后就可以直接解析展示了，而这也就是所谓的服务器端渲染了。而随着前端页面的复杂性提高，前端就不仅仅是普通的页面展示了，而可能添加了更多功能性的组件，复杂性更大，另外，彼时ajax的兴起，使得业界就开始推崇前后端分离的开发模式，即后端不提供完整的html页面，而是提供一些api使得前端可以获取到json数据，然后前端拿到json数据之后再在前端进行html页面的拼接，然后展示在浏览器上，这就是所谓的客户端渲染了，这样前端就可以专注UI的开发，后端专注于逻辑的开发。

　　客户端渲染和服务器端渲染的最重要的区别就是究竟是谁来完成html文件的完整拼接，如果是在服务器端完成的，然后返回给客户端，就是服务器端渲染，而如果是前端做了更多的工作完成了html的拼接，则就是客户端渲染。

客户端渲染路线：

　　1. 请求一个html -> 2. 服务端返回一个html -> 3. 浏览器下载html里面的js/css文件 -> 4. 等待js文件下载完成 -> 5. 等待js加载并初始化完成 -> 6. js代码终于可以运行，由js代码向后端请求数据( ajax/fetch ) -> 7. 等待后端数据返回 -> 8. 客户端从无到完整地，把数据渲染为响应页面

服务端渲染路线：

　　1. 请求一个html -> 2. 服务端请求数据( 内网请求快 ) -> 3. 服务器初始渲染（服务端性能好，较快） -> 4. 服务端返回已经有正确内容的页面 -> 5. 客户端请求js/css文件 -> 6. 等待js文件下载完成 -> 7. 等待js加载并初始化完成 -> 8. 客户端把剩下一部分渲染完成( 内容小，渲染快 )

• 计算任务转移 

　　原本由服务器执行的渲染任务转移给了客户端，这在大量用户访问的时候大大减轻后端的压力。让后端专注做后端应该做的事情，性能将大大提高，因为服务器做的事情确实减小了，而现在随着客户端软硬件的发展，也能处理好大多数的渲染工作了。

• 放弃前端权限 

　　将整个UI逻辑交给客户端以后，一些有经验有能力的用户可能会劫持UI，使得他们能够看到一些不该看到的界面。这似乎违反了安全的原则。但是“一切在前端谈安全都是耍流氓”，后端不能轻信一切从前端传来的数据，切记一定要做好过滤与验证。只要使用SSL、屏蔽XSS、后端不出漏洞，想伪造身份劫持App还是难以做到的。

• 优点：

1. 前端耗时少。因为后端拼接完了html，浏览器只需要直接渲染出来。

2. 有利于SEO（搜索引擎优化）。因为在后端有完整的html页面，所以爬虫更容易爬取获得信息，更有利于seo。

3. 无需占用客户端资源。即解析模板的工作完全交由后端来做，客户端只要解析标准的html页面即可，这样对于客户端的资源占用更少，尤其是移动端，也可以更省电。

4. 后端生成静态化文件。即生成缓存片段，这样就可以减少数据库查询浪费的时间了，且对于数据变化不大的页面非常高效 。

• 缺点：

1. 不利于前后端分离，开发效率低。使用服务器端渲染，则无法进行分工合作，则对于前端复杂度高的项目，不利于项目高效开发。另外，如果是服务器端渲染，则前端一般就是写一个静态html文件，然后后端再修改为模板，这样是非常低效的，并且还常常需要前后端共同完成修改的动作； 或者是前端直接完成html模板，然后交由后端。另外，如果后端改了模板，前端还需要根据改动的模板再调节css，这样使得前后端联调的时间增加。

2. 占用服务器端资源。即服务器端完成html模板的解析，如果请求较多，会对服务器造成一定的访问压力。而如果使用前端渲染，就是把这些解析的压力分摊了前端，而这里确实完全交给了一个服务器。

• 优点：　　

1. 前后端分离。前端专注于前端UI，后端专注于api开发，且前端有更多的选择性，而不需要遵循后端特定的模板。

2. 体验更好。比如，我们将网站做成单页Web应用（single page web application，SPA，是加载单个HTML 页面并在用户与应用程序交互时动态更新该页面的Web应用程序）或者部分内容做成SPA，这样，尤其是移动端，可以使体验更接近于原生app。

• 缺点：

1. 前端响应较慢。如果是客户端渲染，前端还要进行拼接字符串的过程，需要耗费额外的时间，不如服务器端渲染速度快。

2. 不利于SEO。目前比如百度、谷歌的爬虫对于SPA都是不认的，只是记录了一个页面，所以SEO很差。因为服务器端可能没有保存完整的html，而是前端通过js进行dom的拼接，那么爬虫无法爬取信息。 除非搜索引擎的SEO可以增加对于JavaScript的爬取能力，这才能保证SEO。

　　不谈业务场景而盲目选择使用何种渲染方式都是耍流氓。比如企业级网站，主要功能是展示而没有复杂的交互，并且需要良好的SEO，则这时我们就需要使用服务器端渲染；而类似后台管理页面，交互性比较强，不需要seo的考虑，那么就可以使用客户端渲染。

　　另外，具体使用何种渲染方法并不是绝对的，比如现在一些网站采用了首屏服务器端渲染，即对于用户最开始打开的那个页面采用的是服务器端渲染，这样就保证了渲染速度，而其他的页面采用客户端渲染，这样就完成了前后端分离。

　　如果进行了前后端分离，那么前端就是通过js来修改dom使得html拼接完全，然后再显示，或者是使用SPA，这样，SEO几乎没有。那么这种情况下如何做SEO优化呢？

　　我们可以自行提交sitemap，让蜘蛛主动去爬取，但是遇到了sitemap中的url，达到指定页面之后只有元js怎么办呢？这是我们可以使用<noscript>标签来进行简单的优化，比如打印出当前页面信息的一些关键的信息点，但是正常用户并不需要这些，会造成额外的负担，且前端可以判断是否支持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。

原文链接：https://blog.csdn.net/huangpb123/article/details/83592258

原文链接：https://www.cnblogs.com/manshufeier/archive/2018/07/23/9357280.html