Shopify desde adentro: cómo el sistema de temas liquid construye tiendas escalables
La mayoría de los comerciantes interactúan con Shopify a través de su panel de administración: subiendo productos, configurando el envío, gestionando descuentos. Pero detrás de cada tienda de alto rendimiento hay un motor de renderizado que determina qué tan rápido cargan las páginas, con qué flexibilidad los comerciantes pueden personalizar su tienda, y si la arquitectura puede escalar cuando el negocio lo exige. Ese motor es Liquid, el lenguaje de plantillas de código abierto de Shopify, y entender cómo funciona es la diferencia entre una tienda que se arma con parches y una que se ingenia con precisión.
Esta publicación profundiza en cómo Liquid impulsa el sistema de temas de Shopify, por qué Online Store 2.0 cambió la arquitectura de manera fundamental, y cómo luce en la práctica el desarrollo de temas escalables — no en teoría.
Cómo funciona Liquid: el motor de renderizado detrás de cada tienda Shopify
Liquid es un lenguaje de plantillas basado en Ruby creado por Shopify en 2006. Desde entonces se ha publicado como código abierto y se utiliza en múltiples plataformas, pero su integración más profunda sigue siendo en el pipeline de renderizado de temas de Shopify. Cada página que ve un cliente — páginas de producto, páginas de colección, carrito, checkout — es generada por plantillas Liquid que combinan marcado estático con datos dinámicos extraídos del backend de Shopify.
El lenguaje opera sobre tres construcciones fundamentales:
- Objetos: Exponen los datos de la tienda a las plantillas.
{{ product.title }},{{ cart.total_price }},{{ shop.name }}— los objetos dan a las plantillas acceso a la capa de datos en tiempo real sin requerir llamadas a la API desde el navegador. - Tags: Flujo de control y lógica.
{% if %},{% for %},{% unless %},{% paginate %}— los tags permiten que las plantillas respondan a condiciones, iteren sobre colecciones y gestionen la estructura de salida. - Filtros: Transforman la salida de forma inline.
{{ product.price | money }},{{ 'image.jpg' | img_url: '800x' }},{{ article.published_at | date: '%B %d, %Y' }}— los filtros formatean, convierten y manipulan valores antes de que sean renderizados.
El ciclo request-response en Shopify
Cuando un cliente accede a una URL de producto, los servidores de Shopify identifican el recurso solicitado, resuelven el tema activo y renderizan la plantilla Liquid correspondiente del lado del servidor. El HTML completamente renderizado se entrega entonces al navegador. Esto es fundamentalmente diferente a los frameworks de JavaScript del lado del cliente — no hay un HTML esqueleto esperando respuestas de la API. La página llega completa.
Esta arquitectura tiene implicaciones directas en el rendimiento. Dado que Liquid renderiza del lado del servidor:
- El Time to First Byte (TTFB) es rápido — el servidor realiza el trabajo pesado
- Los motores de búsqueda reciben HTML completamente renderizado — no se requiere ejecución de JavaScript para la indexación
- Las métricas de Core Web Vitals como Largest Contentful Paint (LCP) se benefician de la reducción de la sobrecarga de renderizado del lado del cliente
Jerarquía de plantillas y estructura de archivos
Un tema de Shopify es un directorio estructurado de archivos. Los directorios clave son:
theme/
├── layout/
│ └── theme.liquid # Contenedor del layout principal
├── templates/
│ ├── product.json # Plantilla JSON de OS2.0
│ ├── collection.json
│ └── index.json
├── sections/
│ ├── product-main.liquid
│ ├── featured-collection.liquid
│ └── header.liquid
├── snippets/
│ ├── product-card.liquid
│ └── icon-cart.liquid
├── assets/
│ ├── theme.css
│ └── theme.js
└── config/
├── settings_schema.json
└── settings_data.jsonEl archivo layout/theme.liquid es el contenedor más externo — contiene las etiquetas <html>, <head> y <body>, y utiliza {{ content_for_layout }} para inyectar la salida de la plantilla renderizada. Cada solicitud de página pasa por este layout a menos que se especifique uno alternativo.
Los snippets son parciales reutilizables — piense en ellos como componentes que las secciones y plantillas pueden incluir mediante {% render 'product-card' %}. A diferencia de {% include %} (ahora obsoleto), {% render %} crea un scope aislado, evitando la filtración de variables entre contextos — una distinción crítica para plantillas mantenibles y predecibles.
Trabajando con el modelo de objetos de Liquid
Shopify expone un conjunto rico de objetos globales y específicos por contexto. En una página de producto, el objeto product da acceso a datos anidados:
{% for variant in product.variants %}
<option
value="{{ variant.id }}"
{% unless variant.available %}disabled{% endunless %}
>
{{ variant.title }} — {{ variant.price | money }}
</option>
{% endfor %}El objeto cart es accesible globalmente, lo que permite que las plantillas del encabezado muestren el conteo del carrito en tiempo real sin llamadas adicionales a la API. El objeto shop expone la configuración a nivel de tienda. El objeto request proporciona datos de URL, ruta y locale útiles para el renderizado condicional en tiendas multirregión.
Comprender el modelo de objetos en profundidad — saber qué datos están disponibles en qué contextos, qué requiere llamadas adicionales a la API y qué puede almacenarse en caché — es lo que distingue a los desarrolladores que construyen temas Liquid rápidos de aquellos que crean cuellos de botella de rendimiento sin darse cuenta.
Online Store 2.0: el cambio arquitectónico que lo transformó todo
Antes de Online Store 2.0, los temas de Shopify tenían una estructura rígida. Las secciones — los bloques de contenido modulares y de arrastrar y soltar que los comerciantes podían configurar en el editor de temas — estaban limitadas a la página de inicio. Todos los demás tipos de plantilla (producto, colección, blog, página) utilizaban archivos Liquid estáticos sin capacidad nativa de edición mediante arrastrar y soltar. Personalizar el diseño de una página de producto requería cambios en el código. Los comerciantes estaban limitados a la estructura que el desarrollador del tema había codificado de forma fija.
Online Store 2.0, lanzado en 2021, eliminó por completo esa restricción.
Plantillas JSON: desacoplando la estructura del contenido
El cambio arquitectónico más significativo en OS2.0 es la introducción de las plantillas JSON. En lugar de que una página de producto esté definida por un único archivo product.liquid, ahora está definida por un archivo product.json que declara qué secciones aparecen en la página y en qué orden:
{
"sections": {
"main": {
"type": "product-main",
"settings": {
"show_vendor": true,
"enable_sticky_info": true
}
},
"related-products": {
"type": "related-products",
"settings": {
"products_to_show": 4
}
}
},
"order": ["main", "related-products"]
}Este archivo JSON es el que lee el editor de temas. Los comerciantes pueden agregar, eliminar y reordenar secciones en cualquier tipo de página — no solo en la página de inicio. Los desarrolladores definen las secciones disponibles y sus configuraciones; los comerciantes controlan la composición. La separación es limpia y deliberada.
Sections Everywhere y App Blocks
Con OS2.0, la capacidad de "Sections Everywhere" significa que cualquier plantilla puede construirse a partir de una pila de secciones configurables. Cada sección es un archivo .liquid que declara su propio schema — las configuraciones, bloques y presets que controlan su comportamiento en el editor de temas:
{% schema %}
{
"name": "Product Main",
"blocks": [
{
"type": "title",
"name": "Product Title",
"limit": 1
},
{
"type": "price",
"name": "Price",
"limit": 1
},
{
"type": "variant-picker",
"name": "Variant Picker",
"limit": 1
},
{
"type": "@app"
}
]
}
{% endschema %}El tipo de bloque "type": "@app" es particularmente poderoso. Crea un espacio donde los desarrolladores de aplicaciones de Shopify pueden inyectar sus propios bloques — widgets de reseñas, insignias de fidelidad, guías de tallas — directamente en la sección, sin modificaciones en el código del tema. Esta es la capa de integración que permite que el ecosistema de aplicaciones de Shopify funcione de manera limpia con temas personalizados.
Metafields y Metaobjects: datos estructurados sin aplicaciones personalizadas
OS2.0 también elevó los metafields de una preocupación exclusiva de la API para desarrolladores a una funcionalidad de primera clase en los temas. Los metafields permiten a las tiendas adjuntar datos estructurados a cualquier recurso — productos, variantes, colecciones, clientes, pedidos. En las plantillas Liquid, son accesibles a través del objeto del recurso:
{{ product.metafields.custom.care_instructions.value }}
{{ product.metafields.specifications.weight_grams.value | append: 'g' }}Los metaobjects van más allá — son estructuras de datos personalizadas que pueden definirse en el panel de administración de Shopify y referenciarse en múltiples recursos. Un metaobject "Material" podría contener campos para nombre, descripción, calificación de sostenibilidad e imagen. Los productos referencian ese metaobject en lugar de duplicar los datos. En Liquid:
{% assign material = product.metafields.custom.material.value %}
<p>{{ material.name }}</p>
<p>{{ material.description }}</p>Para catálogos de productos complejos — particularmente en contextos B2B y mayoristas — los metaobjects eliminan la necesidad de aplicaciones personalizadas para gestionar contenido estructurado. Esto reduce directamente la dependencia de aplicaciones, mejora los tiempos de carga de páginas y simplifica el mantenimiento a largo plazo.
Construyendo temas escalables: decisiones arquitectónicas que se acumulan con el tiempo
La escalabilidad en el desarrollo de temas de Shopify no es una decisión única — es un conjunto de elecciones arquitectónicas tomadas tempranamente que se acumulan en mantenibilidad o se convierten en deuda técnica. Los temas que resisten picos de tráfico, el crecimiento del catálogo de productos y la incorporación de nuevas funcionalidades son aquellos donde estas decisiones se tomaron de forma deliberada.
Arquitectura de secciones basada en componentes
Los temas Liquid más escalables tratan las secciones y los snippets como un sistema de componentes. Cada sección es responsable de una pieza de UI única y bien definida. Los snippets manejan subcomponentes reutilizables. El objetivo es minimizar la duplicación y maximizar la composabilidad.
Un patrón práctico es el enfoque de "render con parámetros", donde los snippets aceptan variables explícitas:
{% render 'product-card',
product: featured_product,
show_vendor: true,
image_ratio: 'square',
lazy_load: true
%}Dado que {% render %} crea un scope aislado, el snippet solo tiene acceso a las variables que se le pasan explícitamente. Esto previene los errores de "acción a distancia" que afectan a los temas construidos con {% include %}, donde cualquier variable definida en cualquier parte de la cadena de plantillas es accesible dentro del parcial.
Ingeniería de rendimiento a nivel de plantilla
Los Core Web Vitals son un factor de posicionamiento directo, y la arquitectura del tema Liquid tiene un impacto significativo en ellos. Los patrones clave de rendimiento incluyen:
Carga diferida de imágenes con atributos nativos y los filtros de imagen de Shopify:
<img
src="{{ product.featured_image | img_url: '800x' }}"
srcset="
{{ product.featured_image | img_url: '400x' }} 400w,
{{ product.featured_image | img_url: '800x' }} 800w,
{{ product.featured_image | img_url: '1200x' }} 1200w
"
sizes="(max-width: 768px) 100vw, 50vw"
loading="lazy"
width="800"
height="800"
alt="{{ product.featured_image.alt | escape }}"
>Diferir JavaScript no crítico usando los atributos defer y type="module", manteniendo el hilo principal libre durante el renderizado inicial.
Carga de CSS a nivel de sección — limitando los estilos a las secciones que los necesitan en lugar de cargar una hoja de estilos monolítica, reduciendo el CSS que bloquea el renderizado.
Evitar loops de Liquid en rutas de renderizado críticas — los loops {% for %} complejos con acceso a objetos anidados en plantillas de alto tráfico (páginas de producto, páginas de colección) deben perfilarse con cuidado. Cuando los datos pueden pre-estructurarse en metafields o pasarse a través de la configuración de secciones, eso es preferible a calcularlos en tiempo de renderizado.
Arquitectura multirregión y multimoneda
Para las tiendas Shopify Plus que operan en múltiples mercados, la arquitectura del tema debe contemplar Shopify Markets desde el primer día. Esto implica:
- Usar
{{ localization.available_countries }}y{{ localization.available_languages }}para construir selectores de moneda e idioma que funcionen con el enrutamiento de mercados nativo de Shopify - Estructurar las URLs con los prefijos de locale en mente — Shopify Markets enruta el tráfico a
/en-us/,/de-de/, etc., y las plantillas deben manejar estas rutas correctamente - Evitar cadenas de texto codificadas de forma fija en las plantillas Liquid — todo el texto visible para el usuario debe pasar por el filtro
t, extrayendo valores de los archivos de locale en el directoriolocales/:
{{ 'products.product.add_to_cart' | t }}
{{ 'cart.general.subtotal' | t }}Esto no es solo una buena práctica para la internacionalización — es un requisito previo para cualquier desarrollo en Shopify Plus orientado a múltiples regiones.
Arquitectura de configuraciones del tema para la mantenibilidad a largo plazo
El archivo settings_schema.json define las configuraciones globales disponibles en el editor de temas — tipografía, colores, espaciado, interruptores de funcionalidades. La forma en que este archivo está estructurado determina cuánta flexibilidad tienen los comerciantes sin necesidad de intervención de un desarrollador.
Un schema de configuraciones bien arquitectado utiliza design tokens como base:
{
"name": "Colors",
"settings": [
{
"type": "color",
"id": "color_primary",
"label": "Primary",
"default": "#1a1a1a"
},
{
"type": "color",
"id": "color_accent",
"label": "Accent",
"default": "#e63946"
}
]
}Estas configuraciones se referencian luego en CSS mediante propiedades personalizadas generadas por Liquid:
<style>
:root {
--color-primary: {{ settings.color_primary }};
--color-accent: {{ settings.color_accent }};
}
</style>Este patrón significa que un comerciante puede rediseñar la identidad visual de toda la tienda — cambiando colores primarios, escalas tipográficas, espaciado — sin tocar una sola línea de CSS. También significa que cuando un desarrollador necesita actualizar estilos, trabaja con un sistema de tokens coherente en lugar de buscar valores hexadecimales codificados de forma fija en decenas de archivos.
Cuándo los temas personalizados superan a los del Theme Store
La economía del desarrollo de temas de Shopify suele malinterpretarse. Un tema premium del Shopify Theme Store cuesta entre $300 y $500 USD. Un tema Liquid personalizado de una agencia especializada cuesta significativamente más. La pregunta no es cuál es más económico por adelantado — sino cuál es más económico durante toda la vida útil de la tienda.
Las compras en el Theme Store vienen con restricciones: estructuras de secciones con criterios propios que pueden no coincidir con el sistema de diseño de la marca, sobrecarga de rendimiento por funcionalidades que la tienda no utiliza, ciclos de actualización que pueden entrar en conflicto con modificaciones personalizadas, y capacidad limitada para implementar patrones de UX genuinamente diferenciados. A medida que las tiendas crecen — más SKUs, más mercados, requisitos B2B más complejos — estas restricciones se acumulan.
Los temas Liquid personalizados construidos sobre la arquitectura OS2.0, con sistemas de componentes limpios, integración adecuada de metafields e ingeniería orientada al rendimiento, escalan junto con el negocio. No requieren reconstrucción cuando el catálogo crece a 10.000 productos o cuando el negocio se expande a tres nuevos mercados. Ese es el retorno acumulado de la inversión arquitectónica.
En werun.dev, cada tema de Shopify que construimos comienza desde cero — sin clones modificados de Debut, sin bases del Theme Store despojadas de su branding. Arquitecturamos desde los fundamentos de OS2.0 con plantillas JSON, Sections Everywhere e integración de metafields incorporada desde el primer día, optimizados para Core Web Vitals y diseñados para la mantenibilidad a largo plazo. Si su tienda ha superado su tema actual o está planificando un desarrollo que necesita escalar, inicie un proyecto con nosotros.