Heading 1
Heading 2
Heading 3
Heading 4
Heading 5
Heading 6
Lorem ipsum dolor sit amet, consectetur adipiscing elit, sed do eiusmod tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam, quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse cillum dolore eu fugiat nulla pariatur.
Block quote
Ordered list
- Item 1
- Item 2
- Item 3
Unordered list
- Item A
- Item B
- Item C
Bold text
Emphasis
Superscript
Subscript
The decision on the table is which storefront your next build runs on, and it binds you for years. Integrations, custom components and the skills in your team all follow from it. Switching later means rebuilding the front end, although your product data, promotions and customer accounts on the platform carry over whichever way you go.
The difference sits in where the storefront code runs
SFRA, the Storefront Reference Architecture, runs on the commerce platform itself. Its pages are rendered on the server by B2C Commerce, and extensions come as cartridges, the modules that add functionality. It succeeded SiteGenesis, the legacy architecture many older Salesforce shops still run on.
Composable Storefront (PWA Kit) runs as a separate React application on Managed Runtime, the Salesforce hosting service for headless storefronts. It asks Commerce Cloud (Agentforce Commerce) for products, prices and baskets through APIs. That separation is the core of headless commerce on Composable Storefront, and most practical differences follow from it.
SFRA has the deeper integration ecosystem
SFRA's biggest practical advantage is the number of ready-made integrations. Payment providers, tax engines, ratings and reviews, and many other services offer SFRA cartridges that plug into the storefront with configuration and limited development. That shortens the build and spreads maintenance across the provider's own releases.
For Composable Storefront, the picture varies by provider. Many services now support headless storefronts through their own APIs, while others still expect a cartridge. Check each integration on your roadmap individually. Every one that needs custom work adds build effort and a line of maintenance you own.
Each storefront asks for a different team
SFRA work needs developers who know the B2C Commerce platform, its server-side scripting and its cartridge model. Composable Storefront needs front-end developers who work in React and understand how to consume commerce APIs, alongside the platform skills that the back end still requires.
The operating model changes with it. SFRA releases storefront and commerce logic together. Composable Storefront gives the front end its own release cycle, which is faster when you use it and a second process to manage either way. Our Build teams stay on a project from start to finish, with no rotations. That matters most on Composable Storefront, where knowledge of both sides has to stay in one team. Whether your organisation is ready for that second process is covered in deciding whether headless fits you.
Speed and search visibility depend on the build
Both storefronts can be fast, and both can be slow. SFRA serves complete pages from the server, which search engines read easily. Composable Storefront renders the first page on the server and then navigates like an app, which feels quick to shoppers once the first page has loaded.
What decides the outcome is the weight of what you add: scripts, tags, images and custom components. A storefront choice made for performance alone rarely holds up, because implementation quality moves page speed more than the architecture does.
