基于 Jamstack 的性能优化方案

前言

本文基于这次抖音电商 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