SFRA or PWA Kit? The decision that shapes your architecture for years to come
A technical guide for Tech Leads who need to justify this choice to the business, without turning it into technical debt down the road.
Talk to a team that's migrated bothWhy this choice is more strategic than technical
Salesforce Commerce Cloud (SFCC) currently offers two official frontend paths: SFRA (Storefront Reference Architecture), the server-side rendering model with ISML templates that's been the standard since 2018, and PWA Kit, the React-based headless framework behind Composable Storefront, built on top of the Salesforce Commerce API (SCAPI) (according to Salesforce's official documentation).
The wrong choice doesn't show up in the first sprint. It shows up 18 months later, when the team needs to ship a personalization feature that SFRA doesn't handle well, or when the cost of maintaining a custom React build outweighs the performance gains that justified the migration in the first place.
This guide breaks down the technical criteria that actually matter for this decision: architecture, performance, SEO, team learning curve, maintenance cost, and the scenarios where each option wins.
SFRA vs PWA Kit: a straightforward technical comparison
The criteria that most impact architecture decisions for fast-growing e-commerce teams.
| SFRA | PWA Kit | |
|---|---|---|
| Rendering model | Server-side rendering (SSR) with ISML templates, processed directly on the SFCC server. | React with SSR via Managed Runtime; clear separation between frontend and backend through the API. |
| Team learning curve | Requires proficiency in ISML, the B2C Commerce Script API, and SFCC-specific conventions. Lower barrier for teams coming from Java/Demandware. | Requires solid command of React, Node.js, and headless architecture. Higher barrier for teams without experience in modern SPA/SSR. |
| Perceived performance (Core Web Vitals) | Good enough for most cases, but limited by the traditional server request/response cycle. | Greater control over LCP, CLS, and TTFB, thanks to bundle optimization, API caching, and granular rendering. |
| UI/UX flexibility | Limited by the ISML template structure and pre-defined components. Deep customizations require more effort. | Full freedom in React componentization; ideal for rich experiences, installable PWAs, and complex micro-interactions. |
| Initial delivery speed (MVP) | Faster for standard storefronts, leveraging SFRA's ready-made cartridges and features. | Slower to start: requires building the presentation layer from scratch on top of the API. |
| Technical SEO | Native SSR favors indexing without extra configuration effort. | SSR via Managed Runtime also delivers good SEO, but requires attention to hydration and dynamic meta tags. |
| Medium-term maintenance cost | Tends to grow as customizations pile up on top of a rigid server-side architecture. | More predictable when the separation of concerns between API and frontend is respected from the start. |
| Integration with channels beyond web (app, IoT, voice) | Not designed for this; requires significant additional work. | Headless architecture makes it easier to reuse the same API for other channels. |
| Maturity and official Salesforce support | Historical reference point, extensive documentation, and a well-established community since 2018. | Active Salesforce investment as the strategic path toward composable commerce, but with fewer years of production maturity. |
How to decide: a 5-question technical checklist
Before choosing, work through these questions with your architecture team and product leadership.
How much UI customization does the product roadmap actually require?
If the business plans to build UI experiences that go well beyond the standard e-commerce mold (complex configurators, installable PWAs, elaborate micro-interactions), PWA Kit gives you more freedom. If the needs are those of a well-executed traditional storefront, SFRA delivers that with less engineering effort.
Does the current team have deep expertise in React/Node or in Java/ISML?
Migrating to PWA Kit without people who have real experience in headless React architecture leads to rework and performance bugs that cancel out the theoretical gains. Honestly assess the technical background available before committing to the newer architecture.
What's the timeline for the first release?
Tight MVP deadlines tend to favor SFRA, which already comes with most of the purchase journey built in. PWA Kit pays off the higher upfront investment over longer timelines or when a reusable component base already exists.
Is there a real plan for omnichannel expansion (native app, other touchpoints)?
If the same API layer is going to power a mobile app, kiosks, or other channels down the line, PWA Kit's headless architecture avoids having to rebuild integrations later. If the scope is limited to the web store, this argument carries less weight.
What's the appetite for medium-term technical debt?
SFRA tends to accumulate customizations on top of a rigid foundation; PWA Kit tends to degrade when layer separation isn't respected. No architecture is immune to technical debt, the difference is where it builds up.
Migration isn't a rewrite: you can evolve without stopping the business
Many e-commerce teams see the choice between SFRA and PWA Kit as a single, definitive event. In practice, incremental migrations are possible, validating PWA Kit on specific journeys (search, PDP, checkout) before rolling it out across the entire storefront.
This kind of decision requires real hands-on experience with both architectures, because the trade-offs around performance, caching, and SEO shift from page to page. Allocated specialists who've already been through this migration on other SFCC projects reduce the risk of rework, without requiring you to grow your internal team just for this.
What to do with this comparison
No table replaces an assessment of your specific context: current stack, team maturity, business timeline, and product roadmap. The value of this guide is giving Tech Leads, e-commerce leadership, and business stakeholders a shared technical vocabulary for the conversation.
If the decision between SFRA and PWA Kit is stalled due to a lack of hands-on experience with both architectures within the team, that's exactly the kind of gap that gets solved with specialists allocated per project, without affecting internal headcount or slowing down the decision.
Validate the decision before committing the roadmap
A free technical diagnostic with specialists who've implemented both SFRA and PWA Kit in production helps map out performance, SEO, and maintenance risks before the decision is made, not after.
