Migración de Shopify a Headless Next.js: Aumento de 249% en ROAS
Tu página de producto Shopify carga. Pasan ocho punto dos segundos. La imagen del héroe se entrecorta en la vista. El pulgar de tu visitante se acerca al botón atrás — y tu píxel de Meta registra otro rechazo antes de que el checkout ni siquiera se renderice. En marzo de 2024, una marca de cuidado de la piel DTC llegó a nuestro Slack con esta espiral exacta: el gasto en publicidad se desangraba en un tema tan lento que Google efectivamente los había deprioritizado en búsqueda. Ocho meses después, su ROAS había aumentado 249%. LCP bajó de 8.2s a 1.4s. Todos los Core Web Vitals se pusieron en verde. Este es el desglose completo — decisiones de arquitectura, compensaciones que casi cometemos mal, y las tres métricas que cambiaron más rápido de lo que esperábamos.
Tabla de Contenidos
- El Punto de Partida: Una Tienda Shopify en Problemas
- Por Qué Headless y Por Qué Ahora
- Eligiendo el Stack: Next.js, Hydrogen, y la Storefront API
- La Arquitectura de Migración
- Corrigiendo Core Web Vitals: Qué Realmente Movió la Aguja
- La Historia de ROAS: Cómo el Rendimiento Se Convirtió en Ganancia
- Cronograma, Presupuesto y Costos Reales
- Lecciones Aprendidas y Qué Haríamos Diferente
- FAQ
El Punto de Partida: Una Tienda Shopify en Problemas
Llamémoslos GlowCo (NDA, ya sabes cómo es). Son una marca DTC de cuidado de la piel que hace 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.
Aquí está cómo se veían sus métricas cuando se comunicaron con nosotros:
| Métrica | Valor (Marzo 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 Escritorio | 42/100 | 🟡 |
| Tasa de Rebote (Móvil) | 71% | — |
| Tasa de Conversión | 1.2% | — |
| Meta Ads ROAS | 1.8x | — |
| Google Ads ROAS | 2.1x | — |
Una puntuación de PageSpeed de 18 en móvil. He visto tiendas Shopify malas, pero esta llevaba un tema con 2.4MB de JavaScript no optimizado, 14 scripts de terceros que bloquean la renderización (Klaviyo, Yotpo, una aplicación de lealtad, dos herramientas de popup diferentes, y un puñado de scripts de análisis), e imágenes de héroe que eran PNGs de 3MB siendo servidas sin tamaño responsivo.
El tema de Shopify de GlowCo era una versión altamente 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 lío anidado de lógica condicional que nadie entendía completamente.
Pero aquí está lo que realmente me llamó la atención: su equipo de marketing nos mostró que sus puntuaciones de calidad de anuncios de Meta habían estado en declive durante meses. El algoritmo de Meta penaliza las páginas de destino que cargan lentamente. Google Shopping era la misma historia — sus anuncios estaban recibiendo menos impresiones a CPCs más altos porque la puntuación de experiencia de página de destino se estaba desmoronando.
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 Shopify existente — eliminaron algunas aplicaciones, comprimieron imágenes, cambiaron a un tema ligeramente más ligero. Ayudó, apenas. LCP pasó 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 (el JS principal de Shopify solo son ~200KB), y estás a merced de cualquier cosa que haga el tema y las aplicaciones.
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 momento tenía sentido por tres razones:
La Storefront API de Shopify había madurado significativamente. A principios de 2024, la Storefront API cubría casi todo lo que necesitarías para una experiencia de tienda completa, incluyendo gestión de carrito, cuentas de clientes, y acceso a metafields.
Shopify Checkout Extensibility ahora estaba disponible en Plus. Esto significaba que no necesitábamos reconstruir checkout (que, honestamente, es donde headless solía fallar).
El caso de negocio era claro. Si mejorar la velocidad del sitio podría reducir su CPC incluso 15-20% mientras mejora las tasas de conversión, el proyecto se pagaría a sí mismo dentro de 3-4 meses.
Eligiendo el Stack: Next.js, Hydrogen, y la Storefront API
Aquí es donde las cosas se ponen interesantes, porque tuvimos un debate genuino sobre el stack.
Los Contendientes
La respuesta oficial de Shopify para headless es Hydrogen — su framework basado en React construido sobre Remix. Está estrechamente integrado con las APIs de Shopify y desplegado en Oxygen (la plataforma de hosting de Shopify).
Pero finalmente optamos por Next.js 14 (App Router) usando la librería Hydrogen React de Shopify — no el framework completo de Hydrogen/Remix.
Aquí está el por qué:
| Factor | Hydrogen (Remix/Oxygen) | Next.js + Hydrogen React | Astro + Storefront API |
|---|---|---|---|
| Flexibilidad de SSR/SSG | Buena (Remix streaming) | Excelente (ISR, SSG, SSR, RSC) | Excelente (Islands, SSG) |
| Ecosistema React | Completo | Completo | Parcial (Islands) |
| Opciones de hosting | Solo Oxygen (o self-host) | Vercel, Netlify, AWS, self-host | Cualquier host estático + SSR |
| Profundidad de integración Shopify | Nativa | Vía @shopify/hydrogen-react | Llamadas manuales de API |
| Familiaridad del equipo | Baja | Alta | Media |
| Renderización Edge | Oxygen Workers | Vercel Edge, Cloudflare | Cloudflare, Netlify |
| Comunidad/ecosistema | En crecimiento | Masiva | En crecimiento rápido |
Consideramos Astro seriamente. Para un sitio rico en contenido con menos interactividad, el modelo de hidratación parcial de Astro habría sido ideal. Pero el sitio de GlowCo necesitaba mucha interactividad del lado del cliente — un quiz de cuidado de la piel, un generador de rutina de cuidado de la piel, cajones de carrito de agregar rápidamente, gestión de suscripción en tiempo real. React Server Components de Next.js nos dio el mejor equilibrio de rendimiento renderizado en servidor con riqueza del lado del cliente.
También elegimos desplegar en Vercel en lugar de Oxygen. Las capacidades de red edge de Vercel e ISR (Incremental Static Regeneration) nos dieron control de caché granular que no podríamos replicar fácilmente en Oxygen en ese momento.
Nuestro stack 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, landing pages, y posts de blog
- Vercel para hosting y funciones edge
- Recharge vía su API headless para suscripciones
- Klaviyo cargado asincrónicamente vía una 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 de 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 era innegociable. El motor de comercio de Shopify está probado en batalla 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 producto extrajeron 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 ops puede gestionar el inventario sin romper landing pages.
// Obtención de datos de página de producto simplificada (Next.js App Router)
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. Estos cambian aún menos frecuentemente.
- Homepage y landing pages: ISR con revalidación bajo demanda activada por webhooks de Sanity. Cuando el equipo de marketing publica, un webhook toca nuestro endpoint de revalidación.
- Páginas de carrito/cuenta: Totalmente del lado del cliente con shells renderizados en servidor. Estos son inherentemente dinámicos.
- Blog/editorial: Generación estática en tiempo de construcción con revalidación bajo demanda.
La Implementación del Carrito
Este 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 de UI optimistas. El carrito vive en la API Storefront de Shopify (no en estado local), lo que significa que persiste entre sesiones y dispositivos.
// Cajón de 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 solo puede aumentar la conversión de checkout en 50% para clientes recurrentes. Lo personalizamos usando Checkout UI Extensions para consistencia de marca y widgets de upsell, pero el flujo principal permanece nativo de Shopify.
Corrigiendo Core Web Vitals: Qué Realmente Movió la Aguja
Aquí está la parte que la mayoría de estudios de casos 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 de LCP más grande vino de tres cosas:
Eliminar recursos que bloquean la renderización. En el tema antiguo de Shopify, 14 scripts de terceros se cargaban sincrónicamente. En nuestra compilación de Next.js, CSS crítico está inlined, JavaScript está dividido en código y se carga solo donde es necesario, y los scripts de terceros se cargan después de que el contenido principal se pinta usando
next/scriptconstrategy="lazyOnload".Optimización de imágenes con
next/image. Servimos imágenes responsivas en formato WebP/AVIF, correctamente dimensionadas para cada viewport. Las imágenes del héroe pasaron de PNGs de 3MB a archivos AVIF de ~80KB. El elemento LCP (usualmente la imagen del héroe) ahora se carga como un recurso prefetched de prioridad.Almacenamiento en 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 se regenera en el fondo. La mayoría de visitantes nunca esperan una renderización del servidor.
CLS: De 0.42 a 0.02
El desplazamiento de layout fue causado por imágenes sin dimensiones, fuentes cargadas tarde (FOUT), y 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 fallbacks ajustados de tamaño - Sin widgets de terceros inyectados dinámicamente arriba del pliegue
- 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 de jQuery, y JavaScript pesado del lado del cliente bloqueando el hilo principal.
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 de carrito, selectores de productos, widget de quiz), redujimos dramáticamente la cantidad de JavaScript del lado del cliente. Nuestro bundle total de cliente para la página de producto bajó de 2.4MB a 187KB.
Los Números Después
| Métrica | Antes (Marzo 2024) | Después (Noviembre 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 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 Ganancia
Aquí es donde la goma toca el camino. Nadie migra a headless por diversión — el caso de negocio tiene que estar ahí.
El nuevo sitio se lanzó en fases entre julio y octubre de 2024. En noviembre, teníamos datos limpios para comparar. Los resultados fueron, francamente, mejores de lo que proyectamos.
Impacto Directo de Conversión
La tasa de rebote móvil bajó de 71% a 38%. Eso por sí solo es enorme — significa que 46% más visitantes se quedaban para incluso ver el producto. La tasa de conversión móvil pasó de 1.2% a 2.8%.
La tasa de conversión de escritorio mejoró de 2.4% a 3.9%.
Tasa de conversión mezclada general: 1.2% → 3.1%
Impacto de Plataforma de Anuncios
Esta es la parte que incluso nos sorprendió. Dentro de 6 semanas de que los Core Web Vitals pasaran verde en toda la junta:
- Google Ads CPC bajó 22% — La puntuación de experiencia de página de destino de Google mejoró, bajando directamente el costo por clic
- Meta Ads CPM disminuyó 18% — El algoritmo de Meta comenzó a mostrar más sus anuncios (mejor página de destino = puntuación de relevancia más alta = costos más bajos)
- La cuota de impresión de Google Shopping aumentó 34% — La 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 |
|---|---|---|---|
| Meta Ads | 1.8x | 5.2x | +189% |
| Google Search Ads | 2.1x | 7.4x | +252% |
| Google Shopping | 2.4x | 8.8x | +267% |
| Mezclado | 1.95x | 6.8x | +249% |
El aumento de ROAS mezclado de 249% vino de dos factores que se componen: 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
Sería negligente no mencionar el impacto en SEO. Dentro de 4 meses de que todos los Core Web Vitals se pusieran en verde:
- El tráfico orgánico aumentó 67%
- La posición promedio para palabras clave objetivo mejoró 4.2 posiciones
- El ingreso orgánico aumentó 89%
Google ha sido claro que la experiencia de página es una señal de clasificación. Esto fue prueba del mundo real.
Cronograma, Presupuesto y Costos Reales
Creo en la transparencia sobre lo que estos proyectos realmente cuestan. Aquí está el desglose real:
Cronograma: 7 meses desde el inicio hasta el lanzamiento completo (con un rollout en fases comenzando en el mes 5)
Equipo: 2 desarrolladores frontend senior, 1 especialista en backend de Shopify, 1 diseñador, 1 gerente de proyecto (tiempo parcial)
Costo total del proyecto: ~$145,000
Hosting/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 el aumento de ingresos del ROAS mejorado y tasas de conversión.
¿Es este tipo de inversión correcta para cada marca? No. Si haces menos de $1M anuales, las matemáticas probablemente aún no funcionan. Pero para marcas DTC gastando $50K+ mensuales en anuncios con Core Web Vitals pobres, el ROI está casi siempre ahí. Estamos felices de hablar sobre detalles específicos — contáctanos o revisa nuestros modelos de precios para proyectos de comercio headless.
Lecciones Aprendidas y Qué Haríamos Diferente
Qué Funcionó
- Mantener el checkout nativo de Shopify fue 100% la llamada 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.
- Rollout 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.
Qué Haríamos Diferente
- Comenzar la migración headless de Recharge antes. Su API headless tenía algunas peculiaridades que no anticipamos, y se comió 3 semanas de nuestro cronograma. Si estás usando Recharge, presupuesta tiempo extra.
- Configurar la infraestructura de pruebas A/B desde el día uno. La agregamos en el mes 2 y perdimos algunos datos de comparación temprana.
- Usar Vercel's Edge Config para feature flags en lugar del enfoque de variables de entorno con el que comenzamos. Habría hecho el rollout 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 de Shopify y tenerla aparezca en la tienda — cualquier nueva integración de terceros necesita trabajo de desarrollo. Para GlowCo, en su escala y gasto en anuncios, las ganancias de rendimiento superan con creces esta fricción. Pero es un tradeoff real que necesitas entender desde el principio.
FAQ
¿Cuánto tiempo toma 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 cuidado de la piel e integración de suscripción de 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 aplicaciones de Shopify dependientes de tema no funcionarán en una configuración headless. Las aplicaciones que inyectan UI en tu tienda (widgets de revisión, popups de lealtad, herramientas de upsell) necesitan ser reemplazadas con cualquier alternativa basada en API o componentes personalizados. Las aplicaciones de backend (gestión de inventario, envío, etc.) continúan funcionando bien ya que no tocan el frontend.
¿Es Hydrogen o Next.js mejor para Shopify headless?
Depende de tu equipo y requisitos. Hydrogen (construido sobre Remix) ofrece integración de Shopify más ajustada de la caja y es la ruta oficialmente respaldada por Shopify. Next.js ofrece un ecosistema más grande, más flexibilidad de hosting, y React Server Components. Elegimos Next.js para GlowCo porque de la experiencia existente del equipo y capacidades de caché edge de Vercel. Ambas son opciones excelentes.
¿Cuánto cuesta una migración headless de Shopify en 2026?
Presupuestos realistas oscilan entre $80,000 y $250,000+ dependiendo de la complejidad de la tienda, características personalizadas, y tarifas de agencia. El proyecto de GlowCo fue $145,000. Ten cuidado con agencias que cotizan por debajo de $50K por una compilación headless completa — probablemente obtendrás una plantilla con personalización limitada. Los costos de infraestructura mensual típicamente rondan $200-600 para hosting y CMS.
¿Los Core Web Vitals realmente afectan los costos de Google Ads?
Sí. Google Ads usa una puntuación de "Landing Page Experience" como parte del cálculo de Quality Score. Mejor velocidad de página y puntuaciones de Core Web Vitals conducen a puntuaciones de Quality Score más altas, lo que directamente reduce tu costo por clic. GlowCo vio una reducción de CPC de 22% después de que sus Core Web Vitals mejoraron. Meta usa señales similares para puntuación de relevancia de anuncios.
¿Puedes mantener el checkout de Shopify al ir headless?
Absolutamente, y lo recomendamos fuertemente. El checkout de Shopify está altamente optimizado e incluye características como Shop Pay (que puede impulsar la conversión de checkout 50%+ para compradores recurrentes). Con Shopify Plus, puedes usar Checkout Extensibility para personalizar la apariencia y agregar upsells mientras mantienes el flujo de checkout principal intacto.
¿Cuál es la diferencia entre Shopify headless y Shopify Hydrogen?
Shopify headless es un concepto amplio — cualquier frontend personalizado que use la API Storefront de Shopify. Hydrogen es el framework específico de Shopify para construir tiendas headless, construido sobre Remix y desplegado en el hosting Oxygen de Shopify. Puedes ir headless con Next.js, Astro, Nuxt, o cualquier framework. Hydrogen es solo una opción dentro del ecosistema más amplio de Shopify headless.
¿Vale la pena headless para pequeñas tiendas de Shopify?
Usualmente no. Si haces menos de $1M en ingresos anuales y gastas menos de $20K mensuales en anuncios, el costo de una migración headless probablemente no producirá un ROI significativo. Enfócate en optimizar tu tema existente primero — elimina aplicaciones no usadas, comprime imágenes, cambia a un tema enfocado en rendimiento como Dawn. Considera headless cuando tu gasto en anuncios sea lo suficientemente alto que incluso pequeñas ganancias de eficiencia se traduzcan en cantidades de dólares significativas.