前端对于服务端渲染(SSR)的理解
什么是服务端渲染(SSR)?
假设有项目需要渲染一个首页,平时我们的项目启动后,开始渲染,请求页面,返回的body为空,然后执行js将html结构注入body中,再结合css来渲染样式,展现出来。
而使用了服务端渲染(SSR)后,简单理解是将组件或页面通过服务器生成html字符串,再发送到浏览器,最后将静态标记"混合"为客户端上完全交互的应用程序。渲染时请求页面,返回的body里已经存在服务器生成的html结构,之后只需要结合css显示出来。这就节省了访问时间和优化了资源的请求。
使用SSR后的优点?
1. 更利于网站的SEO
2. 更利于首屏页面的渲染
使用SSR后的局限性?
1. 服务端压力较大
本来是通过客户端完成渲染,现在统一到服务端node服务去做。尤其是高并发访问的情况,会大量占用服务端CPU资源。
2. 开发条件受限
在服务端渲染中,只会执行到componentDidMount之前的生命周期钩子,因此项目引用的第三方的库也不可用其它生命周期钩子,这对引用库的选择产生了很大的限制。
3. 学习成本相对较高
除了对本身项目使用的前端框架要熟悉,还需要掌握webpack、node、Koa2等相关技术。相对于客户端渲染,项目构建、部署过程更加复杂。
部分理解和思路:
next.js / nuxt.js 可以很好的完成SSR。
对于toB的项目,SSR无所谓,对于toC的项目,SSR还是必要的。
用了前端框架,浏览器接收到的还是模板和大量的JS,数据需要异步请求过来。所以存在SEO和性能问题。这时候就需要SSR了。
如果不使用服务器端渲染,一个页面的展示流程大概就是,浏览器先下载html和js,然后到服务器请求json数据,最后根据json生成页面。
如果使用服务器端渲染的话,以上步骤都在服务器端执行,也就是说服务器端从自己服务器那里先获取json,然后生成页面,最后把生成的页面输出成html给浏览器下载。