Marca DTC Migró de Shopify a Next.js Headless: Aumento de 249% en ROAS
En marzo de 2024, una marca DTC de skincare se acercó a nosotros con un problema dolorosamente común: su tema de Shopify era lento, su gasto en publicidad se estaba desangrando, y sus Core Web Vitals estaban tan profundamente en rojo que Google esencialmente los estaba depriorizando en la búsqueda. Ocho meses después, su retorno sobre el gasto publicitario había aumentado un 249%, su LCP bajó de 8.2s a 1.4s, y cada métrica de Core Web Vitals estaba solidamente en verde. Esta es la historia completa de cómo llegamos allí — las decisiones arquitectónicas, los compromisos, los errores, y los números reales.
Tabla de contenidos
- El punto de partida: Una tienda Shopify en problemas
- Por qué Headless y por qué ahora
- Elegir la arquitectura: Next.js, Hydrogen, y la Storefront API
- La arquitectura de migración
- Arreglando Core Web Vitals: Qué realmente movió la aguja
- La historia de ROAS: Cómo el rendimiento se convirtió en ganancias
- Cronograma, presupuesto y costos reales
- Lecciones aprendidas y qué haríamos diferente
- Preguntas frecuentes
El punto de partida: Una tienda Shopify en problemas
Llamémosles GlowCo (NDA, ya sabes cómo es). Son una marca DTC de skincare que genera aproximadamente $3.2M anuales a través de su tienda Shopify Plus. Tenían 47 SKUs, un modelo de suscripción a través de Recharge, y estaban gastando aproximadamente $85K/mes en anuncios de Meta y Google.
El problema no era su producto ni su equipo de marketing. El problema era su sitio web.
Así se veían sus métricas cuando se comunicaron con nosotros:
| Métrica | Valor (marzo de 2024) | Estado |
|---|---|---|
| Largest Contentful Paint (LCP) | 8.2s | 🔴 Pobre |
| First Input Delay (FID) | 340ms | 🔴 Pobre |
| Cumulative Layout Shift (CLS) | 0.42 | 🔴 Pobre |
| Interaction to Next Paint (INP) | 510ms | 🔴 Pobre |
| Puntuación de PageSpeed móvil | 18/100 | 🔴 |
| Puntuación de PageSpeed de escritorio | 42/100 | 🟡 |
| Tasa de rebote (móvil) | 71% | — |
| Tasa de conversión | 1.2% | — |
| ROAS de anuncios en Meta | 1.8x | — |
| ROAS de anuncios en Google | 2.1x | — |
Una puntuación de PageSpeed de 18 en móvil. He visto tiendas Shopify malas, pero esta tenía un tema con 2.4MB de JavaScript no optimizado, 14 scripts de terceros que bloqueaban la renderización (Klaviyo, Yotpo, una aplicación de lealtad, dos herramientas popup diferentes, y un puñado de scripts de análisis), e imágenes hero que eran PNGs de 3MB siendo servidas sin ningún tamaño responsivo.
Su tema de Shopify era una versión fuertemente personalizada de un tema premium popular, modificada durante tres años por al menos cuatro freelancers diferentes. El código de plantilla Liquid era un desorden anidado de lógica condicional que nadie entendía completamente.
Pero aquí está lo que realmente llamó mi atención: su equipo de marketing nos mostró que sus puntuaciones de calidad de anuncios en Meta habían estado declinando durante meses. El algoritmo de Meta penaliza las páginas de destino que cargan lentamente. Google Shopping era la misma historia — sus anuncios estaban obteniendo menos impresiones a CPCs más altos porque la puntuación de experiencia de página de destino se estaba hundiendo.
No solo estaban perdiendo tráfico orgánico. Literalmente estaban pagando más por cada clic porque su sitio era lento.
Por qué Headless y por qué ahora
GlowCo ya había explorado las opciones obvias. Habían intentado optimizar su tema de Shopify existente — removieron algunas aplicaciones, comprimieron imágenes, cambiaron a un tema un poco más ligero. Ayudó, apenas. LCP fue de 8.2s a aproximadamente 6.8s. Aún profundamente rojo.
El problema fundamental es uno que vemos repetidamente con la arquitectura monolítica de Shopify: no controlas el pipeline de renderización. Los servidores de Shopify renderizan plantillas Liquid, inyectan su propio JavaScript (solo el JS principal de Shopify es ~200KB), y estás a merced de lo que el tema y las aplicaciones estén haciendo.
Ir headless significaba desacoplar completamente el frontend de la capa de renderización de Shopify. Shopify seguiría manejando el backend de comercio — productos, inventario, checkout, pagos — pero construiríamos toda la experiencia del cliente desde cero.
El tiempo tenía sentido por tres razones:
La Storefront API de Shopify se había vuelto significativamente más madura. A principios de 2024, la Storefront API cubría casi todo lo que necesitarías para una experiencia completa de tienda, incluyendo gestión del carrito, cuentas de cliente, y acceso a metafields.
Shopify Checkout Extensibility ahora estaba disponible en Plus. Esto significaba que no necesitábamos reconstruir el checkout (que, honestamente, es donde headless solía fallar).
El caso de negocios era claro. Si mejorar la velocidad del sitio podría reducir su CPC en incluso 15-20% mientras mejoraba las tasas de conversión, el proyecto se pagaría a sí mismo dentro de 3-4 meses.
Elegir la arquitectura: Next.js, Hydrogen, y la Storefront API
Aquí es donde las cosas se ponen interesantes, porque tuvimos un debate genuino sobre la arquitectura.
Los contendientes
La respuesta oficial de Shopify para headless es Hydrogen — su framework basado en React construido en Remix. Está estrechamente integrado con las APIs de Shopify y desplegado en Oxygen (la plataforma de alojamiento de Shopify).
Pero finalmente optamos por Next.js 14 (App Router) usando la librería Hydrogen React de Shopify — no el framework completo Hydrogen/Remix.
Aquí está el por qué:
| Factor | Hydrogen (Remix/Oxygen) | Next.js + Hydrogen React | Astro + Storefront API |
|---|---|---|---|
| Flexibilidad SSR/SSG | Buena (streaming de Remix) | Excelente (ISR, SSG, SSR, RSC) | Excelente (Islands, SSG) |
| Ecosistema de React | Completo | Completo | Parcial (Islands) |
| Opciones de alojamiento | Solo Oxygen (o self-host) | Vercel, Netlify, AWS, self-host | Cualquier host estático + SSR |
| Profundidad de integración con Shopify | Nativa | Vía @shopify/hydrogen-react | Llamadas manuales a API |
| Familiaridad del equipo | Baja | Alta | Media |
| Renderización en Edge | Oxygen Workers | Vercel Edge, Cloudflare | Cloudflare, Netlify |
| Comunidad/ecosistema | En crecimiento | Masivo | En crecimiento rápido |
Consideramos Astro seriamente. Para un sitio con mucho contenido e interactividad limitada, el modelo de hidratación parcial de Astro hubiera sido ideal. Pero el sitio de GlowCo necesitaba una interactividad del lado del cliente pesada — un quiz de skincare, un constructor de rutina de cuidado de la piel, cajones de carrito de adición rápida, gestión de suscripción en tiempo real. Los React Server Components de Next.js nos dieron el mejor equilibrio de rendimiento renderizado en el servidor con riqueza del lado del cliente.
También elegimos desplegar en Vercel en lugar de Oxygen. Las capacidades de red perimetral de Vercel e ISR (Incremental Static Regeneration) nos dieron un control de caché de grano fino que no podríamos replicar fácilmente en Oxygen en ese momento.
Nuestra pila final:
- Next.js 14 (App Router con React Server Components)
- @shopify/hydrogen-react para carrito, utilidades de Storefront API
- Shopify Storefront API (GraphQL) para datos de productos
- Shopify Plus Checkout (nativo, no personalizado)
- Sanity CMS para contenido editorial, páginas de destino, y publicaciones de blog
- Vercel para alojamiento y funciones edge
- Recharge vía su API headless para suscripciones
- Klaviyo cargado asincronamente vía integración personalizada ligera
Si estás evaluando una configuración similar, nuestro equipo en Social Animal tiene experiencia profunda con esta arquitectura exacta — hemos documentado nuestro enfoque para desarrollo de CMS headless y desarrollo con Next.js si quieres ver el panorama más amplio.
La arquitectura de migración
Capa de datos
Mantuvimos Shopify como la fuente de verdad para todos los datos de comercio. Productos, variantes, inventario, precios, clientes, órdenes — todo permanece en Shopify. Esto fue innegociable. El motor de comercio de Shopify está bien probado y sus tasas de conversión de checkout son difíciles de superar.
Para contenido, configuramos Sanity como un CMS headless. Las páginas de productos extraían datos estructurados de Shopify (precios, variantes, inventario) y contenido editorial de Sanity (historias de ingredientes, guías de uso, narrativas de venta cruzada). Esta separación es crucial — significa que el equipo de marketing puede actualizar el contenido de la página sin tocar datos de productos, y el equipo de operaciones puede gestionar el inventario sin romper páginas de destino.
// Obtención de datos simplificada de página de producto (App Router de Next.js)
async function getProductPageData(handle: string) {
const [shopifyProduct, sanityContent] = await Promise.all([
getShopifyProduct(handle), // GraphQL de Storefront API
getSanityProductContent(handle) // Consulta GROQ de Sanity
]);
return {
product: shopifyProduct,
editorial: sanityContent,
// Fusionar metafields para datos estructurados
structuredData: buildProductSchema(shopifyProduct, sanityContent),
};
}
Estrategia de renderización
No cada página necesita el mismo enfoque de renderización. Fuimos deliberados sobre esto:
- Páginas de producto: ISR con revalidación de 60 segundos. Los productos no cambian cada segundo, pero necesitábamos precisión de inventario dentro de un minuto.
- Páginas de colección: ISR con revalidación de 5 minutos. Estas cambian incluso menos frecuentemente.
- Homepage y páginas de destino: ISR con revalidación bajo demanda activada por webhooks de Sanity. Cuando el equipo de marketing publica, un webhook llama a nuestro endpoint de revalidación.
- Páginas de carrito/cuenta: Completamente del lado del cliente con shells renderizados en el servidor. Estas son inherentemente dinámicas.
- Blog/editorial: Generación estática en tiempo de construcción con revalidación bajo demanda.
La implementación del carrito
Aquí es donde @shopify/hydrogen-react se ganó su lugar. El CartProvider y los hooks asociados manejan toda la gestión del estado del carrito, incluyendo actualizaciones optimistas de UI. El carrito vive en la Storefront API de Shopify (no en estado local), lo que significa que persiste entre sesiones y dispositivos.
// Cajón del carrito con actualizaciones optimistas
'use client';
import { CartProvider, useCart } from '@shopify/hydrogen-react';
function CartDrawer() {
const { lines, totalQuantity, cost, linesUpdate } = useCart();
return (
<Sheet>
{lines.map((line) => (
<CartLine
key={line.id}
line={line}
onQuantityChange={(quantity) =>
linesUpdate([{ id: line.id, quantity }])
}
/>
))}
<CartTotal cost={cost} />
<CheckoutButton />
</Sheet>
);
}
Checkout
No construimos un checkout personalizado. Esto es importante. El checkout nativo de Shopify (especialmente en Plus con Checkout Extensibility) tiene años de pruebas A/B y optimización incorporadas. Shop Pay por sí solo puede aumentar la conversión de checkout en un 50% para clientes recurrentes. Lo personalizamos usando Checkout UI Extensions para consistencia de marca y widgets de venta adicional, pero el flujo principal permanece nativo de Shopify.
Arreglando Core Web Vitals: Qué realmente movió la aguja
Aquí está la parte que la mayoría de los estudios de caso pasan por alto. Ir headless no arregla mágicamente tus Core Web Vitals. Absolutamente puedes construir un sitio Next.js lento. Lo he visto suceder. Lo que importa son las optimizaciones específicas que haces una vez que tienes control sobre el pipeline de renderización.
LCP: De 8.2s a 1.4s
La mejora individual más grande de LCP vino de tres cosas:
Eliminar recursos que bloquean la renderización. En el antiguo tema de Shopify, 14 scripts de terceros cargaban sincrónicamente. En nuestra compilación de Next.js, CSS crítico está en línea, JavaScript está dividido en código y cargado solo donde es necesario, y los scripts de terceros cargan después de que el contenido principal está pintado usando
next/scriptconstrategy="lazyOnload".Optimización de imágenes con
next/image. Servimos imágenes responsivas en formato WebP/AVIF, adecuadamente dimensionadas para cada viewport. Las imágenes hero fueron de PNGs de 3MB a archivos AVIF de ~80KB. El elemento LCP (generalmente la imagen hero) ahora carga como un recurso prefetcheado prioritario.Caché edge con stale-while-revalidate. ISR en Vercel significa que el primer visitante después de una ventana de revalidación obtiene una página en caché instantáneamente mientras el servidor regenera en el fondo. La mayoría de los visitantes nunca esperan un renderizado del servidor.
CLS: De 0.42 a 0.02
El cambio de diseño era causado por imágenes sin dimensiones, fuentes cargadas tarde (FOUT), e widgets de aplicación inyectados dinámicamente. Nuestras correcciones:
- Todas las imágenes tienen atributos explícitos
widthyheight(o usan CSSaspect-ratio) - Fuentes precargadas con
font-display: swapy fuentes de repuesto con tamaño ajustado - Sin widgets de terceros inyectados dinámicamente por encima de la línea de flotación
- Componentes de UI esqueleto para cualquier contenido asincrónico
INP: De 510ms a 78ms
Interaction to Next Paint fue el más difícil de arreglar. El tema antiguo tenía manejadores de eventos adjuntos a todo el DOM, cascadas jQuery, y JavaScript pesado del lado del cliente bloqueando el hilo principal.
Los React Server Components fueron la clave aquí. Al renderizar la mayoría de la página en el servidor e hidratar solo componentes interactivos (cajón del carrito, selectores de producto, widget quiz), redujimos dramáticamente la cantidad de JavaScript del lado del cliente. Nuestro bundle total de cliente para la página de producto cayó de 2.4MB a 187KB.
Los números después
| Métrica | Antes (marzo de 2024) | Después (noviembre de 2024) | Estado |
|---|---|---|---|
| LCP | 8.2s | 1.4s | 🟢 Bueno |
| FID | 340ms | 12ms | 🟢 Bueno |
| CLS | 0.42 | 0.02 | 🟢 Bueno |
| INP | 510ms | 78ms | 🟢 Bueno |
| PageSpeed móvil | 18 | 94 | 🟢 |
| PageSpeed de escritorio | 42 | 99 | 🟢 |
| JS total (página de producto) | 2.4MB | 187KB | — |
| TTFB (p75) | 1.8s | 0.12s | — |
La historia de ROAS: Cómo el rendimiento se convirtió en ganancias
Aquí es donde la goma golpea el camino. Nadie migra a headless por diversión — el caso de negocios tiene que estar allí.
El nuevo sitio se lanzó en fases entre julio y octubre de 2024. Para noviembre, teníamos datos limpios para comparar. Los resultados fueron, francamente, mejores que lo que proyectamos.
Impacto directo de conversión
La tasa de rebote móvil cayó de 71% a 38%. Eso por sí solo es masivo — significa que 46% más visitantes estaban dispuestos a incluso ver el producto. La tasa de conversión móvil fue de 1.2% a 2.8%.
La tasa de conversión de escritorio mejoró de 2.4% a 3.9%.
Tasa de conversión blended general: 1.2% → 3.1%
Impacto de plataforma de anuncios
Esta es la parte que nos sorprendió incluso a nosotros. Dentro de 6 semanas de que los Core Web Vitals pasaran verde en toda la línea:
- El CPC de anuncios en Google cayó 22% — La puntuación de experiencia de página de destino de Google mejoró, reduciendo directamente el costo por clic
- El CPM de anuncios en Meta disminuyó 18% — El algoritmo de Meta comenzó a mostrar sus anuncios más (mejor página de destino = puntuación de relevancia más alta = costos más bajos)
- La cuota de impresiones de Google Shopping aumentó 34% — Una mejor experiencia de página significaba que Google estaba más dispuesto a mostrar sus listados de productos
El efecto combinado en ROAS:
| Canal | ROAS antes | ROAS después | Cambio |
|---|---|---|---|
| Anuncios en Meta | 1.8x | 5.2x | +189% |
| Anuncios de búsqueda en Google | 2.1x | 7.4x | +252% |
| Google Shopping | 2.4x | 8.8x | +267% |
| Blended | 1.95x | 6.8x | +249% |
El aumento blended de ROAS del 249% vino de dos factores compuestos: costo por clic más bajo Y tasa de conversión más alta. Cuando tus clics cuestan menos y cada clic se convierte a una tasa más alta, las matemáticas se componen hermosamente.
Tráfico orgánico
No sería negligente no mencionar el impacto en SEO. Dentro de 4 meses de que todos los Core Web Vitals estuvieran en verde:
- El tráfico orgánico aumentó 67%
- La posición promedio para palabras clave objetivo mejoró 4.2 posiciones
- Los ingresos orgánicos aumentaron 89%
Google ha sido claro que la experiencia de página es una señal de ranking. Esta fue prueba del mundo real.
Cronograma, presupuesto y costos reales
Creo en la transparencia sobre lo que proyectos como estos realmente cuestan. Aquí está el desglose real:
Cronograma: 7 meses desde el inicio hasta el lanzamiento completo (con un lanzamiento en fases comenzando en el mes 5)
Equipo: 2 desarrolladores frontend senior, 1 especialista backend de Shopify, 1 diseñador, 1 gerente de proyecto (a tiempo parcial)
Costo total del proyecto: ~$145,000
Alojamiento/infraestructura mensual: ~$350/mes (Vercel Pro + plan Sanity Growth)
Shopify Plus continuo: $2,300/mes (sin cambios — ya estaban en Plus)
Período de recuperación: El proyecto se pagó a sí mismo en 2.8 meses basado en los ingresos aumentados de ROAS mejorado y tasas de conversión.
¿Es este tipo de inversión adecuada para cada marca? No. Si haces menos de $1M anuales, las matemáticas probablemente aún no funcionan. Pero para marcas DTC gastando $50K+ mensualmente en anuncios con Core Web Vitals pobres, el ROI está casi siempre allí. Estamos felices de hablar de detalles específicos — comunícate con nosotros o revisa nuestros modelos de precios para proyectos de comercio headless.
Lecciones aprendidas y qué haríamos diferente
Lo que funcionó
- Mantener el checkout de Shopify nativo fue 100% la decisión correcta. Sin regresión de conversión de checkout.
- ISR con revalidación bajo demanda nos dio lo mejor de ambos mundos: rendimiento estático con contenido dinámico.
- Lanzamiento en fases (lanzando primero páginas de blog/editorial, luego colecciones, luego PDPs, luego homepage) nos permitió validar rendimiento en producción antes de migrar páginas de alto tráfico.
Lo que haríamos diferente
- Comenzar la migración headless de Recharge antes. Su API headless tenía algunas peculiaridades que no anticipamos, y consumió 3 semanas de nuestro cronograma. Si estás usando Recharge, presupuesta tiempo extra.
- Configurar infraestructura de pruebas A/B desde el primer día. La agregamos en el mes 2 y perdimos algunos datos de comparación tempranos.
- Usar Vercel Edge Config para feature flags en lugar del enfoque de variables de entorno con el que comenzamos. Hubiera hecho el lanzamiento en fases más limpio.
Una advertencia honesta
El enfoque headless añade complejidad operacional. GlowCo ahora gestiona dos sistemas en lugar de uno. Su equipo de marketing no puede simplemente instalar una aplicación Shopify y tenerla aparecer en el escaparate — cualquier nueva integración de terceros requiere trabajo de desarrollo. Para GlowCo, en su escala y gasto en publicidad, las ganancias de rendimiento superan con creces esta fricción. Pero es un compromiso real que necesitas entender desde el principio.
Preguntas frecuentes
¿Cuánto tiempo tarda migrar una tienda Shopify a headless Next.js? Para una marca DTC típica con 30-100 SKUs, espera 4-8 meses dependiendo de la complejidad. El proyecto de GlowCo tomó 7 meses debido a características personalizadas como su quiz de skincare e integración de suscripción con Recharge. Las tiendas más simples con menos características personalizadas se pueden hacer en 4-5 meses.
¿Ir headless rompe las aplicaciones de Shopify? Sí, la mayoría de las aplicaciones de Shopify dependientes del tema no funcionarán en una configuración headless. Las aplicaciones que inyectan UI en tu escaparate (widgets de reseña, popups de lealtad, herramientas de venta adicional) necesitan ser reemplazadas con alternativas basadas en API o componentes construidos personalizadamente. Las aplicaciones de backend (gestión de inventario, envío, etc.) continúan funcionando bien ya que no tocan el frontend.
¿Es mejor Hydrogen o Next.js para Shopify headless? Depende de tu equipo y requisitos. Hydrogen (construido en Remix) ofrece integración más ajustada de Shopify fuera de la caja y es el camino oficialmente soportado por Shopify. Next.js ofrece un ecosistema más grande, más flexibilidad de alojamiento, y React Server Components. Elegimos Next.js para GlowCo por la experiencia existente del equipo y las capacidades de caché edge de Vercel. Ambas son opciones excelentes.
¿Cuánto cuesta una migración headless de Shopify en 2025? Los presupuestos realistas oscilan entre $80,000 a $250,000+ dependiendo de la complejidad de la tienda, características personalizadas, y tarifas de agencia. El proyecto de GlowCo fue de $145,000. Ten cuidado de agencias que cotizan por debajo de $50K para una compilación headless completa — probablemente obtendrás una plantilla con personalización limitada. Los costos de infraestructura mensual generalmente rondan $200-600 para alojamiento y CMS.
¿Los Core Web Vitals realmente afectan los costos de anuncios en Google? Sí. Google Ads usa una puntuación de "Experiencia de página de destino" como parte del cálculo de Quality Score. Mejor velocidad de página y puntuaciones de Core Web Vitals llevan a Quality Scores más altos, que directamente reducen tu costo por clic. GlowCo vio una reducción de CPC del 22% después de que sus Core Web Vitals mejoraron. Meta usa señales similares para la puntuación de relevancia de anuncios.
¿Puedes mantener el checkout de Shopify cuando vas headless? Absolutamente, y lo recomendamos fuertemente. El checkout de Shopify está altamente optimizado e incluye características como Shop Pay (que puede aumentar la conversión de checkout en 50%+ para shoppers recurrentes). Con Shopify Plus, puedes usar Checkout Extensibility para personalizar la apariencia y agregar upsells manteniendo el flujo de checkout central intacto.
¿Cuál es la diferencia entre Shopify headless y Shopify Hydrogen? Shopify headless es un concepto amplio — cualquier frontend personalizado que use la Storefront API de Shopify. Hydrogen es el framework específico de Shopify para construir escaparates headless, construido en Remix y desplegado en el alojamiento Oxygen de Shopify. Puedes ir headless con Next.js, Astro, Nuxt, o cualquier framework. Hydrogen es solo una opción dentro del ecosistema Shopify headless más amplio.
¿Vale la pena headless para pequeñas tiendas Shopify? Usualmente no. Si haces menos de $1M en ingresos anuales y gastas menos de $20K mensualmente en anuncios, el costo de una migración headless probablemente no producirá un ROI significativo. Enfócate en optimizar tu tema existente primero — remueve aplicaciones sin usar, comprime imágenes, cambia a un tema enfocado en rendimiento como Dawn. Considera headless cuando tu gasto en publicidad sea lo suficientemente alto como para que incluso pequeñas mejoras de eficiencia se traduzcan en cantidades significativas de dólares.