Store Framework o FastStore: cómo elegir en 2026

Pocas decisiones en un proyecto VTEX pesan tanto como esta, y pocas se toman con tan poca información. Vi equipos elegir FastStore porque es lo nuevo y equipos quedarse en Store Framework porque es lo que conocemos.

Las dos razones son malas y suelen terminar igual: replanteos a mitad del desarrollo, sprints quemados y un cliente que pregunta por qué la fecha de salida se volvió a mover. Este artículo es lo que me hubiera gustado tener en la mano antes de algunos de esos kickoffs.

La pregunta equivocada

La pregunta no es cuál es mejor. Los dos son frontends oficiales de VTEX, los dos tienen soporte y los dos pueden sostener una tienda grande con mucho tráfico.

La pregunta útil es cuál encaja con tu equipo, con tus integraciones y con lo que el negocio va a necesitar en los próximos tres años. Cuando lo planteo así, la conversación deja de ser una discusión entre devs y pasa a ser una decisión de producto, que es lo que realmente es.

Qué es cada uno en la práctica

Store Framework vive dentro de VTEX IO. Armás la tienda componiendo bloques declarados en JSON, extendés con apps en React y resolvés lógica del lado servidor con Node y GraphQL. Publicás con el toolbelt, con workspaces, versionado y rollback. Es un ecosistema cerrado y bastante coherente.

FastStore es el enfoque headless de VTEX: un frontend basado en Next.js, con un toolkit de componentes, secciones que podés sobrescribir y un CMS headless para el contenido. Se despliega con WebOps y consume VTEX a través de su propia capa GraphQL, que se puede extender.

En criollo: Store Framework te da más cosas resueltas a cambio de jugar con sus reglas. FastStore te da más control a cambio de hacerte cargo de más.

Dónde Store Framework sigue ganando

Si la operación depende de apps del ecosistema IO, Store Framework sigue siendo el camino corto. Muchas apps de VTEX y de partners exponen bloques pensados para este framework. En FastStore, esa misma funcionalidad a veces hay que reconstruirla o integrarla a mano.

También gana cuando la agencia o el equipo interno ya tiene años de conocimiento en IO y una base de apps propias probadas en producción. Ese capital no se tira a la basura por una moda.

Y gana en proyectos donde el tiempo de salida manda. Con un buen theme base y componentes conocidos, una tienda en Store Framework sale más rápido que una en FastStore construida desde cero, sobre todo si el diseño no se aleja demasiado de lo estándar.

Un detalle que mucha gente no sabe: las apps backend de IO (resolvers GraphQL, servicios en Node, integraciones con ERP) se pueden seguir consumiendo desde FastStore. Lo que no se reutiliza es el front. Eso cambia bastante la cuenta cuando se evalúa una migración.

Dónde FastStore tiene ventaja real

Performance. Con generación estática, revalidación y un bundle mucho más liviano, llegar a buenos Core Web Vitals es más natural. En Store Framework se puede, pero suele ser una pelea constante con el peso del JavaScript y la hidratación.

SEO en catálogos grandes. Tenés control fino sobre el render, los metadatos, los datos estructurados y cómo se generan las páginas de categoría y producto. Para tiendas con decenas de miles de SKUs y mucho tráfico orgánico, esto vale oro.

Equipo y mercado. Next.js y React estándar son mucho más fáciles de conseguir que gente que domine VTEX IO a fondo. Si la marca quiere internalizar el front, FastStore le baja la barrera de entrada.

Ahora, una advertencia: la performance no viene gratis. Vi tiendas en FastStore más lentas que algunas en Store Framework por culpa de un tag manager cargado de píxeles, scripts de terceros sin control e imágenes sin optimizar. El framework no te salva de las malas decisiones.

Las preguntas que hago antes de decidir

Cuando me toca opinar en esta elección, no arranco por la tecnología. Arranco por estas preguntas:

• ¿Qué apps del ecosistema IO usa hoy la tienda o va a necesitar, y existe un equivalente razonable del lado de FastStore?
• ¿Qué integraciones de frontend con terceros hay (reseñas, búsqueda, recomendaciones, chat) y tienen soporte para cada mundo?
• ¿Quién va a mantener la tienda dentro de dos años, y qué sabe ese equipo?
• ¿Quién edita el contenido, con qué frecuencia y con qué nivel de autonomía?
• ¿Cuál es el problema concreto que queremos resolver? Si es performance, ¿ya se midió y se atacó en el stack actual?

Si la respuesta a la última pregunta es vaga, la decisión todavía no está madura. Y eso también es una respuesta.

El checkout, el detalle que nadie mira en el kickoff

FastStore resuelve la vitrina, pero en la mayoría de los setups el checkout sigue siendo el de VTEX, con sus customizaciones de siempre. Eso significa que cuotas, promociones bancarias, medios de pago locales, CUIT para factura A y retiro en sucursal se resuelven en el mismo lugar, elijas el frontend que elijas.

Si alguien te propone FastStore como forma de rehacer el checkout, pedí que te muestre exactamente cómo y con qué costo de mantenimiento. Muchas veces la promesa no resiste la primera reunión técnica.

Otro punto: el paso de la vitrina al checkout, que en muchas implementaciones vive en otro subdominio. Hay que cuidar sesión, cookies y tracking entre dominios. Vi proyectos que salieron bien en lo visual y perdieron atribución en analytics durante semanas porque nadie miró esto antes del go live.

Lo mismo con Mi Cuenta, listas de deseos y otras piezas que en Store Framework vienen casi resueltas. En FastStore conviene confirmar al principio qué está disponible en la versión actual y qué hay que construir.

Errores que vi a mitad de proyecto

El más común: estimar un proyecto FastStore con la cabeza de Store Framework. Se asume que ciertas piezas existen listas para usar, y en el sprint cuatro aparece que hay que desarrollarlas. Ahí se rompe el cronograma.

El segundo: elegir FastStore sin nadie en el equipo que sepa Next.js de verdad. Caching, revalidación, rutas dinámicas y build times no se aprenden en un proyecto con fecha comprometida para Hot Sale.

El tercero va para el otro lado: elegir Store Framework para un sitio muy editorial, con un diseño muy fuera de lo estándar, y terminar peleando con CSS handles, overrides y bloques que no hacen exactamente lo que el diseño pide.

El cuarto: no hacer una prueba de concepto con las dos o tres integraciones críticas antes de firmar el alcance. Una semana de PoC te ahorra un mes de discusiones después.

Y el que más duele: no pensar en quién hereda la tienda. La agencia termina el proyecto y el equipo interno recibe algo que no sabe operar ni deployar.

Si ya estás en Store Framework

Migrar no siempre conviene. Si el dolor es performance, muchas veces una auditoría seria da resultados grandes sin cambiar de stack: sacar apps que nadie usa, controlar scripts de terceros, lazy loading bien aplicado, imágenes en tamaño correcto y revisar qué se renderiza del lado servidor.

Si la migración tiene sentido, lo bueno es que catálogo, precios, promociones, Master Data e integraciones con el ERP no se tocan. Cambia la capa de presentación. Lo que hay que cuidar es el SEO: mantener URLs, mapear redirecciones, medir antes y después, y no salir en temporada alta.

Y planificalo como un proyecto propio, no como un rediseño con otro nombre. Tiene riesgos distintos y necesita su propio plan de rollback.

Mi criterio para 2026

Si tenés una tienda funcionando en Store Framework, con apps propias y un equipo que la domina, primero exprimí lo que tenés. Migrar por moda es la forma más cara de no resolver nada.

Si arrancás de cero, con foco fuerte en orgánico, un diseño propio y un equipo con buen nivel en Next.js, FastStore es hoy una opción muy sólida y es hacia donde VTEX empuja el futuro del front.

Y si estás en el medio, que es lo más común, la respuesta sale de las preguntas de arriba, no de una presentación comercial ni de lo que esté de moda en LinkedIn.

Si querés charlarlo

Si sos de una agencia y necesitás un arquitecto o dev VTEX senior para un proyecto así, o sos de una marca y querés una segunda opinión antes de comprometer meses de desarrollo, escribime. Con una charla corta y mirando tu caso concreto ya suele quedar bastante claro el camino.