ISR

我们基于 SSG 的基础上再来探讨 ISR

在 SSG 场景中，假如我们一个产品中有 10000 个页面，每次构建的时候，等待的时间可能是十分长的。而且很可能我们的一次修改仅仅只会修改其中的几个或者几十个页面，权衡之下，SSG 方案似乎有些不划算了

ISR 提出的方案就是，每次构建，我们只完全预渲染其中的一部分页面，比如 10000 个页面中，我们渲染重要的 1000 个页面

当请求命中了非这 1000 个页面中的时候，再启动渲染，并且将渲染结果缓存下来

在 NextJs 中，这里有两种方式处理

• fallback: blocking：阻塞请求，等当前请求的页面渲染完成后返回页面，等渲染完成之后，之后的相同请求返回这个页面
• fallback: true：不阻塞请求，直接返回上一次的缓存页面（可能内容是过期的），同时在后台渲染页面，等渲染完成之后，之后的相同请求返回这个页面

权衡

SSR

ISR 和 SSR 很像，主要的不同点在于，SSR 每次都返回新生成的页面，而 ISR 可以保证第一个请求是渲染过的页面

SSG

对于小项目，SSG 比 ISR 会更有优势，如果在 build 阶段的时间本身就不长，没有必要使用增量渲染方案

CSR

CSR 只需要服务器静态托管，而 ISR 需要运行 Node。ISR 具有 CSR 不具有的 SEO 优势

ISR 不只是缓存，它的目的是在部署之间持久保存生成的页面。使用 ISR 技术部署的时候，需要保证上一次部署的资源没有被移除，当作为增量渲染的页面被请求，结果应该指向上一次部署的目标页面。哪怕对服务进行了回滚。ISR 机制也应该能正常工作

https://www.smashingmagazine.com/2021/04/incremental-static-regeneration-nextjs/