fe_服务端渲染ssr

4 min read

ssr

服务端渲染听上去很高大上,其实10年前的应用都是服务端渲染的。

渲染指的是数据填充到页面上的过程,服务端渲染就是在后端将数据填充到dom元素中,直接返回填充好的html文本。与之对应的客户端渲染就是客户端发起ajax请求来拉取数据,然后渲染到dom中,在前后端分离模式下一直是客户端渲染的。

倒退?

以十年前很火的三大框架,php/jsp/asp为例,他们都是服务端渲染的,如下:

image

php文件本身就是php+html混写的,在请求该文件的时候,php引擎会抽出php标签运行相关代码,其他标签内容原样返回。这就是纯纯的服务端渲染,是服务端将数据填充到dom中去的,这种前端爬虫是能直接爬到数据的。

image

前后端分离明明可以将后端代码和前端代码完全解耦,html中不在出现后端的语言,这样两波人可以独立开发,这不是很好的事情吗?为啥又要复辟呢?

其实并不是需要所有的前端场景都要转SSR,而是有些场景例如文章博客系统,他们是需要被搜索引擎爬取数据的,SEO(Search Engine Optimizatio)搜索引擎优化。

为了能做好SEO,就需要被搜索引擎爬虫的时候,能爬到数据内容,上面例子中可以看到,客户端渲染被爬虫是看不到数据部分的,所以SSR就成了这种应用的出路。

但是直接退回php这种嵌入的编写方式,那之前积累的大量前端的框架,就没法用了,那咋办呢,那就出一个node.js版本的服务端,他既能使用前端框架的组件库,又能调用后端的函数:例如查询数据库等,然后用特定的函数名指定一个jsx中哪个函数是在后端运行拿数据的,剩下的就跟以前的前端一样编译成正常的js文件。

不同的解决方案

以react为例,next.js是最出名的ssr方案,但是它主打SSG,静态资源 + CDN的方案来提速,zeit团队的代表作。

remix是Facebook团队的开源方案,2021年底开源,主打SSG + 服务器缓存的方案,更加轻量。

除了单纯的SSR,next夹杂了很多私货,要学的东西变多。