Scroll Top

Shopify Hydrogen and Headless Commerce

Updated September 2026 · Written and maintained by the Progression Agency strategy team

Headless commerce separates the storefront from the commerce engine, and Hydrogen is Shopify’s framework for building that storefront. It buys complete control over the experience — at the cost of building and maintaining an application that replaces everything a theme gave you for free. This covers the three reasons that genuinely justify it, the reasons that do not, what breaks, what it costs to run rather than to build, and the decision sequence that stops most projects at the right point.

The short answerHeadless does not make a store faster. It gives you control over performance, which means you can make it faster and equally make it slower — a well-built theme is fast and a badly-built headless storefront is slow. Before deciding, name the specific thing your theme cannot do. If you cannot name it concretely, the theme is not your constraint and improving it will get you further for less.

Progression Agency is based in New York City and works with ecommerce clients across the United States. Shopify’s framework capabilities, hosting options, API versions and app ecosystem change regularly — verify current specifics in Shopify’s own developer documentation rather than relying on any third-party description, including this one.

Headless commerce, in short
The commonest failure is not the build. It is eighteen months later, when the developer has moved on and the dependencies are two major versions behind.

What is headless commerce, and what is Hydrogen?

Headless commerce separates the storefront a customer sees from the commerce engine behind it, so the two are built and deployed independently. Hydrogen is Shopify’s own framework for building that storefront.

The commerce engine still handles products, inventory, checkout and orders. What changes is that the front end is an application you build rather than a theme you configure.

What separating the storefront actually means
Steps five to seven are why headless is less risky than it sounds: the money-handling parts stay where the platform maintains them.

What does going headless actually buy you?

Complete control over the storefront experience, the ability to pull content from several systems into one interface, and freedom from theme constraints — at the cost of building and maintaining an application.

It buys control. Whether that control is worth the cost depends entirely on whether the theme was genuinely limiting something commercially important.

What headless gives, and what it costs
GainWhat it meansCorresponding cost
Full design controlNo theme constraintsYou build every component
Custom interactionsConfigurators, visualizers, complex filteringDevelopment and testing
Content from several systemsCMS, PIM, commerce in one interfaceIntegration and maintenance
Independent deploymentFront end ships separatelyA deployment pipeline to run
Performance controlYou decide what loads and whenYou also own the regressions
Multi-channel reuseSame data, several front endsOnly useful if you have several
Framework flexibilityModern toolingDevelopers who know it
Freedom from theme updatesNothing breaks on a theme changeNothing improves either

The last row is worth reading twice. Escaping theme updates also means escaping the improvements platforms ship to themes, so anything the platform adds for theme users has to be built by you instead.

When is headless genuinely the right decision?

When the storefront experience is a competitive advantage, when content and commerce genuinely need to merge, or when a specific interaction the theme cannot support is commercially important.

Those are the three defensible reasons. Everything else — speed, modernity, developer preference — is either achievable within a theme or not actually the constraint.

Experience is the differentiator — Justified. Configuration, visualization..
Content and commerce merge — Justified. Deeply interleaved, not linked..
A specific unsupported interaction — Justified. Concrete, not a wish..
Several front ends — Justified. One catalog, many storefronts..
Commerce inside a product — Justified. A feature, not the whole thing..
Real internationalisation complexity — Justified. Beyond platform features..

The storefront experience is the differentiator

Where how the product is presented, configured or visualized is part of why people buy.

Content and commerce must genuinely merge

Editorial, guides and product deeply interleaved rather than linked from a blog.

A specific interaction the theme cannot support

A configurator, a complex filter, a made-to-order flow. Something concrete rather than a general wish.

Several front ends on one commerce backend

Multiple brands or regions sharing catalog and inventory.

An existing application the store must live inside

Where commerce is a feature of a larger product rather than the whole thing.

Genuine internationalisation complexity

Beyond what the platform’s own market features handle.

When is it the wrong decision?

When the reason is speed, when nobody will maintain it, when the team has no relevant experience, or when the theme was never actually the constraint.

The speed argument is the one that catches most merchants: a well-built theme is fast, and a badly-built headless storefront is slow. Architecture does not confer performance.

Does your situation justify headless?
The bottom four are the most frequently stated reasons and the weakest ones. The top four are rarely given and are the ones that actually hold.
Reasons for going headless, and whether they hold
Stated reasonDoes it hold?What is actually true
‘It will be faster’RarelyA good theme is fast; headless can be slow
‘The theme is limiting us’SometimesName the specific limitation first
‘It is more modern’NoNot a business reason
‘Our developers prefer it’No, on its ownA real factor, not a justification
‘We need a configurator’YesA concrete capability theme cannot do
‘Content and commerce must merge’YesA genuine architectural need
‘We have several storefronts’YesReuse is the classic case
‘Competitors have done it’NoTheir constraint is not yours

The ‘theme is limiting us’ row is the one to interrogate hardest. Ask which specific thing the theme cannot do, and whether that thing is commercially important. If the answer is vague, the theme is probably not the constraint.

Does headless make a store faster?

Not inherently. It gives you control over performance, which means you can make it faster and you can equally make it slower.

Core Web Vitals are decided by what a page actually loads and when, not by whether the storefront is a theme or an application. Google’s own guidance on those metrics is the authoritative reference, and it says nothing about architecture.

What actually determines storefront speed
Relative influence, not measured values. Every item here is controllable in a theme too, which is why architecture alone does not confer speed.

A theme can be fast

A well-built theme with disciplined apps and optimized images performs well, and most slow themes are slow because of accumulated apps and unoptimised images.

Headless can be slow

Large JavaScript bundles, unoptimised data fetching and third-party scripts produce the same problems in any architecture.

You inherit responsibility for performance

Which is genuinely valuable if somebody owns it, and a liability if nobody does.

Fix the theme first, then decide

Removing unused apps and optimizing images frequently produces the improvement people were hoping headless would deliver.

Measure before and after

Against real field data rather than a synthetic score, because synthetic tests miss what real visitors experience.

What do you have to build that a theme gave you?

Everything on the storefront: product listing and detail pages, cart, search, filtering, navigation, content pages, account pages and every state in between.

This is the part consistently underestimated. A theme supplies dozens of working components, and each has to be built, tested and maintained in a headless storefront.

Product listing and detail — You build. Every state..
Cart interface — You build. Logic stays on platform..
Search and filtering — You build. Or integrate a service..
Navigation and content pages — You build. Or add a CMS..
Account pages — You build. Interface, not identity..
Error and empty states — You build. The ones nobody remembers..

What stays with the platform?

Products, inventory, orders, customers, payments and checkout — and checkout in particular generally remains on the platform.

That boundary matters commercially: the highest-risk part of the funnel stays where the platform maintains it, which is one of the more reassuring aspects of this architecture.

What moves and what stays
ComponentHeadlessPlatform
Product listing and detail pagesYou buildData supplied
Cart interfaceYou buildCart logic supplied
CheckoutGenerally staysPlatform-maintained
Search and filteringYou build or integrateData supplied
Content pagesYou build, or a CMSOptional
Customer accountsYou build the interfaceIdentity and data supplied
PaymentsUntouchedPlatform
Inventory and ordersUntouchedPlatform
Discounts and promotionsDisplayed by youLogic on platform
Apps that inject front-end codeFrequently unavailableTheme-dependent

The last row is the practical shock for many merchants: apps that work by injecting code into a theme have nothing to inject into, so a headless build means re-solving whatever those apps were doing.

What happens to your existing apps?

Apps that add back-office functionality generally continue. Apps that inject front-end code generally do not, and their functions have to be rebuilt.

Auditing the app list before committing is the single most useful piece of preparation, and it frequently changes the decision.

What does a headless build cost to run, not just to build?

Hosting, a deployment pipeline, dependency and framework updates, monitoring, and developer availability — ongoing rather than one-off.

A theme is maintained largely by the platform. A headless storefront is an application your business now owns, with the ongoing obligations that implies.

What skills does the team need?

Front-end application development, an understanding of the commerce APIs, and somebody who can keep dependencies current — available continuously rather than for the build.

The most common failure is not the build. It is the eighteen months afterwards when the developer who built it has moved on and the dependencies are two major versions behind.

Front-end application skills — Team needs. Continuously, not once..
Commerce API understanding — Team needs. Data shapes and limits..
Dependency maintenance — Team needs. The real long-term cost..
A deployment pipeline — Team needs. And somebody who owns it..
Monitoring — Team needs. You own the errors now..
A plan for developer turnover — Team needs. The commonest failure point..

How do you decide?

Name the specific capability the theme cannot deliver, establish that it matters commercially, confirm somebody will maintain the result, and only then evaluate the architecture.

If you cannot complete the first step with something concrete, the answer is almost certainly to improve the theme instead.

The decision, in order
QuestionIf the answer is unclearIf the answer is clear
What can the theme not do?Stop; fix the themeContinue
Does that matter commercially?StopContinue
Could a theme app or custom work do it?Try that firstContinue
Who maintains it in two years?Stop; this is the real riskContinue
Do we have the skills continuously?Hire or partner firstContinue
Which apps break?Audit before decidingPlan the replacements
What is the ongoing cost?Model itBudget it
What does success look like?Define itMeasure it

Steps four and five stop more headless projects than any technical consideration, and stopping there is a good outcome rather than a failure: an unmaintained storefront is worse than a constrained one.

What are realistic examples of headless being the right call?

A made-to-order product needing a configurator, a publisher selling products inside editorial, a group running several brands on one catalog, and a business whose store lives inside a larger application.

These are illustrative situations rather than named client results. Each describes a capability a theme genuinely cannot deliver, which is the test that matters.

Illustrative situations where headless holds up
SituationWhy a theme cannot do itWhat headless enables
Made-to-order configuratorComplex state and pricing logicA real configuration interface
Publisher selling within editorialContent and commerce deeply interleavedOne interface, two systems
Several brands, one catalogThemes are per-storefrontShared data, distinct front ends
Store inside a larger applicationCommerce is a feature, not the siteEmbedded commerce
Visualizer or room plannerHeavy interactive stateA genuine application
B2B portal with account pricingComplex per-customer logicCustom account experience
Kiosk or in-store screenNot a browser storefrontA different front end, same backend
Marketplace-style browsingComplex faceted searchSearch you control fully

These are examples of the pattern rather than case studies: in every one, somebody can name the specific thing the theme cannot do. That is the whole test, and a situation that does not fit any of these rows is unlikely to justify the architecture.

Is a hybrid approach a good compromise?

It is a real option and not a simplification — running part of a site headless and part theme-based means maintaining two systems rather than one.

It makes sense where one section genuinely needs the control and the rest genuinely does not, and it is a poor way to avoid making the decision.

What should you do before committing?

Fix the theme’s performance, audit the apps, name the capability, and identify the person who maintains the result — in that order.

Two of those four frequently end the conversation, which saves considerably more than the project would have cost.

How should the project be scoped if you do proceed?

Component by component, with the states nobody remembers included — empty carts, failed searches, out-of-stock variants, error pages — because those are where headless builds overrun.

A theme ships all of those working. A headless scope that lists only the happy path is a scope that will be exceeded.

The states a headless scope must include
StateWhy it mattersCommonly scoped?
Empty cartSeen by many visitorsSometimes
Failed or empty searchCommon, and a conversion momentRarely
Out-of-stock variantFrequent, and confusing if unhandledSometimes
Product with one imageLayouts assume severalRarely
Very long product titlesBreaks layoutsRarely
Discount applied and removedCart state changesSometimes
Payment or network failureUsers hit itRarely
404 and error pagesEvery site needs themRarely

The rows marked rarely are where headless builds overrun, and they are all supplied working by a theme. Listing them in the scope is the cheapest correction available to the estimate.

Considering headless and not sure it is the constraint?

We work with ecommerce clients across the United States, and we will help you name the specific thing your theme cannot do before anybody proposes an architecture — because if that cannot be named, the theme is not the problem.

Talk to Progression Agency

Video: ecommerce and marketing practice

A general library on marketing practice. The headless commerce material is written out in full above.

Getting found in search

AI, AEO and what is changing

Paid media and lead generation

Websites and design

Choosing and working with an agency

Social, content and brand

By industry and by situation

Frequently asked questions

Are there shopify hydrogen themes available?
Hydrogen ships starter templates rather than a theme marketplace. Shopify hydrogen themes do not exist in the Online Store sense — Hydrogen is a React framework, so what you install is a scaffolded storefront you then build on, not a theme you configure.
What is the default shopify hydrogen theme?
The Hydrogen skeleton template, generated by the CLI. The shopify hydrogen theme most projects start from is that skeleton plus Shopify’s demo store components, which give you cart, product and collection routes to modify rather than a finished design.
What is headless commerce?
An architecture separating the storefront a customer sees from the commerce engine behind it, so the two are built and deployed independently.
What is Shopify Hydrogen?
Shopify’s own framework for building a headless storefront that talks to its commerce platform through the storefront API.
What does headless actually buy you?
Complete control over the storefront experience, the ability to combine content from several systems, and freedom from theme constraints.
Does headless make a store faster?
Not inherently. It gives you control over performance, which means you can make it faster and equally make it slower. A well-built theme is fast; a badly-built headless storefront is slow.
What actually determines storefront speed?
Image weight and format, third-party and app scripts, JavaScript bundle size, data fetching strategy, fonts and hosting — all controllable in a theme too.
Should I fix the theme before going headless for speed?
Yes. Removing unused apps and optimizing images frequently produces the improvement people hoped headless would deliver, at a fraction of the cost.
When is headless genuinely justified?
When the storefront experience is a competitive differentiator, when content and commerce must genuinely merge, or when a specific interaction the theme cannot support matters commercially.
What are the weak reasons for going headless?
That it will be faster, that it is more modern, that developers prefer it, or that competitors have done it. None is a business justification on its own.
What about ‘the theme is limiting us’?
Interrogate it. Ask which specific thing the theme cannot do and whether that matters commercially. If the answer is vague, the theme is probably not the constraint.
What do I have to build that a theme gave me?
Product listing and detail pages, cart interface, search, filtering, navigation, content pages, account pages, and every error and empty state in between.
What stays on the commerce platform?
Products, inventory, orders, customers, payments and — generally — checkout, which is the highest-risk part of the funnel and remains platform-maintained.
Why does checkout staying matter?
Because the part of the funnel where money changes hands remains maintained by the platform rather than becoming your responsibility, which is genuinely reassuring.
What happens to my existing apps?
Back-office apps generally continue. Apps that work by injecting code into a theme generally do not, because there is no theme to inject into.
How do I find out which apps break?
Audit the app list before committing. It is the single most useful preparation step and it frequently changes the decision.
What does headless cost to run rather than to build?
Hosting, a deployment pipeline, dependency and framework updates, monitoring, and continuous developer availability.
Why is that different from a theme?
Because a theme is maintained largely by the platform. A headless storefront is an application your business owns, with the ongoing obligations that implies.
What skills does the team need?
Front-end application development, understanding of the commerce APIs, and somebody keeping dependencies current — available continuously rather than only for the build.
What is the most common failure?
Not the build. It is eighteen months later, when the developer who built it has moved on and the dependencies are two major versions behind.
Do we lose platform improvements by going headless?
Yes, on the storefront. Escaping theme updates also means escaping the improvements platforms ship to themes, so anything added for theme users must be built by you.
Is headless good for multiple storefronts?
It is the classic justified case: several front ends sharing one catalog, inventory and order system is exactly what the architecture is for.
Is it right for a store with a configurator?
That is one of the strongest cases, because a complex configurator or visualizer is a concrete capability a theme genuinely cannot deliver.
Does headless help international selling?
Only where the complexity genuinely exceeds what the platform’s own market features handle. Below that threshold it adds cost without adding capability.
How should I decide?
Name what the theme cannot do, confirm it matters commercially, check a theme app or custom work cannot do it, and confirm who maintains the result in two years.
Which decision step stops most projects?
Who maintains it in two years, and whether the skills are available continuously. Stopping there is a good outcome rather than a failure.
Is an unmaintained headless storefront worse than a constrained theme?
Yes, clearly. A storefront nobody can update becomes a business risk, where a constrained theme is merely a limitation.
Can we go headless for part of the site?
Hybrid approaches exist and add their own complexity — two systems to maintain rather than one. It is a real option and not a simplification.
How should success be measured?
By whatever the specific capability was meant to achieve — conversion on the configurator, engagement with merged content — rather than by the architecture itself.
Where should I verify current capabilities?
Shopify’s own developer documentation. Framework capabilities, hosting and API versions change, and third-party descriptions date quickly.

Sources and further reading

  1. Google Search Essentials — SEO starter guide
  2. Google: creating helpful, reliable, people-first content
  3. Google: intro to structured data
  4. Google: LocalBusiness structured data
  5. Google: FAQPage structured data
  6. Google: Article structured data
  7. Google: Product structured data
  8. Google: title links in search results
  9. Google: control your snippets
  10. Google: robots.txt introduction
  11. Google: sitemaps overview
  12. Google: consolidate duplicate URLs
  13. Google: redirects and Search
  14. Google: JavaScript SEO basics
  15. Google: multi-regional and multilingual sites
  16. Google Search Central Blog
  17. Google: get started with Search Console
  18. Google: how local search results are determined
  19. Google Business Profile: prohibited and restricted content
  20. Google Business Profile: address and service area guidelines
  21. Google Business Profile: review policy
  22. Google Business Profile: add or edit categories
  23. Google Ads: location targeting settings
  24. Google Ads: about negative keywords
  25. Google Ads: about Quality Score
  26. Google Ads: importing offline conversions
  27. Google Ads: about Smart Bidding
  28. Google Ads: about Performance Max
  29. Google Local Services Ads: eligibility and screening
  30. Google Ads: keyword match types
  31. Google Analytics 4: about conversions
  32. Google Analytics 4: attribution models
  33. US Census Bureau QuickFacts: New Jersey
  34. US Census Bureau: American Community Survey
  35. US Census: Statistics of US Businesses
  36. Bureau of Labor Statistics: New Jersey data
  37. BLS: Occupational Employment and Wage Statistics
  38. NJ Department of Labor: labor market information
  39. New Jersey Business Action Center
  40. US Small Business Administration: New Jersey district
  41. USA.gov: business resources
  42. web.dev: Core Web Vitals explained
  43. web.dev: Largest Contentful Paint
  44. web.dev: Cumulative Layout Shift
  45. web.dev: Interaction to Next Paint
  46. Google PageSpeed Insights
  47. Google Rich Results Test
  48. Google Search Console
  49. W3C Markup Validation Service
  50. Schema.org: LocalBusiness type
  51. Schema.org: Service type
  52. Schema.org: FAQPage type
  53. Schema.org: HowTo type
  54. W3C: WCAG 2.2 quick reference
  55. FTC: CAN-SPAM Act compliance guide
  56. FCC: telemarketing and robocall rules (TCPA)
  57. FTC endorsement guides — reviews and testimonials
  58. FTC: rule on consumer reviews and testimonials
  59. HHS: HIPAA guidance on online tracking technologies
  60. New Jersey Courts: attorney advertising guidelines
  61. New Jersey DCA: construction codes and permits
  62. New Jersey Home Improvement Contractor registration
  63. New Jersey Division of Consumer Affairs
  64. TikTok for Business
  65. TikTok Creative Center
  66. TikTok Ads Help Center
  67. TikTok Community Guidelines
  68. TikTok Terms of Service
  69. TikTok Privacy Policy
  70. TikTok Safety Center
  71. TikTok Transparency Center
  72. TikTok Creator Portal
  73. TikTok Newsroom
  74. TikTok for Developers
  75. TikTok advertising solutions
  76. TikTok Creator Marketplace
  77. TikTok Business Center
  78. TikTok for Business blog
  79. TikTok Creative Center: top ads
  80. TikTok Branded Content policy
  81. TikTok Shop for sellers
  82. Instagram for Business
  83. Instagram for Creators
  84. Instagram Help Center
  85. About Instagram
  86. Meta Business Suite
  87. Meta Business Help Center
  88. Meta Transparency Center
  89. About Meta
  90. Meta: Instagram platform docs
  91. YouTube Creators
  92. YouTube Official Blog
  93. YouTube Shorts help
  94. How YouTube Works
  95. YouTube Studio
  96. LinkedIn Marketing Solutions
  97. LinkedIn Help
  98. Pinterest Business
  99. Pinterest Business Help
  100. Snapchat for Business
  101. X for Business
  102. Reddit communities
  103. Reddit for Business Help
  104. ASCAP
  105. BMI
  106. SESAC
  107. Global Music Rights
  108. PRS for Music (UK)
  109. PPL (UK)
  110. SOCAN (Canada)
  111. APRA AMCOS (Australia)
  112. GEMA (Germany)
  113. SACEM (France)
  114. SIAE (Italy)
  115. JASRAC (Japan)
  116. IFPI
  117. RIAA
  118. National Music Publishers Association
  119. Harry Fox Agency
  120. SoundExchange
  121. Music Reports
  122. Epidemic Sound
  123. Artlist
  124. Soundstripe
  125. PremiumBeat
  126. AudioJungle
  127. Free Music Archive
  128. Creative Commons
  129. Incompetech
  130. FTC: advertising and marketing
  131. FTC: disclosures 101
  132. FTC: endorsement guides
  133. FTC: consumer reviews rule
  134. FTC: advertising FAQs
  135. US Copyright Office
  136. US Copyright Office: DMCA
  137. US Copyright Office: music FAQ
  138. US Copyright Office: fair use FAQ
  139. USPTO: trademarks
  140. UK Advertising Standards Authority
  141. ACCC (Australia)
  142. Competition Bureau Canada
  143. GDPR overview
  144. California Consumer Privacy Act
  145. COPPA
  146. FTC: children’s privacy
  147. W3C Web Accessibility Initiative
  148. W3C: WCAG
  149. W3C: captions
  150. W3C: making audio and video accessible
  151. ADA.gov
  152. WebAIM
  153. Epilepsy Foundation
  154. Pew Research: internet and technology
  155. DataReportal
  156. US Census Bureau
  157. US Bureau of Labor Statistics
  158. Interactive Advertising Bureau
  159. Think with Google
  160. Google Trends
  161. Nielsen insights
  162. Schema.org: VideoObject
  163. Schema.org: SocialMediaPosting
  164. Schema.org: MusicRecording
  165. Schema.org: HowTo
  166. Schema.org: FAQPage
  167. Schema.org: Organization
  168. Google: video best practices
  169. Google: video structured data
  170. CapCut
  171. Adobe Premiere Rush
  172. DaVinci Resolve
  173. Canva
  174. Descript
  175. VEED
  176. Kapwing
  177. Otter.ai
  178. Later
  179. Buffer
  180. Hootsuite
  181. Sprout Social
  182. Google Analytics
  183. Google Search Console
  184. Google Analytics developer docs
  185. GA4: events and conversions
  186. Matomo
  187. Plausible Analytics
  188. Similarweb
  189. UK Information Commissioner’s Office
  190. Office of the Privacy Commissioner of Canada
  191. Australian OAIC
  192. European Data Protection Board
  193. EU data protection
  194. EU Digital Services Act
  195. Ofcom
  196. FCC
  197. AIGA
  198. Nielsen Norman Group
  199. Smashing Magazine
  200. web.dev
  201. MDN: web media
  202. MDN: the video element
  203. ISO 21001 (reference)
  204. Buma/Stemra (Netherlands)
  205. STIM (Sweden)
  206. Teosto (Finland)
  207. Koda (Denmark)
  208. TONO (Norway)
  209. IMRO (Ireland)
  210. SGAE (Spain)
  211. ZAiKS (Poland)
  212. KOMCA (South Korea)
  213. MCSC (China)
  214. CISAC
  215. World Intellectual Property Organization
  216. TikTok: creating videos
  217. TikTok: exploring videos
  218. TikTok: privacy settings
  219. TikTok: growing your audience
  220. TikTok Creator Academy
  221. TikTok Effect House
  222. TikTok for small business
  223. Instagram: Reels help
  224. YouTube: Shorts best practice
  225. How YouTube recommends
  226. Pinterest Predicts
  227. Snapchat for Business
  228. Hootsuite blog
  229. Social Media Examiner
  230. Marketing Week
  231. Adweek
  232. web.dev — Core Web Vitals
  233. web.dev — Largest Contentful Paint
  234. web.dev — Interaction to Next Paint
  235. web.dev — Cumulative Layout Shift
  236. Google Search Central — page experience
  237. MDN — web performance

Get a free marketing proposal

Tell us what you are trying to grow and we will come back with a plan, not a pitch deck. Same-day reply on weekdays.

Our website uses cookies from third party services to improve your browsing experience. Read more about this and how you can control cookies by clicking "Privacy Preferences".
Privacy Preferences
When you visit our website, it may store information through your browser from specific services, usually in form of cookies. Here you can change your privacy preferences. Please note that blocking some types of cookies may impact your experience on our website and the services we offer.
Privacy Policy
You have read and agreed to our privacy policy
Required