前言
本文基于这次抖音电商 818 主会场性能优化项目介绍一下 Jamstack 架构
Jamstack 介绍
Jamstack 是 Netlify 公司在 2016 年提出的一种架构理念，JAM 分别是 JavaScript、APIs 和 Markup 的缩写，具体含义是：
- JavaScript (J): 主要指运行在浏览器的逻辑代码，负责前端渲染、数据请求等逻辑(例如：React、Vue、Angular).
-
APIs (A): 可以通过 JavaScript 调用的数据接口 (例如：飞书开放 API、GitHub API).
-
Markup (M): 用于页面构建的模板方案、站点生成器、构建工具 (例如：Nunjucks、 Webpack、Gatsby).
传统的 web 架构
我们过去熟悉的类 LAMP 或者 MEAN 架构的渲染流程都大概都如下图所示，每当用户请求一个页面时，服务器就会查询一个数据库，并将结果与页面的标记和插件中的数据结合起来，在浏览器中生成一个新的 HTML 文档。这个过程可以减慢页面加载时间。
Jamstack 架构
Jamstack 架构与上述传统架构还是有很大的不同，当用户请求页面时，不需要查询数据库，因为 HTML 文档在 CDN 静态缓存文件，如果有数据需求，会再通过 API 接口去获取。
Jamstack 的实现
Jamstack 的实现依赖下面几个点
- 页面前后端分离
- 前端支持提前构建
- 基于 CDN Cache 来控制是否需要回源（常见基于 etag)
- 基于统一的 API 网关对接口进行管理
Jamstack 实践
方案设计
Jamstack 核心还是一个架构思想，具体到我们这次抖音电商大促主会场，还是需要做一些调整
- 电商场景，数据分为静态部分、个性化部分
- 静态部分跟随静态页面一起下发
- 个性化部分通过 API 动态请求
- 搭建场景，页面无法提前构建，运营会频繁调整
- 提供在线页面构建服务，支持 CDN 回源
- 动态构建
- 基于动态源站，让页面拥有动态调整能力
- 为了性能，我们采用的是定时回源策略，这样可以减少压力，有更快的二次请求速度
- 基于源站，也可以对回源策略个性化调整，比如定点刷新能力
Jamstack Plus
Jamstack 架构主要还是基于浏览器 web 场景来设计，目前行业大多数访问路径都是在 App 内，所以我们也借助客户端提供更好的性能
DNS & TCP
根据我们的统计，DNS 和 TCP 会有 150ms-200ms 的耗时，基于 dns-prefetch preconnect 只能解决页面内的部分，我们基于字节浏览器内核 TTWebview 的域名保活功能，针对我们的域名进行的长链接保活，让这块儿耗时大幅减少
API Prefetch
Jamstack 架构让页面的静态和动态进行了分离，正常情况下，我们需要在页面主文档加载完成，使用 JavaScript 请求 API 获取数据，借助客户端的能力，我们可以在主文档加载的同时，并行加载 API 数据
静态资源离线化
借助客户端能力，我们提前将页面使用的静态资源（JavaScript、CSS、图片）进行了预先的离线化，这样可以大大减少静态资源的加载耗时。
Code Cache
借助字节浏览器内核 TTWebview，我们可以对 JavaScript 的编译结果进行 Cache，进一步减少二次打开的运行耗时
未来
跨端方案
目前页面越来越复杂，JavaScript 的执行耗时越来越久，一些预编译方案也是值得探索，比如 Flutter 本地开发时使用 JIT 保障研发体验，正式发布使用 AOT 保障性能。
SSR
如果页面的数据不是强个性化，SSR + Jamstack 是个非常好的架构，既保证性能，也有动态化能力。
团队介绍
我们是抖音电商前端营销团队，如果你对构建下一代搭建平台、跨端方案、性能优化感兴趣，可以联系我 mengdesen#bytedance.com
