前言
最近的工作有涉及到ssr,所以这篇文章算是一个总结,并且对还在beta阶段的nuxt3做一个浅析。前段时间有一个蛮火的视频,关于rollup作者rich的一段演讲,在演讲里面rich梳理了ssr和csr,并且讲述了痛点,和提出新的概念“transition app”,如果你有兴趣可以看看这个视频
在文章开始前,我来简单介绍一下"spa", “mpa”, “ssr”, “csr”…这些个名词的意义。如果你是做web前端开发的,这几个词可能伴随着你的工作生涯很久很久了,相关文章互联网上多如牛毛,如果你对这些概念比较模糊甚至压根不知道,那么别关闭网页,我希望这篇文章能够拯救你。
SPA与MPA
MPA称之为“多页应用”, 那么什么是多页应用呢?字面意思其实就是有多个页面的应用就是多页应用。从技术手段上来讲,你可以这么粗略地理解。SPA,MPA不同点太多了,而且各有利弊。
MPA应用你需要单独维护多个html页面,而且我们每加载/切换一次页面,都需要加载一整个页面。但是它对于seo特别友好,因为我们可以给每一个html页面设置不同的meta等信息,从而达到更好的收录效果;所以MPA多出现在大型的电商/新闻网站等。
不同于MPA,SPA可以使得我们通过ajax或者其他技术动态的更改某一个区域的内容而不需要重新加载页面,包括切换页面也不会重新加载整个html,它对状态的留存做的很好,而且在移动端表现特别优异(因为在以前流量是很珍贵的,可以以最小的损失切换页面,无论是用户体验还是成本相较于MPA都是极大的改善)
SSR
在我们web较早的时候,开发者喜欢使用jsp或者其他模板渲染引擎来构造一个应用。我们一般称之为SSR(服务端渲染) 它的大致架构是如下这个样子
用户发起一个请求抵达后端服务器后:
- 后端会将用户所需要的内容通过数据层进行查询
- 处理业务
- 通过模板来拼接页面
- 返回一个html字符串给客户端
- 前端渲染然后加载js脚本完成剩余交互
你可能也发现了,在SSR服务端渲染中,前端负责的东西太过单薄,说得好听叫交互,难听点就是“点击事件工程师”。所以老一辈的后端基本人人都会前端,js的水平高的一抓一大把。随着使用SSR渲染页面的应用越来越多,弊端也出现了:
- 后端做了太多事情了,再牛逼的人也吃不消
- 前后端耦合,维护难度升级
- 内容更新/跳转,都需要重新加载一次页面
- 服务端渲染成本很高
- …
CSR
**CSR(客户端渲染)**大致是以下的架构:
CSR架构更贴近我们的现代前端开发,我们一般使用VUE, REACT这一类的前端视图框架时,都是默认CSR体系的。大致的流程是下面这样子的:
- 浏览器向前端服务器请求html和js,html页面是空html,并且同时执行js
- js渲染页面
- 通过后端暴露的api进行交互
SSR和CSR的区别
可以发现,使用CSR进行开发,会有几个明显的缺点
SEO
因为从前端服务器获取的html最开始是空html,这非常不利于seo,很多搜索引擎的老版本蜘蛛会直接爬页面,不会等待js加载完,所以会直接爬出来一个空页面。尽管现在的百度,谷歌等搜索引擎的爬虫能力很强,能够部分支持CSR SPA页面,SEO效果虽然可以其他方式弥补 (比如加入meta标签等等); 但是我们使用SSR完全不用担心,因为获得的html页面是一个完整的,可以直接渲染的。