Hydrogen o Liquid en Shopify: cómo elegir arquitectura
Hydrogen o Liquid: compara arquitectura, rendimiento y costo de mantenimiento en Shopify. Guía técnica para decidir sin comprometer el roadmap.
Por Fernando Ruch
Si estás decidiendo entre Hydrogen o Liquid para el próximo ciclo de desarrollo de tu tienda Shopify, la respuesta corta es: depende. Depende de cuánto control sobre renderizado, UX y composición de frontend exige tu roadmap. Y depende de cuánta deuda técnica y retraso en el plazo estás dispuesto a asumir para ganar ese control. Liquid resuelve bien la mayoría de los casos con menor costo de mantenimiento. Hydrogen existe para cuando esa arquitectura deja de ser suficiente.
No es una elección ideológica entre "moderno" y "legado". Son dos modelos de arquitectura con trade-offs bien definidos. Uno funciona dentro de los rieles de Shopify. El otro te da libertad total de frontend a cambio de más responsabilidad de ingeniería. Este artículo compara ambos enfoques en el nivel que importa para quien va a sostener el sistema en producción: arquitectura, rendimiento, hosting, costo de mantenimiento y criterios objetivos de decisión.
Qué es Liquid y por qué sigue siendo la base estándar de las tiendas Shopify
Liquid es el lenguaje de plantillas nativo de Shopify. Según la documentación oficial de temas (shopify.dev), Liquid es la columna vertebral de los temas Shopify y se usa para cargar contenido dinámico en las storefronts. Los objetos de este lenguaje pueden extenderse mediante metafields para datos personalizados. Un tema Shopify es, en la práctica, un paquete de archivos de plantilla, bloques de construcción y assets de soporte. La propia Shopify aloja, versiona y sirve estos archivos directamente desde el CDN de la plataforma.
Desde la introducción de Online Store 2.0, la arquitectura de temas Liquid ganó un nivel de flexibilidad mucho mayor. Esto reduce buena parte de la justificación histórica para saltar a headless demasiado pronto. La documentación de Shopify describe esta migración como un camino para hacer el tema más flexible y fácil de mantener, permitiendo añadir y quitar secciones de cualquier plantilla y preparar el tema para app blocks.
Esto significa que los equipos de merchandising y producto pueden montar y reordenar páginas sin depender de un deploy de código para cada ajuste de layout. Es una ganancia real de velocidad operativa, muchas veces subestimada a la hora de justificar una migración a headless.
La estructura de un tema sigue un patrón previsible. El directorio templates controla qué se renderiza en cada tipo de página. El directorio assets guarda CSS, JS e imágenes. El directorio config guarda las configuraciones expuestas en el editor de temas.
Ese mismo directorio templates contiene los archivos de plantilla de un tema y permite añadir funcionalidad específica, como recomendaciones de producto en una PDP o un formulario de comentarios en una plantilla de artículo. Ninguna plantilla es obligatoria, pero es necesario tener una plantilla correspondiente para cada tipo de página que se quiera renderizar.
Para equipos técnicos, el punto práctico es simple: Liquid es el camino de menor fricción para entregar rápido. Mantiene SEO y Core Web Vitals bajo control de Shopify, sin cargar overhead de infraestructura propia.
Qué es Hydrogen y cuándo resuelve un problema real
Hydrogen es el framework React de Shopify para construir storefronts headless. Está hecho para consumir la Storefront API vía GraphQL. Es el camino recomendado cuando el frontend necesita hacer cosas que un tema Liquid, incluso en Online Store 2.0, no soporta de forma limpia.
Esto incluye composición de contenido fuera del estándar de e-commerce y experiencias con lógica client-side pesada. También cubre integración con sistemas de renderizado compartidos entre múltiples propiedades digitales, o requisitos de UX que se salen del modelo de secciones y bloques.
Hydrogen corre junto con Oxygen, el hosting gestionado de Shopify para storefronts headless. La documentación oficial (shopify.dev) impone límites técnicos estrictos sobre este entorno: el tiempo de arranque del worker (startup time) debe ser de 400 milisegundos o menos. El deploy también puede consumir como máximo 128 MB de memoria, bajo riesgo de que se descarten peticiones al superar el límite.
Estos números no son un detalle de infraestructura, son una restricción de arquitectura. Cualquier decisión de bundling, server components o dependencia pesada en el frontend headless tiene que respetar ese presupuesto de cold start y memoria. De lo contrario, la tienda empieza a tirar peticiones en producción bajo carga.
Un ejemplo público, documentado por la propia Shopify en su blog institucional, ilustra este trade-off. Cuando una agencia reconstruyó Shopify Supply usando una versión temprana de Hydrogen, el proyecto exigió componer UX con assets complejos como modelos 3D, algo fuera del alcance natural de un tema Liquid.
La misma publicación es honesta sobre el costo de esta elección. Reconoce que ir headless típicamente cuesta más caro al cliente y puede tardar más en estructurarse y construirse. El motivo es que el equipo de desarrollo dedica más tiempo a construir desde cero funcionalidades de comportamiento del consumidor que un tema ya entrega listas.
Es el trade-off central que cualquier Tech Lead necesita poner sobre la mesa antes de aprobar la migración. La libertad de frontend tiene precio en velocidad de entrega y en superficie de mantenimiento.
Hydrogen o Liquid: comparación directa por criterio técnico
Criterio | Liquid (Online Store 2.0) | Hydrogen |
|---|---|---|
Control de renderizado | Limitado al modelo de secciones y bloques del tema | Completo: React Server Components y enrutamiento definidos por el propio equipo |
Hosting | Gestionado por Shopify, sin infraestructura propia que mantener | Oxygen (gestionado) o self-host, con límites estrictos de cold start y memoria |
Velocidad de implementación | Alta para catálogo, PDP y checkout dentro del estándar de la plataforma | Menor: exige reconstruir capas que el tema ya entrega listas |
Mantenimiento a largo plazo | Bajo: las actualizaciones de plataforma corren por cuenta de Shopify | Alto: el equipo interno sostiene todo el código del frontend |
Casos ideales | E-commerce estándar, catálogo amplio, multi-tema, operación ágil | UX fuera de lo estándar, composición de contenido avanzada, multi-storefront |
Dependencia de app blocks | Nativa y de primera clase | Exige reimplementar el equivalente o integrar vía API |
En la práctica, la decisión raramente es binaria entre "todo Liquid" o "todo Hydrogen". Los equipos maduros suelen mantener el catálogo principal en Liquid y aíslan en Hydrogen solo los recorridos que realmente necesitan composición de frontend diferenciada, como landing pages de campaña, configuradores de producto o experiencias headless para un subconjunto de mercados.
Señales de que Liquid todavía es suficiente
El cuello de botella real es operativo (rendimiento de PDP, integración de datos, tiempo de carga), no una limitación genuina de composición de frontend.
El equipo de producto/merchandising necesita editar layout sin depender de un deploy. Esto es exactamente lo que resuelve Online Store 2.0, al permitir añadir y quitar secciones de cualquier plantilla.
No tienes una justificación de UX concreta para headless, solo la sensación genérica de que "headless es más moderno". Eso no es un criterio técnico, es hype.
Tu stack de apps de terceros (reviews, upsell, personalización) depende de app blocks nativos. Funcionan de forma directa en temas 2.0, pero exigen reingeniería en Hydrogen.
Señales de que Hydrogen se justifica
La UX exige composición de contenido, renderizado condicional o interactividad que el modelo de secciones de Liquid no soporta sin parches.
Necesitas una capa de frontend compartida entre múltiples storefronts o marcas, con lógica de presentación centralizada.
Tu roadmap ya mapeó el presupuesto de rendimiento bajo los límites reales de Oxygen (cold start, memoria). El equipo también tiene capacidad para sostener ese código en producción, no solo para escribirlo una vez.
Existe presupuesto y plazo alineados con el negocio para absorber el costo más alto de construcción. La propia Shopify reconoce esto públicamente como parte del trade-off headless.
Conclusión
Hydrogen y Liquid no compiten por el mismo problema. Liquid, especialmente en Online Store 2.0, cubre la mayoría de los escenarios de e-commerce, con menor costo de mantenimiento y cero infraestructura propia que sostener.
Hydrogen resuelve el subconjunto real de casos en los que el frontend necesita una libertad que el modelo de temas no entrega. Esa ganancia tiene costo: más tiempo de construcción, más responsabilidad de ingeniería y límites técnicos estrictos de hosting. Esos límites deben entrar en la cuenta desde el diseño de la arquitectura.
La pregunta correcta no es qué tecnología es mejor. Es qué deuda técnica tu contexto actual puede permitirse pagar ahora mismo.
Si tu equipo está evaluando esta decisión y quiere validar el trade-off con quien ya sostuvo arquitectura Shopify (Liquid e Hydrogen) en producción bajo presión de plazo y sin aumentar el equipo interno, agenda una conversación con Develoci. Revisamos tu escenario específico antes de comprometer el roadmap.