Site Builder: Overview
Site Builder Overview
Three builders decide what a visitor sees, and they all speak the same language: blocks.
┌──────────────── 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 │
└─────────────────────┘
Why they are separate builders
Page content and site chrome look similar but behave differently. Chrome appears on every page, must load fast, and contains live functionality (navigation, search, cart). Page content is per-URL and mostly editorial. So chrome gets its own storage and its own cached delivery, while pages get the full block editor. Both use the same block JSON, which is what lets one template library serve all of them.
This mirrors how other mature systems split it — WordPress calls chrome "template parts", Shopify calls it "section groups". Nobody renders the header through the page engine.
Where to find each one
| Builder | Where |
|---|---|
| Page Builder | Content → Pages → Create / Edit |
| Header Builder | Content → Menus → Header Builder |
| Footer Builder | Content → Menus → Footer Builder |
| Template Library | The Templates & blocks button in the page editor |
| Email Templates | CRM → Engagement → Templates |
Performance model
Header and footer are fetched by the storefront in one cached request
(GET /public/site-chrome), started by a <link rel="preload"> in the page shell. On a warm cache
that request costs zero database queries, and the request is cached in the browser tab for the
session, so moving between pages never refetches it. Nothing chrome-related runs inside the page
request, so first paint is never blocked — skeletons hold the layout until the payload lands.