The headless Adobe Commerce storefront has matured into a viable architecture in 2026, but the decisions you make at the start of the project determine whether the headless build is an asset or a liability for the next five years. Most of the headless projects that fail do so because the team chose the framework and the host before they understood the operational implications.
This is not a piece about whether headless is the right answer. The headless question is business-specific, and for many mid-market stores a well-tuned Hyvä storefront is the more pragmatic choice. This is a piece about how to actually build a headless Adobe Commerce storefront with Remix when you have decided headless is the right path.
Bemeir’s Adobe Commerce engineering practice has built headless storefronts on Next.js, Remix, and Hydrogen, and the architecture patterns below are what hold up across the projects we have shipped. Remix specifically has earned a place in our toolkit for its data-loading model, its progressive enhancement story, and its compatibility with Cloudflare Workers and similar edge runtimes.
Why Remix specifically
The headless framework selection conversation usually narrows to three options for Adobe Commerce: Next.js, Remix, and Shopify Hydrogen. Each has trade-offs.
Next.js is the most popular React framework and has the largest ecosystem. Its rendering model has shifted between versions, with the App Router and React Server Components introducing complexity that has caused project delays and architectural rework on multiple projects we have seen. The framework is capable but the team has to track the framework’s own evolution alongside the storefront’s evolution.
Remix is built around web platform fundamentals: forms, HTTP, and progressive enhancement. The data-loading model uses route-level loaders and actions that map cleanly to the request-response lifecycle, which simplifies reasoning about data freshness and caching. The framework changes less frequently than Next.js and the changes are usually backward-compatible.
Hydrogen is Shopify’s own framework, optimized for Shopify storefronts. Some teams use it against non-Shopify backends but the fit is poorer because the framework’s design centers on Shopify’s data model.
For Adobe Commerce specifically, Remix tends to be the cleaner fit because its data-loading model maps well to GraphQL-driven storefronts and its progressive enhancement story is friendly to the kinds of merchandising teams that want predictable behavior. The Remix documentation on data loading is the entry point for understanding the model.
The architecture in one diagram
The headless architecture has six tiers when fully built out.
The browser. The customer’s device, where Remix-rendered HTML is hydrated into a React application.
The edge layer. A CDN with edge compute, typically Cloudflare or Fastly, that serves cached HTML, handles request routing, and runs lightweight authentication and personalization logic close to the user.
The Remix application server. The Node.js or Workers runtime that renders pages, executes route loaders, and talks to backend services.
The API layer. Adobe Commerce’s GraphQL endpoint and REST endpoints, plus any custom APIs the project builds.
The Adobe Commerce backend. The Magento application itself, hosted on Adobe Commerce Cloud or self-hosted.
The data tier. MySQL or MariaDB for transactional data, Redis for session and cache, Elasticsearch or OpenSearch for product search.
Between these tiers, three caches matter operationally. The browser cache for static assets. The edge cache for HTML and API responses where business rules allow. The application-level cache inside Remix loaders for data that can be cached on the application server but not at the edge.
Each cache tier has its own TTL and invalidation strategy, and the strategies have to cooperate. A page that the edge caches for an hour but the Remix loader caches for 10 seconds will sometimes serve stale data. The discipline of writing down the cache topology and tracking what invalidates what is the operational backbone of the headless build.
Caching strategy by data type
The caching strategy is the operational heart of a fast headless Adobe Commerce storefront. The right approach is to categorize every piece of data by how often it changes and how user-specific it is, then map each category to the right cache tier.
Static catalog data, like product names, descriptions, and categories, changes rarely. Cache aggressively at the edge with TTLs of one hour or longer. Invalidate on product updates via webhooks from Adobe Commerce.
Pricing and inventory data changes more frequently but is rarely user-specific (with the exception of B2B). Cache at the edge with shorter TTLs (1 to 5 minutes) or fetch fresh on every request with application-level memoization within the request lifecycle.
Cart and checkout data is user-specific and changes constantly. Do not cache. Always fetch fresh, with the Remix loader pulling from the API on every request.
User-specific data like order history and saved addresses is cached at the application level only, scoped to the user’s session. Do not cache at the edge.
Search results are tricky. The same search query can be cached at the edge for users in the same locale, but search relevance can be personalized for logged-in users. The common pattern is to edge-cache for logged-out users and bypass for logged-in users.
The table below summarizes the caching strategy we typically use on mid-market headless builds.
| Data type | Edge cache | TTL | Invalidation |
|---|---|---|---|
| Product catalog | Yes | 1 hour | Webhook on product update |
| Category pages | Yes | 1 hour | Webhook on category update |
| Pricing (logged-out) | Yes | 5 min | Webhook on price rule change |
| Pricing (B2B logged-in) | No | n/a | Always fresh |
| Search (logged-out) | Yes | 15 min | Webhook on catalog change |
| Search (logged-in) | No | n/a | Always fresh |
| Cart | No | n/a | Always fresh |
| Checkout | No | n/a | Always fresh |
| User profile | App-level only | Session | On user action |
The Cloudflare Workers cache API documentation covers the edge-side mechanics if Cloudflare is your edge provider.
GraphQL discipline
Adobe Commerce’s GraphQL endpoint is the primary data source for a headless Remix storefront. The discipline of how you query it determines performance and maintainability.
Three patterns that hold up across projects.
Query exactly the fields you need. GraphQL lets you over-fetch by accident if you do not stay disciplined. The fields you do not need cost both bandwidth and backend processing time.
Use persisted queries for production. Persisted queries let the client send a query hash rather than the full query string, which reduces request size and makes server-side caching easier. Adobe Commerce supports persisted queries through Magento’s built-in mechanisms or through Apollo’s persisted-query layer.
Co-locate queries with the routes that use them. Remix’s loader-per-route model encourages this naturally. Putting the query next to the loader keeps the data flow obvious and prevents the “query somewhere else” anti-pattern that complicates refactoring.
The Adobe Commerce GraphQL documentation is the platform-specific reference. The Apollo Client documentation on persisted queries covers the broader pattern.
Edge runtime considerations
Where you run Remix matters. The options for headless Adobe Commerce in 2026 are Node.js on traditional hosting (Vercel, Fly, AWS), Cloudflare Workers, and Deno Deploy. Each has trade-offs.
Node.js on traditional hosting is the most familiar and supports the broadest range of libraries. The deployment latency to the user is bounded by the location of the host, which is the trade-off versus edge runtimes.
Cloudflare Workers runs the application at the edge, which dramatically reduces TTFB for users far from the origin. The constraints are stricter: no Node.js APIs, limited package compatibility, and CPU time limits per request. Remix has solid Workers compatibility, but the discipline of staying within Workers constraints affects how you write the application.
Deno Deploy is similar in profile to Workers, with slightly more permissive constraints and a smaller ecosystem.
For most mid-market Adobe Commerce headless builds, Cloudflare Workers is the right choice if the team is comfortable working within the constraints. The latency improvement for international users is meaningful, and the operational story is simpler than managing Node.js infrastructure.
Real-user monitoring is non-negotiable
The headless architecture introduces complexity that synthetic monitoring will not catch. Real User Monitoring is the only way to know what your actual customers are experiencing.
The metrics that matter are LCP, INP, and TTFB at the 75th percentile, broken out by geography, device class, and connection type. The patterns that produce slow LCP for mobile users in specific regions are not visible without RUM.
Several tools handle RUM well in 2026. The web-vitals library gives you raw data that you can ship to any analytics destination. Cloudflare Web Analytics is free and integrates with Workers. Datadog RUM and New Relic Browser are paid options with more sophisticated correlation between frontend and backend metrics.
Wire RUM into the build from the start. Headless projects that defer RUM until launch routinely discover performance issues in production that would have been visible in development if measurement had been earlier.
Authentication and personalization at the edge
Authentication patterns in a headless Adobe Commerce store need to handle three states: logged-out, logged-in via traditional cookie session, and logged-in via token-based API authentication.
The pattern that works on Cloudflare Workers is to use Adobe Commerce’s customer token endpoint to mint a JWT on login, store the JWT in an HttpOnly cookie, and verify the JWT at the edge for each request. The verification can happen in a Workers middleware before the Remix application runs, which lets you make cache decisions at the edge based on logged-in status.
For personalization that needs more than the binary logged-in flag, the pattern is to store a small profile blob (customer group, locale, currency, recently viewed) in a separate cookie or in KV storage at the edge. The Remix loader can read this blob without an origin round-trip and personalize the response accordingly.
Personalization that requires real-time data from the backend (like cart contents or order history) cannot be edge-cached and should fetch fresh on every request. The discipline is to identify what can be edge-personalized cheaply and what cannot, and to design the page composition so that the cacheable parts dominate the user experience.
What we ship
A typical mid-market headless Adobe Commerce build with Remix that ships well looks like this. LCP at 1.2 to 1.8 seconds on mobile P75, INP under 100ms on mobile P75, TTFB under 200ms on edge cache hits and under 600ms on edge cache misses. Build size under 100KB of JavaScript on the critical path, with the rest lazy-loaded. Cache hit ratio above 80 percent on category and product pages for logged-out users. Deployment frequency of multiple times per day, with feature flags for risk management.
The numbers are achievable, but they require the discipline above to actually land in production. Headless projects that skip the cache topology, skip the GraphQL discipline, or defer RUM until launch routinely ship at twice the LCP and half the cache hit ratio of well-disciplined builds.
If you are evaluating headless against Hyvä for your specific store, the conversation should be honest. Hyvä is the right answer for most mid-market stores in 2026 because it delivers most of the performance gains of headless with much lower operational complexity. Headless wins when the team has dedicated frontend engineering, when the storefront needs deep customization that Hyvä’s theme model does not support, or when the business has specific reasons to decouple the storefront from Adobe Commerce’s release cycle. Bemeir’s Shopify Plus practice, Shopware practice, and BigCommerce practice all have headless patterns that are platform-specific in detail but architecturally similar. The framework above is portable. The patterns hold.
