网站构建器概述

三个构建器决定访客看到的内容，它们都使用相同的语言：区块。

        ┌──────────────── Header Builder ────────────────┐
        │  topbar · logo · navigation · search · actions  │
        └────────────────────────────────────────────────┘
        ┌──────────────── Page Builder ──────────────────┐
        │  slider · banner · features · products · CTA …  │
        │  (one page = an ordered bundle of blocks)       │
        └────────────────────────────────────────────────┘
        ┌──────────────── Footer Builder ────────────────┐
        │  brand · menu columns · newsletter · legal …    │
        └────────────────────────────────────────────────┘
                              ▲
                   ┌──────────┴──────────┐
                   │  Template Library   │
                   │ pages · blocks ·    │
                   │ header · footer     │
                   └─────────────────────┘

为什么它们是独立的构建器

页面内容和网站外观相似，但行为不同。外观出现在每个页面， 必须快速加载，并包含实时功能（导航、搜索、购物车）。页面内容是按URL 并且主要是编辑性的。因此外观有自己的存储和缓存交付，而页面则获得 完整的区块编辑器。两者使用相同的区块JSON，这使得一个模板库可以服务于 所有这些。

这反映了其他成熟系统的分割方式——WordPress称外观为“模板部分”，Shopify 称其为“部分组”。没有任何人通过页面引擎渲染头部。

在哪里找到每一个

性能模型

头部和底部通过商店前端以一个缓存请求获取 （GET /public/site-chrome），由页面外壳中的<link rel="preload">启动。在温暖缓存的情况下， 该请求的成本为零数据库查询，并且请求在浏览器标签中缓存以供 会话使用，因此在页面之间移动时不会重新获取。与外观相关的内容不会在页面 请求中运行，因此首次绘制从不被阻塞——骨架保持布局，直到有效载荷到达。