Jasmstack 是一个很有意思的领域，值得单独摘一片文章来说。优势和劣势比较明显。

技术演进

Jamstack一本通 - 图1

  • CSR client side rendering 客户端渲染 spa
  • SSR server side rendering 服务端渲染，需要一个node server，就引入了运维监控的概念
  • SSG static site generation 静态网站生成，纯前端文件，需要遍历路由，路由有变化需要重新全量渲染
  • ISR Incremental Site Rendering 增量式的网站渲染，增量
  • DPR Distributed Persistent Rendering 分布式的持续渲染

我觉得前三个不用多解释，就不解释了。

SSR

SSR从直观上看，一个页面如果考虑更好的体验，应当区分动态内容和静态内容：比如菜单导航和新闻详情。知乎的那篇文章更加细致：

  • 变化不频繁的，比如文章、排行榜、推荐列表，应该设定缓存
  • 变化频繁的，比如用户头像、时间轴、登录状态、实时评论

得出初步结论：变化不多的不应该交给服务端渲染，会造成资源浪费，可以考虑api动态渲染，这一点说起来复杂，操作简单，比如nuxt提供了相关判断符号，可以区分 SSR/CSR 的环境

SSG

SSG 最大的问题就是需要全量发布，成本太高。

ISR

到了ISR这部分，尝试解决全量渲染的问题：

  • 关键页面，渲染成SSG，走CDN，比如网站首页
  • 非关键历史页面，回退到CSR，加入渲染列表，生成静态文件，纳入CDN

也就是，第二次访问生成静态文件。 stale-while-revalidate

缺陷也明显：

  • 第一次和第二次命中的页面不同，体验不一致

  • 第二次访问有可能是过期了，下一次才是对的

    DPR

    对ISR的改进：

  • 第一次，没太理解，类似于引入了 serverless 函数

  • 页面始终不响应过期文件，CDN溯源到服务器走渲染
  • 发版时候，自动刷新CDN

显然还是有问题的：

  • serverless 推广门槛，启动
  • DPR 像 CDN + Serverless 组合，Serverless builder 这里只是做兜底。最终目的都是以 最少开支最快地展示实时内容（又快又省）
  • 不成熟，依赖厂商

苦恼，兜兜转转。

-1 参考资料

大会《GMTC2021》之 《字典跳动的现代web开发实践》部分

JAMstack: https://jamstack.org/