[See How]简单聊聊前端渲染模式以及Nuxt3.js

原文链接:因卓诶-简单聊聊前端渲染模式以及Nuxt3.js

前言

最近的工作有涉及到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（服务端渲染） 它的大致架构是如下这个样子

用户发起一个请求抵达后端服务器后：

1. 后端会将用户所需要的内容通过数据层进行查询
2. 处理业务
3. 通过模板来拼接页面
4. 返回一个html字符串给客户端
5. 前端渲染然后加载js脚本完成剩余交互

你可能也发现了，在SSR服务端渲染中，前端负责的东西太过单薄，说得好听叫交互，难听点就是“点击事件工程师”。所以老一辈的后端基本人人都会前端，js的水平高的一抓一大把。随着使用SSR渲染页面的应用越来越多，弊端也出现了:

1. 后端做了太多事情了，再牛逼的人也吃不消
2. 前后端耦合，维护难度升级
3. 内容更新/跳转，都需要重新加载一次页面
4. 服务端渲染成本很高
5. …

CSR

**CSR（客户端渲染）**大致是以下的架构:

CSR架构更贴近我们的现代前端开发，我们一般使用VUE, REACT这一类的前端视图框架时，都是默认CSR体系的。大致的流程是下面这样子的:

1. 浏览器向前端服务器请求html和js，html页面是空html，并且同时执行js
2. js渲染页面
3. 通过后端暴露的api进行交互

SSR和CSR的区别

可以发现，使用CSR进行开发，会有几个明显的缺点

SEO

因为从前端服务器获取的html最开始是空html，这非常不利于seo，很多搜索引擎的老版本蜘蛛会直接爬页面，不会等待js加载完，所以会直接爬出来一个空页面。尽管现在的百度，谷歌等搜索引擎的爬虫能力很强，能够部分支持CSR SPA页面，SEO效果虽然可以其他方式弥补 (比如加入meta标签等等); 但是我们使用SSR完全不用担心，因为获得的html页面是一个完整的，可以直接渲染的。

用户体验（白屏