PWA Kit vs SFRA en Salesforce Commerce Cloud: cómo elegir la arquitectura correcta

Elegir entre PWA Kit (Composable Storefront) y SFRA en Salesforce Commerce Cloud no es una cuestión de preferencia técnica. Es una decisión de arquitectura que va a definir el coste de mantenimiento, la velocidad de evolución y el techo de rendimiento del storefront durante los próximos años. La documentación oficial de Salesforce presenta ambas como puntos de partida equivalentes, cada una con su caso de uso recomendado. En la práctica, sin embargo, las implicaciones para el equipo que mantiene el código día a día son bastante distintas.

Si estás evaluando qué arquitectura usar en el próximo proyecto SFCC (o decidiendo si vale la pena migrar un storefront existente), la respuesta correcta depende de tres variables concretas: el perfil del equipo, la urgencia del time to market y hasta qué punto la experiencia de front-end es un diferencial competitivo para el negocio. Este artículo compara los trade-offs reales entre ambas arquitecturas, sin declarar una "ganadora" universal.

SFRA y PWA Kit: dos arquitecturas, dos modelos de desarrollo

SFRA (Storefront Reference Architecture) es una arquitectura server-side basada en el patrón MVC. Renderiza HTML y JavaScript directamente en el servidor, usando Bootstrap y jQuery en la capa de UI. Según Salesforce, SFRA se diseñó a partir del análisis de datos de más de 2.000 storefronts mobile, con el objetivo de identificar los patrones de UX que más convierten en pantallas pequeñas (Fuente: SFCC Developer Guide). Es la arquitectura estándar desde que sustituyó a SiteGenesis y sigue siendo el punto de partida más habitual en implementaciones SFCC.

PWA Kit se lanzó en 2021 como alternativa a SFRA y sigue el modelo composable/headless. Aquí el front-end se ejecuta desacoplado del back-end, consumiendo datos vía SCAPI (Salesforce Commerce API), con renderizado en React y ejecución en el Managed Runtime de Salesforce (MRT). Esto cambia por completo quién escribe qué. En lugar de templates server-side con lógica de negocio mezclada con la presentación, tienes un contrato de API claro entre el catálogo/checkout (back-end) y la experiencia de compra (front-end).

Conviene señalar que Salesforce está evolucionando esta línea composable hacia una nueva generación (Storefront Next, con React Router 7 y React 19). Esto refuerza que el modelo headless es la dirección estratégica de la plataforma, aunque PWA Kit siga siendo hoy la opción madura y ampliamente documentada.

Time to Market: dónde el SFRA todavía gana

Para quien necesita lanzar rápido, SFRA tiene una ventaja estructural: viene con un template totalmente funcional e integraciones preconfiguradas. Esto reduce el coste del proyecto y acelera el go-live. Si el equipo ya tiene experiencia previa con SFRA, la reutilización de habilidades y código de implementaciones anteriores es inmediata. Las campañas y promociones pueden lanzarse con una implicación mínima de desarrollo.

PWA Kit invierte esta ecuación a corto plazo. Exige montar (o heredar) una base de componentes React, configurar la integración vía SCAPI y validar el pipeline de build/deploy en el Managed Runtime antes de tener la primera página funcional. La ganancia de velocidad de PWA Kit no aparece en el primer sprint: aparece en los ciclos siguientes, cuando el desacoplamiento entre front-end y back-end permite que los equipos de UI iteren sin depender del deploy en el servidor de aplicación SFCC.

Rendimiento y SEO: el trade-off que más pesa a largo plazo

Aquí está el punto que con más frecuencia hace cambiar de opinión a un tech lead. SFRA renderiza en servidor por defecto, lo que históricamente favorece el SEO y los Core Web Vitals sin esfuerzo extra. El HTML llega ya listo al navegador.

Pero a medida que el storefront crece (más lógica de negocio en los controllers, más integraciones de terceros, más personalización), el tiempo de respuesta del servidor tiende a aumentar. Optimizar el rendimiento en SFRA, en ese escenario, significa optimizar la propia stack JavaScript/ISML, con un margen de maniobra limitado por la arquitectura MVC.

PWA Kit también hace server-side rendering en la carga inicial, preservando el SEO. Pero usa una stack moderna basada en React, lo que abre paso a técnicas de optimización más finas: code splitting, caché de página en CDN, hidratación selectiva. El trade-off real no es que "PWA Kit sea más rápido que SFRA" de forma genérica. Es que PWA Kit ofrece más palancas de optimización a quien tiene conocimiento de rendimiento web moderno en el equipo, mientras que SFRA entrega un techo de rendimiento decente con menos esfuerzo de configuración.

Para quien ya sufre lentitud en producción, independientemente de la arquitectura elegida, conviene entender antes los límites de plataforma SFCC que afectan a cualquier storefront: infraestructura compartida, rate limit de API o restricciones de personalización.

Coste total de propiedad: mantenimiento versus flexibilidad

Salesforce posiciona SFRA como reductor del coste total de propiedad. Las actualizaciones son más sencillas al seguir un estándar ampliamente documentado y respaldado por un ecosistema de conectores plug-and-play a través de los cartridges. Esto es real: mantener un SFRA "de fábrica", sin personalización pesada sobre los cartridges base, tiene un coste de mantenimiento previsible. La dependencia de conocimiento especializado en React también es menor.

El coste de PWA Kit se desplaza a otro lugar. Se paga más en el montaje inicial (arquitectura, integración SCAPI, pipeline de CI/CD), pero se gana desacoplamiento, lo que reduce el coste de evolucionar la experiencia de front-end sin tocar el back-end SFCC. Para operaciones con catálogo complejo, múltiples integraciones y alta frecuencia de cambios en la capa de presentación, ese desacoplamiento paga dividendos con los años: tests A/B, personalización visual y experiencias distintas por mercado. Para una operación más estable, con pocos cambios estructurales en el front-end, el coste adicional de mantener una stack composable puede no justificarse.

Cuándo tiene sentido elegir SFRA

SFRA es la opción más sólida cuando:

El equipo ya domina el patrón MVC, Bootstrap y jQuery, y no hay presión para reconstruir ese conocimiento
El time to market es la prioridad número uno del proyecto
La experiencia de front-end sigue estándares de mercado, sin necesidad de diferenciación visual extrema
La operación depende solo de conectores y apps plug-and-play del ecosistema SFCC

Cuándo tiene sentido elegir PWA Kit (Composable Storefront)

PWA Kit tiende a compensar la inversión inicial cuando:

La experiencia de front-end es parte de la propuesta de valor de la marca, no un commodity
Existe la necesidad de reutilizar la misma capa de front-end en múltiples touchpoints o mercados
El roadmap de producto exige iteración rápida en la UI sin depender del ciclo de deploy del back-end SFCC
El equipo técnico ya tiene (o va a construir) madurez en React y arquitectura headless

¿Y si ya tienes SFRA en producción?

Migrar de arquitectura no tiene por qué ser un evento de "big bang" con el sitio fuera de línea. Los equipos maduros suelen adoptar enfoques híbridos, manteniendo partes del storefront en SFRA mientras migran los journeys críticos (PDP, checkout) a PWA Kit de forma incremental. Si esta es tu realidad, vale la pena entender en detalle cómo llevar adelante esa transición sin interrumpir la operación. Ya cubrimos ese proceso en migración de SFRA a PWA Kit sin frenar las ventas.

Conclusión

No existe una arquitectura correcta en abstracto. Existe la arquitectura correcta para la etapa de tu negocio, la madurez de tu equipo y la urgencia del plazo. SFRA entrega previsibilidad y velocidad inicial. PWA Kit entrega flexibilidad y un techo de rendimiento más alto para quien tiene (o va a tener) el conocimiento especializado para explotarlo. La decisión equivocada sale cara en retrabajo y deuda técnica, no en la herramienta en sí.

Si esta decisión está sobre tu mesa ahora mismo y el trade-off entre time to market, rendimiento y coste de mantenimiento todavía no está claro para tu contexto específico, vale la pena hablar con quien ya ha tomado esta decisión en producción varias veces. Agenda una conversación con Develoci para evaluar qué arquitectura encaja en la realidad técnica y comercial de tu proyecto.