当我们使用Next.js、Gatsby.js类似的站点生成框架时，它们本身具有ssg、dsg、ssr的预渲染方案。该如何选择以及改动成本是什么，下面将列举这几种构建方式的区别、优缺点及适用场景。
参考资料
- netlify博客: https://blog.logrocket.com/ssg-vs-ssr-in-next-js/
- netlify博客: https://www.netlify.com/blog/2020/12/02/next.js-should-i-use-ssr-or-ssg/
- Gatsby官方说明： https://www.gatsbyjs.com/blog/choosing-the-best-page-rendering-modes-for-your-gatsby-site/
<u>它们最大的区别和重点在于页面构建的时间不同以及对构建和渲染时间的取舍</u>
ssgstatic-site-generation静态站点生成
传统静态资源模式，部署前提前构建完所有页面及资源，项目构建时间和项目本身成正比
- 构建时间: 部署阶段构建
- 优点: 良好的SE和O用户体验好，因为页面构建打包是在部署阶段当用户访问时是打包好的静态资源没有运行时加载，页面响应速度更快
- 缺点: 随着项目内容的增多打包速度会随之越来越慢构建时间也就相应变长，且容易被植入xss攻击代码
- 适用: 内容不经常更改的类似门户、博客网站
csgclient-side-generation客户端渲染
每次页面从加载到展示都需经过资源请求和api请求填充数据
- 构建时间: 每次页面加载是动态渲染
- 优点: 传统单页面bundle开发模式都是客户端渲染、学习门槛低无需额外服务配置
- 缺点: 因为是动态渲染不利于网络爬虫SEO,并且每次都需要资源和api请求完成后完全展示会有响应速度慢的问题
- 适用: 传统单页面打包模式应用
ssrserver-side-rendering服务端渲染
内容经常变化需要随时根据服务请求保持更新
- 构建时间: 每次请求服务时动态构建渲染返回包括数据的所有文档内容
- 优点: 相对于ssg的全量构建在开发部署占用的时长，ssr会预渲染部分再经过运行时代码动态渲染，极大缩减开发部署耗时,相比CSG更好的SEO
- 缺点: 因为需要动态渲染所以需要经过请求来保证实时更新，TTFB(Time-To-First-Byte)会有开销增加白屏时间相对影响用户体验
- 适用: 内容经常变化，且有自定义化需求的
dsgdeferred-static-generation延迟静态生成
预先构建部分重要页面进行缓存，对于不必要的内容延迟渲染生成。是Gatsby对DPR(Distributed Persistent Rendering)分布式持久化渲染概念的实现。
设置页面属性 defer: true,将进行延迟渲染，直到第一个用户请求页面。数据依然会在构建时获取并保存为快照，因此在渲染时不需要访问任何API，每个用户都会看到相同的页面。 只有首次访问用户需要等待更长时间，但渲染的页面随后会被缓存后续请求速度会很快
- 构建时间: 重要内容预先构建、其余延迟到具体请求时渲染
- 优点: 保证重要页面渲染速度的前提下，延迟次要内容的渲染缩减了部署时的构建时长均衡了ssg构建时长的问题
- 缺点: 需要服务端增加缓存策略和制定方案，增加了服务端成本
- 适用: 内容较多，有渲染优先级类型的站点