Shopify Headless Development

The question before the project

Almost everyone who writes to us about headless has already decided. They have read that it is faster, they have seen a competitor’s storefront that felt quicker, and they want a quote. The useful conversation starts one step earlier: what is the theme layer actually costing you, in money, per month?

That question has real answers. A design the theme fights on every template. Three developer-days a month spent working around Liquid’s rendering model. A front end that cannot be reused for the native app the business is also building. An editorial team blocked behind a theme release cycle. Those are reasons to go headless, and they are measurable.

“It will be faster” is usually not one, and it is the reason we are given most often. A headless storefront gives you control over what ships and when it renders. It does not give you a fast site — it gives you the ability to build one, and the equally real ability to ship something considerably slower than Dawn. We have audited headless builds that lost to the theme they replaced on every Core Web Vital, because nobody owned a budget and every quarter added one more client-side dependency.

So the first thing we sell here is not a build. It is a short, paid assessment that answers one question in writing: should this store go headless, and if not, what should it do instead. A meaningful share of them come back “not yet”. That is a good outcome for both sides, and it is the reason the technical buyers we want to work with take the second call.

What headless actually changes

Headless replaces the theme layer. Shopify keeps the products, the inventory, the orders, the customers, the discounts and the checkout. Your storefront becomes an application you own that reads from the Storefront API over GraphQL and drives the cart through it.

What you gain is control over rendering. You choose what is server-rendered, what is streamed, what is cached and for how long, what ships to the browser and what never does. You can compose Shopify with a headless CMS, a PIM, a search provider and a review system, and present them as one thing rather than as five widgets stacked on a product page. You can reuse the same component library and the same data layer for a native app or an in-store kiosk.

What you lose is more concrete than most proposals admit. The theme editor goes. Every app that works by injecting into the theme stops working, and each one becomes a decision: replace it with an API integration, rebuild the feature, or do without. Your marketing team’s ability to build a landing page on a Thursday afternoon becomes a thing you have to deliberately design for — usually by connecting a CMS with a visual editor, which is a project of its own with its own licence cost.

That trade is worth making at a certain scale and a certain rate of change. It is a poor trade for a store doing modest volume with two people running it, and the industry has been extremely quiet about that.

Hydrogen, and when it isn’t Hydrogen

Hydrogen is Shopify’s React framework for headless storefronts, built on Remix, deployed to Shopify’s Oxygen hosting. It is our default recommendation, for one unglamorous reason: it is the stack Shopify maintains against its own API. When the Storefront API changes, Hydrogen’s documentation, examples and utilities change with it. On any other stack, that reconciliation is your problem, and you pay for it every quarter forever.

There are good reasons to pick something else. An existing application that already owns the routes and the design system. A team that is deep in another framework and will maintain this for years. A front end that has to serve more than a storefront. In those cases the Storefront API is a GraphQL endpoint like any other and we build against it directly — with Astro, React or Preact depending on how much of the page genuinely needs to be interactive.

Whatever hosts it, the architecture decisions are the same and they are made before the build: rendering strategy per route, caching and revalidation, where the cart lives, what the content source is, and what stays inside Shopify because Shopify does it better than we would.

Performance is a budget, not an outcome

On a headless build we set a budget per route — bytes shipped, requests, and a Core Web Vitals target — and enforce it in the pipeline, so the build fails when a dependency pushes a route over. Field data, not lab scores: what phones on real networks experience, over a rolling window, not what a laptop on office wifi reports once.

This is the part that makes a headless storefront actually fast, and it is almost never in a proposal, because it is a constraint on the people writing the proposal.

The migration is the risky part

Moving a live storefront that already earns and already ranks is where these projects go wrong, and it goes wrong in three predictable ways.

URLs change and nothing redirects them. Structured data that the theme emitted quietly for years does not get reimplemented, and the rich results disappear about six weeks later. And pages render nothing without JavaScript, so crawlers that do not execute it — including a good share of the AI retrieval fetchers now worth caring about — see an empty document.

All three are avoidable, and all three are avoided by treating them as deliverables rather than as launch-week tasks. The redirect map is verified line by line against the old site’s indexed URLs. Structured data parity is checked page type by page type, not sampled. Server rendering is the default for anything a crawler needs, and we check what the page contains with JavaScript disabled before cutover, because that is what several of the things reading your store now actually see.