Skip to content

Reference build

Tidemark

Headless commerce

The build agencies ask for most often, and the one where performance is the entire brief.

Year
2026
Engagement
Reference build

What it had to do.

A direct-to-consumer catalogue on Shopify, with the storefront rebuilt headlessly so that design and performance are not constrained by theme architecture. Merchandising stays in Shopify admin, where the client's team already works.

The constraint

Performance is not a nice-to-have on this one, it is the reason the project exists. The target was green Core Web Vitals on a mid-range Android over a throttled connection, not a desktop Lighthouse score screenshot.

Architecture

How it is put together.

Edge

  • Static cataloguepre-rendered, revalidated
  • Image pipelineAVIF, fixed aspect

Runtime

  • Cart + pricingstreamed in
  • Searchpredictive, debounced
  • Checkout handoffShopify hosted

Source

  • Storefront APIproducts, collections
  • Admin APIbuild-time sync
  • Webhookstargeted revalidation
The split that makes it fast: everything shared is static at the edge, everything personal is streamed after.

Stack

  • Next.js
  • Shopify Storefront API
  • TypeScript
  • Tailwind
  • Cloudflare

Every choice cost something.

An architecture without trade-offs is an architecture nobody has stress-tested. Here is what we gave up for what we got.

Static shell, streamed personalisation

What we did

Catalogue and content render statically at the edge; cart, stock and customer-specific pricing stream in afterwards.

Why

Nothing personal belongs in a cached document, and nothing shared should wait for a personal lookup. Splitting them means the first paint never blocks on an API call.

What it cost

Price changes propagate on revalidation rather than instantly. Flash-sale SKUs are excluded from static rendering, because being briefly wrong about a sale price is worse than being slightly slower.

Prefetch on intent, not on viewport

What we did

Links prefetch on hover or touch-start instead of when they scroll into view.

Why

Viewport prefetching on a long product grid downloads dozens of pages nobody will open, on mobile data, paid for by the customer.

What it cost

First desktop navigation is marginally slower than aggressive prefetching. Bandwidth on mobile drops sharply, which is where the customers actually are.

Layout shift is designed out, not tuned out

What we did

Every image renders inside a box whose aspect ratio comes from Shopify metadata; missing dimensions fail the build.

Why

Cumulative layout shift is almost always images without reserved space. If the data is complete, the shift cannot happen.

What it cost

Requires clean product data, which not every catalogue has. An admin report flags SKUs with missing dimensions so merchandisers can fix them before publish.

How it was built.

  1. Week 1

    Performance budget

    Targets agreed per template as hard numbers, with the build failing if a budget is exceeded.

  2. Weeks 2-4

    Catalogue and templates

    Collection, product and content templates, image pipeline, and the data contract with Shopify admin.

  3. Weeks 5-6

    Cart and checkout

    Streamed cart, stock states, discount handling and handoff to Shopify's hosted checkout.

  4. Week 7

    Field testing

    Throttled mobile testing on real devices, not emulators, with fixes prioritised by field data rather than lab scores.

What is true of it.

Properties of the build we can demonstrate, not business results we did not measure.

  • Layout shift is structurally prevented: a product without image dimensions fails the build rather than shipping.

  • The performance budget is enforced in CI, so a regression blocks the merge instead of being discovered a quarter later.

  • Merchandising stays entirely in Shopify admin: no developer is needed to publish a product.

  • Checkout remains Shopify-hosted, keeping PCI scope out of the custom codebase.

Next step

Tell us what needs building.

A 30-minute call, under mutual NDA if you want one signed first. You leave with a view on scope, team shape and budget range, whether or not you work with us.

Or write to hello@warmbench.dev