服务端渲染看这一篇就够了（Next.js）

背景：

以前：没有服务端渲染的概念，大规模应用之前，用户请求网页，都是后端先调用数据库，获得数据之后，将数据和页面元素进行拼装，组合成完整的 html 页面，再直接返回给浏览器，以便用户浏览，

优点：利于SEO，首屏快。

缺点：直接操作dom，性能差，代码管理混乱，不适合大工程，开发兼顾前后台，无法做到分工明确。  

     

现在：前后端分离，依赖于接口，并且单页应用得到了广泛应用（Angular、React、Vue 前端三大框架），后端专注于数据接口服务，前端专注接口调用，取得数据后渲染页面，

优点：分工明确，工程清晰，易于维护，虚拟dom性能高，满足日渐发展的前端需求。

缺点：不利于SEO（搜索引擎并不能收录到 ajax 爬取数据之后然后再动态 js 渲染出来的页面），首屏慢（单页应用由于一次性将代码发送给浏览器，代码过大导致首屏慢）。

 

好了，现在前后端分离解决了以前的很多痛点，但他却带来了一些新的痛点，于是有人说，那前后端分离、单页应用还不是鸡肋。事实上，它重新带来的痛点远远没有传统的痛点大，而且有很多项目对SEO和首屏的依赖性并不强，比如后台管理系统，比如ERP等等，而且首屏渲染依然不是问题，有webpack等打包工具的按需加载之后，可以解决首屏慢的问题，那对于SEO依赖性强的项目是不是就没法使用单页应用了呢？答案是否定的，服务端渲染可以解决SEO问题，而且还能让首屏更快

 

什么是服务器端渲染？        

分工明确，工程浩大，前后端分离无疑是未来趋势，但针对致命的SEO和和首屏慢，有何解决方法，服务端渲染由此而生、简单理解是将组件或页面通过服务器生成html字符串，再发送到浏览器，即数据和页面在服务器端就已经被渲染成完整的html文档，无需浏览器再通过接口访问数据再渲染。进而解决SEO（页面已经完整，爬虫可以爬取到页面所有内容），首屏慢（服务器端进行代码分隔，按需加载，只给浏览器有需要的资源）的问题。

附：对“代码分割、按需加载”的解释：即首次访问home，服务器只返回home页面，与home页面无关的资源不会加载，点击跳转路由至list，服务器返回list页面，与list页面无关的资源不会加载，此时该单页应用就已经将home和list都发至浏览器了，再次路由切换访问home时，不会发请求要home页面，这就是服务器端渲染解决了单页应用的致命问题，同时不影响单页应用的用户体验。

 

单页应用，使用的是客户端渲染： 

其渲染流程如下：

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. 客户端把剩下一部分渲染完成( 内容小，渲染快 )

计算一下：一共至多需要向服务器同步请求两次次数据

附：对同一个组件，服务端渲染“可视的”一部分( render/componentWillMount部分代码 )，为确保组件有完善的生命周期及事件处理，客户端需要再次渲染。即：服务端渲染，实际上也是需要客户端进行 再次地、但开销很小的二次渲染。

 

服务端渲染之next.js？（next.js对应的是react，如果你只会Vue，请对应自行学习Nuxt.js）

Next.js是一套基于React的服务器端渲染框架。在React模块化的基础上，带来以下几点好处：

1、默认服务端渲染模式

2、代码自动分隔使页面加载更快

3、以文件系统为基础的客户端路由

4、以webpack的热替换为基础的开发环境

5、使用React的JSX和ES6的module，模块化和维护更方便

6、可以运行在Express和其他Node.js的HTTP 服务器上

7、可以定制化专属的babel和webpack配置

next.js详细使用，请查看官方文档：https://nextjs.frontendx.cn/