PWA Kit ou SFRA: Como Escolher a Arquitetura Certa no SFCC

A escolha entre PWA Kit (Composable Storefront) e SFRA no Salesforce Commerce Cloud não é uma decisão de preferência técnica. É uma decisão de arquitetura que vai definir seu custo de manutenção, sua velocidade de evolução e o teto de performance do storefront pelos próximos anos. A documentação oficial da Salesforce apresenta as duas como pontos de partida equivalentes, cada uma com seu caso de uso recomendado. Na prática, porém, as implicações para o time que vai manter o código no dia a dia são bem diferentes.

Se você está avaliando qual arquitetura usar no próximo projeto SFCC (ou decidindo se vale migrar um storefront existente), a resposta certa depende de três variáveis concretas. São elas: o perfil da sua equipe, a urgência do time to market e o quanto a experiência de front-end é um diferencial competitivo para o negócio. Este artigo compara os trade-offs reais entre as duas arquiteturas, sem recomendar uma "vencedora" universal.

SFRA e PWA Kit: duas arquiteturas, dois modelos de desenvolvimento

SFRA (Storefront Reference Architecture) é uma arquitetura server-side, baseada no padrão MVC. Ela renderiza HTML e JavaScript diretamente no servidor, usando o framework Bootstrap e jQuery para a camada de UI. Segundo a Salesforce, o SFRA foi desenhado a partir de uma análise de dados de mais de 2.000 storefronts mobile. O foco foi identificar os padrões de UX que mais convertem em telas pequenas (Fonte: SFCC Developer Guide). É a arquitetura padrão desde que substituiu o SiteGenesis, e ainda é o ponto de partida mais comum em implementações SFCC.

PWA Kit foi lançado em 2021 como alternativa ao SFRA e segue o modelo composable/headless. Nele, o front-end roda de forma desacoplada do back-end, consumindo dados via SCAPI (Salesforce Commerce API), com renderização em React e execução no Managed Runtime da Salesforce (MRT). Isso muda fundamentalmente quem escreve o quê. Em vez de templates server-side com lógica de negócio misturada à apresentação, você tem uma API contract clara entre o catálogo/checkout (back-end) e a experiência de compra (front-end).

Vale registrar que a Salesforce vem evoluindo essa linha composable para uma nova geração (Storefront Next, com React Router 7 e React 19). Isso reforça que o modelo headless é a direção estratégica da plataforma, mesmo que o PWA Kit continue sendo a opção madura e amplamente documentada hoje.

Time to Market: onde o SFRA ainda ganha

Para quem precisa lançar rápido, o SFRA tem uma vantagem estrutural: vem com template totalmente funcional e integrações pré-configuradas. Isso reduz custo de projeto e acelera o go-live. Se sua equipe já tem experiência prévia com SFRA, o reaproveitamento de skills e código de implementações anteriores é imediato. Campanhas e promoções podem ser lançadas com envolvimento mínimo de desenvolvimento.

O PWA Kit inverte essa equação no curto prazo. Exige montar (ou herdar) uma base de componentes React, configurar a integração via SCAPI e validar o pipeline de build/deploy no Managed Runtime antes de ter uma primeira página funcional. O ganho de velocidade do PWA Kit não aparece no primeiro sprint: aparece nos ciclos seguintes. É quando o desacoplamento entre front-end e back-end permite que times de UI iterem sem depender de deploy no servidor de aplicação SFCC.

Performance e SEO: o trade-off que mais pesa a longo prazo

Aqui está o ponto que mais frequentemente muda a decisão de um tech lead. SFRA renderiza no servidor por padrão, o que historicamente favorece SEO e Core Web Vitals sem esforço extra. O HTML já chega pronto ao navegador.

Mas conforme o storefront cresce (mais lógica de negócio nos controllers, mais integrações de terceiros, mais personalização), o tempo de resposta do servidor tende a aumentar. Otimizar performance em SFRA, nesse cenário, significa otimizar a própria stack Javascript/ISML, com margem de manobra limitada pela arquitetura MVC.

PWA Kit também faz server-side rendering na carga inicial, preservando SEO. Mas usa uma stack moderna baseada em React, o que abre espaço para técnicas de otimização mais finas: code splitting, cache de página no CDN, hidratação seletiva. O trade-off real não é "PWA Kit é mais rápido que SFRA" de forma genérica. É que o PWA Kit dá mais alavancas de otimização para quem tem conhecimento de performance web moderna no time, enquanto o SFRA entrega um teto de performance decente com menos esforço de configuração.

Para quem já sofre com lentidão em produção, independente da arquitetura escolhida, vale entender antes os limites da plataforma SFCC que afetam qualquer storefront. Podem ser eles de infraestrutura compartilhada, rate limit de API ou restrições de customização.

Custo total de propriedade: manutenção versus flexibilidade

A Salesforce posiciona o SFRA como redutor de custo total de propriedade. As atualizações são mais simples por seguir um padrão amplamente documentado e suportado por um ecossistema de conectores plug-and-play através dos cartuchos. Isso é real: manter um SFRA "no padrão", sem customização pesada em cima dos cartridges base, tem custo de manutenção previsível. A dependência de conhecimento especializado em React também é menor.

O custo do PWA Kit se desloca para outro lugar. Você paga mais na montagem inicial (arquitetura, integração SCAPI, pipeline de CI/CD), mas ganha desacoplamento, o que reduz o custo de evoluir a experiência de front-end sem tocar no back-end SFCC. Para operações com catálogo complexo, múltiplas integrações e alta frequência de mudança na camada de apresentação, esse desacoplamento paga dividendos ao longo dos anos. Isso vale para testes A/B, personalização visual e experiências diferentes por mercado. Para uma operação mais estável, com poucas mudanças estruturais no front-end, o custo adicional de manter uma stack composable pode não se justificar.

Quando faz sentido escolher SFRA

SFRA é a escolha mais sólida quando:

O time já domina o padrão MVC, Bootstrap e jQuery, e não há pressão para reconstruir conhecimento
O time to market é a prioridade número um do projeto
A experiência de front-end segue padrões de mercado, sem necessidade de diferenciação visual extrema
A operação depende apenas de conectores e apps plug-and-play do ecossistema SFCC

Quando faz sentido escolher PWA Kit (Composable Storefront)

PWA Kit tende a compensar o investimento inicial quando:

A experiência de front-end é parte da proposta de valor da marca, não um commodity
Há necessidade de reutilizar a mesma camada de front-end em múltiplos touchpoints ou mercados
O roadmap de produto exige iteração rápida na UI sem depender do ciclo de deploy do back-end SFCC
A equipe técnica já tem (ou vai construir) maturidade em React e arquitetura headless

E se você já está rodando SFRA em produção?

Migrar de arquitetura não precisa ser um evento de "big bang" com o site fora do ar. Times maduros costumam adotar abordagens híbridas, mantendo partes do storefront em SFRA enquanto migram jornadas críticas (PDP, checkout) para PWA Kit de forma incremental. Se essa é a sua realidade, vale entender em detalhe como conduzir essa transição sem interromper a operação. Já cobrimos esse processo em migrar de SFRA para PWA Kit sem parar o e-commerce.

Conclusão

Não existe arquitetura certa em abstrato. Existe a arquitetura certa para o estágio do seu negócio, a maturidade do seu time e a urgência do prazo. SFRA entrega previsibilidade e velocidade inicial. PWA Kit entrega flexibilidade e teto de performance mais alto para quem tem (ou vai ter) conhecimento especializado para explorá-lo. A decisão errada custa caro em retrabalho e dívida técnica, não em ferramenta em si.

Se essa decisão está na sua mesa agora e o trade-off entre time to market, performance e custo de manutenção ainda não está claro para o seu contexto específico, vale conversar com quem já tomou essa decisão em produção diversas vezes. Agende uma conversa com a Develoci para avaliar qual arquitetura se encaixa na realidade técnica e comercial do seu projeto.