¿SFRA o PWA Kit? La decisión que define los próximos años de su arquitectura
Una guía técnica para Tech Leads que necesitan justificar esta elección ante el negocio, sin que se convierta en deuda técnica por el camino.
Hablar con quien ya migró ambosPor qué esta elección es más estratégica que técnica
Salesforce Commerce Cloud (SFCC) ofrece hoy dos caminos oficiales de frontend: SFRA (Storefront Reference Architecture), el modelo de renderizado en servidor con plantillas ISML consolidado desde 2018, y PWA Kit, el framework headless basado en React detrás de Composable Storefront, construido sobre la Salesforce Commerce API (SCAPI), según la documentación oficial de Salesforce.
La elección equivocada no aparece en el primer sprint. Aparece 18 meses después, cuando el equipo necesita entregar una funcionalidad de personalización que SFRA no resuelve bien, o cuando el coste de mantener un build de React a medida supera la mejora de rendimiento que justificó la migración.
Esta guía ordena los criterios técnicos que de verdad pesan en la decisión: arquitectura, rendimiento, SEO, curva de aprendizaje del equipo, coste de mantenimiento y los escenarios en los que gana cada opción.
SFRA vs PWA Kit: comparativa técnica directa
Los criterios que más influyen en la decisión de arquitectura en equipos de e-commerce que crecen rápido.
| SFRA | PWA Kit | |
|---|---|---|
| Modelo de renderizado | Renderizado en servidor (SSR) con plantillas ISML, procesadas directamente en el servidor de SFCC. | React con SSR en Managed Runtime; separación clara entre frontend y backend a través de la API. |
| Curva de aprendizaje del equipo | Exige dominio de ISML, de la B2C Commerce Script API y de las convenciones propias de SFCC. Menor barrera para quien viene de Java o Demandware. | Exige dominio sólido de React, Node.js y arquitectura headless. Barrera mayor para equipos sin experiencia en SPA y SSR modernos. |
| Rendimiento percibido (Core Web Vitals) | Suficiente en la mayoría de los casos, pero limitado por el ciclo tradicional de petición y respuesta del servidor. | Mayor control sobre LCP, CLS y TTFB gracias a la optimización del bundle, la caché de API y el renderizado granular. |
| Flexibilidad de UI/UX | Limitada por la estructura de plantillas ISML y los componentes predefinidos. Las personalizaciones profundas exigen más esfuerzo. | Libertad total de componentes en React; ideal para experiencias ricas, PWA instalable y microinteracciones complejas. |
| Velocidad de entrega inicial (MVP) | Más rápido para tiendas estándar, aprovechando los cartuchos y funcionalidades que SFRA ya trae. | Más lento al inicio: exige construir la capa de presentación desde cero sobre la API. |
| SEO técnico | El SSR nativo favorece la indexación sin esfuerzo extra de configuración. | El SSR en Managed Runtime también ofrece buen SEO, pero exige atención a la hidratación y a las meta tags dinámicas. |
| Coste de mantenimiento a medio plazo | Tiende a crecer a medida que las personalizaciones se acumulan sobre una arquitectura de servidor rígida. | Más previsible cuando la separación de responsabilidades entre API y frontend se respeta desde el inicio. |
| Integración con canales más allá de la web (app, IoT, voz) | No fue diseñado para esto; exige un trabajo adicional considerable. | La arquitectura headless facilita reutilizar la misma API en otros canales. |
| Madurez y soporte oficial de Salesforce | Referencia histórica, amplia documentación y comunidad consolidada desde 2018. | Inversión activa de Salesforce como camino estratégico hacia el composable commerce, pero con menos años de madurez en producción. |
Cómo decidir: una checklist técnica en 5 preguntas
Antes de elegir, respondan estas preguntas con el equipo de arquitectura y el liderazgo de producto.
¿Qué nivel de personalización de UI exige el roadmap de producto?
Si el negocio quiere construir experiencias de UI muy distintas del estándar de e-commerce (configuradores complejos, PWA instalable, microinteracciones elaboradas), PWA Kit da más libertad. Si las necesidades son las de una tienda tradicional bien ejecutada, SFRA lo resuelve con menos esfuerzo de ingeniería.
¿El equipo actual domina React y Node, o Java e ISML?
Migrar a PWA Kit sin personas con experiencia real en arquitectura headless con React genera retrabajo y fallos de rendimiento que anulan la mejora teórica. Evalúen con honestidad la experiencia técnica disponible antes de decidirse por la arquitectura más nueva.
¿Cuál es el plazo para el primer lanzamiento?
Los plazos ajustados de MVP suelen favorecer a SFRA, que ya trae buena parte del recorrido de compra. PWA Kit compensa la mayor inversión inicial en horizontes más largos o cuando ya existe una base de componentes reutilizable.
¿Hay un plan real de omnicanalidad (app nativa, otros puntos de contacto)?
Si la misma capa de API va a alimentar una app móvil, quioscos u otros canales a medio plazo, la arquitectura headless de PWA Kit evita reescribir integraciones. Si el alcance es solo la tienda web, este argumento pierde peso.
¿Qué tolerancia hay a la deuda técnica a medio plazo?
SFRA tiende a acumular personalizaciones sobre una base rígida; PWA Kit tiende a degradarse cuando no se respeta la separación de capas. Ninguna arquitectura es inmune a la deuda técnica: la diferencia está en dónde se acumula.
Migrar no es reescribir: se puede evolucionar sin parar el negocio
Muchos equipos de e-commerce ven la elección entre SFRA y PWA Kit como un evento único y definitivo. En la práctica, es posible hacer migraciones incrementales, validando PWA Kit en recorridos concretos (búsqueda, ficha de producto, checkout) antes de extenderlo a toda la tienda.
Este tipo de decisión exige experiencia práctica real con las dos arquitecturas, porque los compromisos de rendimiento, caché y SEO cambian de una página a otra. Especialistas asignados que ya pasaron por esta migración en otros proyectos SFCC reducen el riesgo de retrabajo, sin que usted tenga que ampliar el equipo interno para ello.
Qué hacer con esta comparativa
Ninguna tabla sustituye la evaluación de su contexto concreto: stack actual, madurez del equipo, plazos de negocio y roadmap de producto. El valor de esta guía es dar un vocabulario técnico común a la conversación entre el Tech Lead, el liderazgo de e-commerce y los responsables de negocio.
Si la decisión entre SFRA y PWA Kit está bloqueada porque al equipo le falta experiencia práctica en las dos arquitecturas, ese es justo el tipo de carencia que se resuelve con especialistas asignados por proyecto, sin comprometer la plantilla interna ni la velocidad de la decisión.
Validen la decisión antes de comprometer el roadmap
Un diagnóstico técnico gratuito con especialistas que ya implementaron SFRA y PWA Kit en producción ayuda a mapear los riesgos de rendimiento, SEO y mantenimiento antes de tomar la decisión, no después.
