Headless Shopify Architecture Tradeoffs

An honest look at the architecture decisions behind building headless Shopify storefronts with Next.js, versus the 10+ Liquid theme stores I built at two agencies. When headless makes sense, and when it really doesn't.

I've built one headless Shopify storefront (Hytura) using Next.js with Shopify's Storefront API as the backend, and more than 10+ Liquid-based Shopify stores across my time at two different Shopify agencies. Having worked extensively on both sides, I have a pretty clear view of when headless makes sense and when it doesn't. The short version: headless Shopify is powerful but expensive in engineering complexity, and for the majority of stores, it's not the right choice. ## When Headless Actually Makes Sense Headless Shopify is worth considering when the storefront needs to do something that Shopify's Liquid theme system fundamentally can't. For Hytura, the requirements included: - **A custom design system** that couldn't be achieved within Liquid's template constraints. The brand had specific interaction patterns, product customization flows, and animated transitions between collections that would have been hacky at best in a Liquid theme. - **Integration with external systems** beyond what Shopify apps provide. Hytura integrates with a custom inventory management system and pulls content from a headless CMS for editorial-style product storytelling. - **Performance requirements** that Liquid themes struggle with. Shopify's hosted themes have gotten faster, but they still load Shopify's full JavaScript bundle. With a headless frontend, I control every kilobyte. If none of these apply, and the store needs a clean product catalog with standard checkout, Shopify's native theme system with Dawn or a premium theme is almost certainly the better choice. The operational overhead of headless doesn't justify marginal performance gains. ## Hydrogen vs. Custom Next.js Shopify's own headless framework, Hydrogen, is built on Remix and is the "official" way to go headless. I evaluated it for Hytura and went with custom Next.js instead for practical reasons. **Deployment flexibility.** Hydrogen is designed for Shopify's Oxygen hosting platform. You can deploy it elsewhere, but you lose some of the optimized caching and Storefront API integration. I deploy on Vercel, and Next.js is a first-class citizen there. The deployment pipeline, preview environments, and edge caching just work without configuration. **Ecosystem.** Next.js has a larger ecosystem of libraries, examples, and community knowledge. When I hit a problem with ISR cache invalidation or image optimization, there are hundreds of Stack Overflow answers and GitHub discussions. Hydrogen's ecosystem is smaller, and troubleshooting can mean reading framework source code. **Team familiarity.** The merchants I work with sometimes hire other developers for maintenance. Finding a Next.js developer is significantly easier than finding a Hydrogen developer. The tradeoff: Hydrogen has tighter integration with Shopify's Storefront API, including built-in components for cart management, product variants, and checkout. With Next.js, I built these from scratch, which took meaningful development time. ## The Theme Editor Problem This is the single biggest reason most stores should not go headless. Shopify's Liquid themes come with a visual theme editor where merchants can rearrange sections, add content blocks, and customize pages without touching code. This is not a minor convenience. For the 10+ Liquid stores I built at two agencies, the theme editor was the feature merchants used every day. Go headless and you lose all of that. For Hytura, I built a section-based CMS system that gives the merchant comparable control. Each page is composed of ordered sections, each section has a type (hero, product grid, testimonials, rich text, etc.), and each type has configurable fields. ```typescript type Section = | { type: "hero"; fields: { heading: string; image: ShopifyImage; cta: Link } } | { type: "product-grid"; fields: { collection: string; columns: 2 | 3 | 4 } } | { type: "rich-text"; fields: { content: string; alignment: "left" | "center" } } | { type: "testimonials"; fields: { items: Testimonial[] } }; interface Page { slug: string; title: string; sections: Section[]; } ``` Merchants edit page content through Shopify's metafields or a connected headless CMS. The Next.js frontend fetches the section list at build time (ISR) and renders each section using a component map. Adding a new section type means building one React component and registering it. This works well enough, but it's a significant amount of infrastructure to replicate functionality that Shopify themes provide out of the box. For Hytura, building the CMS section system took about three weeks. Three weeks that wouldn't have been needed with a Liquid theme. ## Lessons from 10+ Liquid Stores Working at two Shopify agencies, I built and maintained more than 10 production Liquid storefronts across various industries. This experience is what shaped my honest view of headless. A few things stood out: **Liquid is more capable than developers give it credit for.** With Shopify's Online Store 2.0 architecture, sections and blocks are flexible enough for most store requirements. Custom sections with configurable schemas, dynamic data sources, and JavaScript-enhanced interactions can handle complex product pages, landing pages, and collection filtering without going headless. **Merchants live in the theme editor.** Every merchant I worked with spent time rearranging homepage sections, updating banners for sales, and tweaking product page layouts. The theme editor is not optional for most stores. Any headless solution that doesn't provide an equivalent (and none truly do) creates ongoing dependency on a developer for content changes. **The Shopify app ecosystem is underrated.** Reviews, wishlists, loyalty programs, size guides, currency converters. There are apps for everything, and they integrate into Liquid themes with minimal effort. Go headless and you either find API-only alternatives (which exist for some apps but not all), build features custom, or tell the merchant it's not available. This is a recurring cost that's easy to underestimate. **Development speed and maintainability.** A Liquid theme can go from design to production in two to four weeks. A headless storefront with equivalent features takes eight to twelve weeks minimum. For small and medium-sized stores, this time difference translates directly into wasted budget. ## Performance: Where Headless Shines Performance is the clearest win for headless. Hytura consistently scores 95+ on Lighthouse performance, compared to the 60-75 range typical for Shopify Liquid themes. **Image optimization.** Next.js's `Image` component with automatic WebP/AVIF conversion, responsive `srcset`, and lazy loading. Shopify's CDN serves images well, but the native theme image handling doesn't do format negotiation or proper responsive sizing without manual Liquid code. **ISR for collection and product pages.** Product pages are statically generated and revalidated every 60 seconds. This means most page loads are served from the edge cache as static HTML. When the merchant updates a product title or price, the change appears within a minute without a full rebuild. **Bundle size control.** A Shopify Liquid theme loads Shopify's analytics, payment buttons, and theme JavaScript whether you need them or not. With a headless frontend, my JavaScript bundle is under 90KB gzipped for the entire storefront. First contentful paint is consistently under 1.2 seconds. **Edge caching with stale-while-revalidate.** I configure Vercel's edge cache to serve stale content while revalidating in the background. During a product launch or sale, the storefront handles traffic spikes without breaking a sweat because edge-cached pages require no origin compute. ## The Honest Complexity Cost Here's what I underestimated when starting the headless project: **Checkout is still Shopify's.** Even with a headless storefront, checkout happens on Shopify's domain. The visual transition from your custom storefront to Shopify's checkout page is jarring unless you spend significant time on checkout extensibility (Shopify Functions, checkout UI extensions). I spent two to three days just making the checkout feel like a natural continuation of the storefront. **Inventory and pricing sync.** Shopify is the source of truth for inventory and pricing, but with ISR caching, the storefront might show a stale price or an "in stock" status for a sold-out product. I built a client-side revalidation hook that checks inventory status when a product page mounts, but this adds complexity and can cause a flash of incorrect state. **Merchant onboarding.** Liquid theme merchants can use Shopify's visual editor. Headless merchants need documentation, sometimes training, and occasionally my help to update content. I've reduced this friction with the section-based CMS, but it's not as intuitive as Shopify's native editor. ## When It's Not Worth It After building both headless and Liquid stores, my recommendation is straightforward. I'd only suggest headless if at least two of these are true: 1. The design requires custom interactions that Liquid can't support 2. Performance is a measured conversion bottleneck (not just a Lighthouse vanity metric) 3. The store integrates with external systems that need frontend-level integration 4. The team has ongoing engineering capacity to maintain the headless stack For a store doing under $1M in annual revenue with a small team, the complexity cost of headless almost certainly outweighs the benefits. A well-optimized Dawn theme with a few custom sections will get you 80% of the performance at 20% of the engineering cost. I don't regret going headless for Hytura. It had genuine requirements that justified it. But across those 10+ Liquid stores I've built, most of them would have been worse off with a headless approach. The practical reality is that Shopify's theme editor, app ecosystem, and development speed matter more than raw performance numbers for the majority of e-commerce businesses.

Blog

Browse posts in explorer mode. Click a post to open its article in a new window with metadata, images, and code blocks.

Post List

Loading workspace