A specialty-food brand's store went from 6-second product pages to edge-served speed without a rebrand

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

This specialty-food brand makes small-batch pantry staples — sauces, spice blends, oils — and sells direct through an online store alongside wholesale accounts. Recipes are the marketing engine: recipe pages drive most new-customer discovery, and the brand team publishes constantly. The storefront runs on an established commerce platform; over years, the theme on top had collected apps, scripts, and campaign leftovers. One part-time developer maintains the store, and marketing's roadmap — landing pages, experiments, seasonal pushes — queues behind whatever capacity that developer has.

What it was costing

The brand's store ran on a theme that had accumulated apps and scripts for years; product pages took over six seconds on mobile, recipe content — the brand's best acquisition channel — was buried under render-blocking everything, and each marketing experiment required a developer.

What they could see

• Product pages took over six seconds to become usable on a phone — readers sat through a blank frame before anything responded to a tap.
• Recipe pages, the biggest acquisition channel, loaded so heavy that readers bounced before content appeared.
• Every marketing experiment — a new banner, a collection page, a test — waited days in the developer's queue.
• The theme had collected so many apps and scripts that nobody could say which ones were still used.
• Mobile conversion trailed desktop by a gap the team attributed to speed but had never fixed.

The constraints we worked inside

• The storefront platform stays; the replatform is to a headless front end, not a new commerce backend.
• The brand's design language is distinctive and hand-built; the rebuild must match it closely, not approximate it.
• Recipes are editorial content published by the brand team; the front end must give them a fast, self-serve path.

What had been tried before

An optimization pass on the existing theme — minification, image compression, script deference — was commissioned first.

The theme loads render-blocking apps on every template by design; the pass shaved milliseconds while six-second pages kept their architecture, and the weight regrew within weeks.

The store's developer hand-built static templates for the three highest-traffic product pages.

The bespoke templates drifted from the theme immediately — every price, badge, or banner change needed the developer again, and the experiment backlog kept growing.

A page-builder marketing layer was placed in front of the store for campaign experiments.

It stacked another script collection on an already heavy page, and anything touching product data still needed the developer — cost and weight, both up.

What we proposed

We proposed a headless front end: Next.js on Vercel, statically generated with on-demand revalidation, talking to the existing commerce platform's APIs — the storefront backend stays, because SKUs, checkout, and tax rules work and were not the problem. The brand's distinctive design language would be rebuilt as typed components with visual sign-off per template; approximation was not acceptable. Recipes move into a structured content model with a draft preview URL, giving the brand team a self-serve publishing path that ships fast by default — the acquisition channel stops depending on a developer's queue.

Just as important is what we ruled out, and why:

• A new commerce platform under a new front end — Payments approval, SKU and subscription migration, and staff retraining for a backend that already works; the constraint was the front end's weight, not the engine beneath it.
• Deeper optimization of the existing theme — Minification and pruning shave milliseconds off a structurally heavy page, and experiments would still queue behind the developer — the constraint the brand actually hired us to remove.
• Full server-side rendering for product and recipe pages — Both page types change rarely and read mostly; revalidation on publish delivers the same freshness at edge speed without per-request render cost during campaign spikes.

How the work ran

Delivered by the systems pod — engineer + commerce lead over 8 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

Next.js

A typed component system rebuilds the brand's hand-built design language exactly — approximation wasn't acceptable, and components make parity checkable per template.

Vercel

On-demand revalidation keeps product data fresh from the commerce APIs while pages serve from the edge, so speed doesn't cost freshness.

Commerce platform APIs

SKUs, subscriptions, and tax rules keep working untouched; only the front end's weight was the problem, so the backend stayed exactly as it was.

On-demand revalidation

Marketing experiments ship as new static variants with preview URLs, so launches stop requiring a developer deploy to go live.

Structured recipe content

Recipes become data with a preview path for the brand team, decoupling the best acquisition channel from one part-time developer's queue.

What went wrong

How we worked together

Cadence

Mid-week and Friday build reviews with the developer and brand lead, template by template, with visual sign-off recorded per template and a shared board of unblocked experiments.

Client side

The developer paired on API integration and kept ownership of the commerce backend; the brand lead signed off designs and tested the recipe publishing path.

Decisions

Design parity was settled in review calls against the live site side by side; anything touching checkout was escalated to the founder the same day.

They provided

API credentials and theme assets, the recipe archive with its photo library, and protected time from the developer across the eight weeks.

What changed

The headline: mobile lcp on product pages, 28-day field data after cutover — 6.1s → 1.9s, read from CrUX field data. A second check: recipe-page entrances converting to product views at +17%.

Marketing's backlog flipped direction: experiments launch without the developer now, and the developer's queue holds real engineering instead of banner swaps. The brand team treats recipe publishing as part of writing a recipe, not a handoff. Page speed stopped appearing in the weekly meeting because it stopped being a slide. And the design language survived the rebuild intact — it met the founder's standard of looking exactly like the brand, which is why most customers never noticed it happened.

The result was read from CrUX field data against the pre-engagement baseline over the stated window, with a guardrail check on recipe-page entrances converting to product views. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• A typed component library matching the design language, with the per-template visual sign-off record.
• The recipe migration script, kept and documented, for future archive additions.
• A brand-team publishing guide: drafting, previewing, and releasing recipes without developer involvement.
• A performance budget per template, checked in CI, so page weight can't creep back.