阅读 728

基于 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

03c6be92-1c75-430a-bcbb-c208b5abf583.gif

文章分类
前端
文章标签