Every Shopify storefront renders one of two ways: Liquid, Shopify's server-side templating language that themes are built in, or a front end you build yourself that pulls data through the Storefront API. This is the architectural fork behind "should we go headless?" — and getting it right matters, because it sets your speed, your flexibility, your cost and your maintenance for years. Here's how the two actually compare and how I decide.
How each one works
Liquid
Shopify renders your pages on its servers from Liquid templates and sends finished HTML to the browser. The theme is the storefront. You get Shopify's hosting, its CDN, checkout, SEO handling and platform features for free, and you work within the theme architecture. This is how the overwhelming majority of stores run — and for good reason.
Storefront API
A GraphQL API that exposes products, collections, cart and checkout as data. You build the front end — often React via Hydrogen, or another framework — and query Shopify for what you need. Shopify becomes the commerce engine; the presentation layer is entirely yours. This is "headless," and the Storefront API is the pipe that makes it possible.
The trade-offs, honestly
| Liquid | Storefront API (headless) | |
|---|---|---|
| Control | Within theme architecture | Total over the front end |
| Speed to build | Fast — themes & ecosystem | Slower — you build the layer |
| Performance ceiling | Very good when done well | Higher, if built carefully |
| SEO | Handled by the platform | Yours to get right (SSR needed) |
| Cost & maintenance | Lower | Higher — more moving parts |
| Platform features | Work out of the box | Some you re-implement |
The Storefront API gives you a higher ceiling and a higher floor of effort. Liquid gives you most of the performance for a fraction of the work. Pick the ceiling only when you'll actually use it.
When Liquid is the right answer
For most stores. If a well-built theme meets your design and your performance goals, Liquid is faster to build, cheaper to run, and comes with the platform's SEO and features handled. Reaching for the Storefront API to render a fairly standard store adds cost and complexity for a ceiling you won't touch. A slow Liquid store is usually a performance problem to fix, not a reason to go headless.
When the Storefront API earns its keep
- A front end Liquid can't express. Highly interactive, app-like experiences or a design system that fights the theme architecture.
- You're already in React. An existing app or design system you want commerce to live inside.
- Multiple front ends, one commerce backend. Web, mobile, kiosk, marketplace all reading the same Storefront API.
- Content-heavy builds. Pairing Shopify commerce with a separate CMS, stitched together in your own front end — often alongside metaobjects for structured data.
You don't have to pick one for everything
A useful middle path: run the storefront in Liquid and use the Storefront API for specific pieces — a fast custom cart, a live search, a bespoke product configurator — inside an otherwise Liquid theme. You get the platform's defaults where they're fine and API-driven control only where you need it. Most stores that "use the Storefront API" use it exactly like this, not as a full headless rebuild.
The SEO caveat
One thing that catches teams out: with the Storefront API you own rendering, which means you own SEO. If the front end renders client-side only, crawlers and Core Web Vitals suffer. Headless done right means server-side rendering so pages arrive as HTML — which is a big part of why frameworks like Hydrogen exist. With Liquid this is simply handled for you.
The honest summary
Liquid vs the Storefront API isn't old vs new — it's two valid tools. Liquid is the right default: most of the performance, a fraction of the effort, platform features included. The Storefront API is the right choice when you have a real reason to own the front end and the budget to maintain it. Choose based on what your store actually needs to do, not on which sounds more modern.