On this page
If your storefront runs on Shopify Hydrogen, the size-recommendation apps you find on the Shopify App Store almost never work out of the box. They ship as theme app extensions, and Hydrogen doesn't render Liquid themes — it renders React components against Oxygen. That mismatch trips up a lot of merchants who assume "works with Shopify" means "works with my storefront," and it costs real return-rate reduction while the gap goes unfixed.
Why Theme App Extensions Don't Apply to Hydrogen
Theme app extensions inject blocks into the Online Store 2.0 theme editor. They rely on Liquid, theme sections, and the Shopify theme architecture to place a widget on a product page. Hydrogen storefronts skip that layer entirely — they're custom React applications built on Remix conventions, deployed to Oxygen, and they pull data through the Storefront API rather than rendering server-side Liquid templates.
That means any app whose entire integration story is "install and it appears on your PDP" simply has nothing to hook into on a Hydrogen build. There's no theme editor slot for it to occupy. This is a well-documented consequence of Shopify's own headless architecture split between theme-based storefronts and composable/Hydrogen storefronts — see Shopify's own guidance on headless commerce for how differently the two paths are meant to be built.
What Actually Works: Component + API
The workable pattern for Hydrogen is the same one used for any headless storefront: treat the size recommender as a UI component you own, backed by a hosted API you call. You're not installing an app — you're integrating a widget.
- A lightweight React component rendered inside your product route
- A fetch call to the sizing API, passing product identifiers and (optionally) a brand's size chart reference
- A recommendation payload returned and rendered as a size suggestion, confidence indicator, or fit note
- Analytics events fired to your existing tracking layer so recommendation impact is measurable
This is functionally identical to how you'd add fit tools to a headless storefront via API on any other stack — Next.js, Nuxt, or a custom SPA. Hydrogen isn't special here; it's just another headless frontend consuming a REST or GraphQL endpoint.
Step-by-Step: Wiring the Component into a Product Route
1. Identify Where Product Data Already Lives
Hydrogen product routes typically load product data via a loader function that queries the Storefront API. You need the product's variant IDs, and ideally a size-chart mapping, available in that same loader response so you're not making a second round trip on every render.
2. Add the Recommender as a Client Component
Render the size widget as a client-side component that receives product and variant data as props. Keep it decoupled from your loader logic — it should only need an identifier and a callback for when a size is selected.
3. Call the Sizing API on Mount or on Interaction
Two common patterns: fetch a recommendation proactively when the product page loads, or wait until the shopper opens a "find my size" modal. The second pattern is lighter on API calls and matches shopper intent more precisely, since you're not spending a lookup on visitors who never engage with sizing.
4. Pass the Result into the Variant Selector
The payoff moment is connecting the recommended size to Hydrogen's variant selection state, so a shopper who accepts the suggestion has their size pre-selected rather than having to re-enter it manually. This single UX step is often the difference between a recommendation that gets used and one that gets ignored.
5. Instrument for Measurement
Fire events for widget-shown, recommendation-returned, size-accepted, and size-overridden. Without this, you can't tell whether the integration is reducing size-related returns or just adding a UI element nobody touches.
Headless Sizing Approach vs. Traditional App Install
| Aspect | Theme App Extension (non-headless) | Component + API (Hydrogen) |
|---|---|---|
| Install method | App Store install, auto-injects into theme | Manual component integration in codebase |
| Rendering | Liquid section in theme editor | React component in product route |
| Data flow | App reads theme/product data automatically | Developer passes product/variant data explicitly |
| Deployment | No redeploy needed | Requires a storefront deploy to ship |
| Flexibility | Limited to app's UI options | Full control over placement, styling, and triggers |
| Maintenance | Vendor-managed | Shared — API managed by vendor, UI managed by your team |
The trade-off is upfront engineering time for long-term control. Once the component is in place, updating copy, styling, or trigger logic is a normal frontend change rather than a support ticket to an app vendor.
Where This Fits in a Broader Fit Strategy
A size recommender on the PDP is one entry point, but it shouldn't be the only one. Many Hydrogen merchants also expose sizing at checkout as a last-chance confirmation, which catches shoppers who skipped the PDP widget or changed their mind on size mid-cart. Because Hydrogen checkout customization has its own constraints (Checkout Extensibility rather than raw component control), that integration point needs separate handling from the PDP widget described above — plan for it as a distinct implementation task, not an afterthought.
Common Pitfalls in Hydrogen Integrations
- Assuming the sizing vendor's "Shopify app" listing covers Hydrogen — always confirm API-first support before committing engineering time
- Fetching recommendations on every page load instead of on-demand, which adds unnecessary API load and slows the PDP
- Failing to pass variant IDs consistently between the loader and the client component, causing recommendation-to-variant mismatches
- Skipping analytics instrumentation, which makes it impossible to prove ROI to stakeholders after launch
The Business Case for Doing This Properly
Fit-related uncertainty remains one of the largest drivers of apparel returns industry-wide, and headless merchants are not exempt just because their stack is more modern — if anything, the integration gap means many Hydrogen storefronts are running with weaker size guidance than their Liquid-theme competitors. Retailers report that pre-purchase sizing confidence measurably reduces size-related return volume, a pattern widely discussed in apparel returns research such as the National Retail Federation's return statistics. For a Hydrogen store investing in a modern, fast, componentized frontend, leaving the size-recommendation gap unaddressed is an odd place to cut corners — it's a returns-cost line item hiding behind an architecture decision.
Frequently Asked Questions
Does Shopify's own Hydrogen framework include size recommendation out of the box?
No. Hydrogen is a frontend framework for building custom storefronts against the Storefront API — it doesn't include merchandising features like size recommendation. Any sizing capability has to be added as a component you build or integrate, connected to a sizing API of your choice.
Can I still use a Shopify App Store sizing app on Hydrogen?
Only if the app offers an API-first or headless integration path separate from its theme app extension. Many popular sizing apps are built exclusively for Liquid themes, so check the vendor's documentation for explicit Hydrogen or headless support before assuming compatibility.
How long does a typical Hydrogen size-recommender integration take?
For a team already comfortable with the Hydrogen codebase, a basic PDP widget integration — component plus API call plus variant wiring — typically takes a few days of focused development. Adding checkout-stage sizing and full analytics instrumentation extends that timeline, since Checkout Extensibility has separate constraints from the storefront.
Do I need a different sizing API for Hydrogen than for a Liquid theme?
No — the underlying sizing API and recommendation logic can be identical across both. What changes is the integration layer: a Liquid theme consumes it through a theme app extension, while Hydrogen consumes it through a component that calls the same API directly.