Shopify Partials: la etiqueta que se carga media capa de JavaScript de tu tema

El 21 de julio de 2026 Shopify publicó la vista previa para desarrolladores «Liquid July ’26», y dentro venía una etiqueta que lleva años haciendo falta: {% partial %}. La resumo en una frase y luego la abrimos: marca un trozo de la página como una región que JavaScript puede refrescar por su cuenta, sin recargar la página entera y sin escribir el renderizado en cliente.

Si has tocado alguna vez un selector de variantes, ya sabes por qué esto es noticia.

El problema que resuelve

Escenario de toda la vida. Ficha de producto, el usuario cambia de talla. Hay que actualizar el precio, el botón de compra, el estado de stock, la galería y a lo mejor un aviso de envío. Cinco trozos de página que dependen de un solo clic.

Hasta ahora tenías tres caminos, todos con peaje:

1. Recargar la página. Funciona. Es lento y se nota.
2. Section Rendering API. Pides una sección con ?sections=, te devuelve su HTML y lo pegas en el DOM. Es la solución oficial desde hace años y es correcta, pero te obliga a que cada trozo actualizable sea una sección entera, con su fichero y su schema. Actualizar el precio y el botón por separado significa dos secciones que nunca quisiste crear.
3. Renderizar en cliente. Te traes el JSON del producto y pintas el HTML con JavaScript. Rápido y flexible, y a cambio acabas manteniendo la misma plantilla dos veces: una en Liquid para el servidor y otra en JS para el navegador. Cuando alguien toca una y se olvida de la otra, aparece el bug clásico de «en el primer render se ve bien y al cambiar de variante se rompe».

Qué hace Partials

La sintaxis es tan sosa que casi decepciona, y eso es exactamente lo bueno:

{% partial 'product-price' %}
  <span class="price">{{ product.selected_variant.price | money }}</span>
{% endpartial %}

Marcas la región en el sitio donde ya estaba, dentro de la plantilla. No creas un fichero nuevo, no montas un endpoint, no declaras un schema. Y desde JavaScript la refrescas con los ayudantes del paquete @shopify/partial-rendering:

// refrescar varias regiones de la URL actual
await partials.refresh('product-price', 'product-cta');

// o con control total sobre la petición
const update = await partials.fetch('product-grid', { url: url.toString() });
partials.apply(update);

La diferencia de fondo con el renderizado en cliente es que el HTML lo sigue generando el servidor con tu Liquid de siempre. Hay una sola plantilla. No hay dos verdades que sincronizar.

Dónde se nota

Los sitios obvios son los cuatro de siempre, y son justo los que más ingresos mueven:

• Selector de variantes en la ficha de producto.
• Filtros y ordenación en colecciones, sin recargar el listado entero.
• Paginación y cargar más productos.
• Carrito: contador, resumen y bloque de envío gratis.

Y sí, el argumento de rendimiento es real: menos HTML por petición, menos trabajo del navegador y menos JavaScript propio que descargar, parsear y mantener. En una ficha pesada eso se traduce en interacción más rápida. Ahora bien, cuidado con las cifras que circulan: cuando alguien te promete de 700 ms a 100 ms y entre un 5 % y un 10 % más de conversión, está contando su caso, no una ley física. Mide el tuyo antes y después. Es lo único que vale.

Lo que no te van a contar en el hilo de LinkedIn

Partials te quita el problema del renderizado. No te quita los problemas de haber quitado la recarga de página, que la documentación de Shopify enumera con una honestidad que se agradece:

• Peticiones que llegan tarde. Si el usuario cambia de variante tres veces seguidas, tienes tres peticiones en vuelo y la que llegue la última gana, aunque sea la más vieja. Se soluciona con AbortSignal, pero se soluciona tú.
• Estado de carga. Toca poner aria-busy y algún indicador visual, o el usuario clica y no pasa nada aparente durante 200 ms, que es tiempo de sobra para volver a clicar.
• Lectores de pantalla. Un trozo de DOM que cambia sin recargar la página no se anuncia solo. Hay que anunciarlo.
• Estado efímero en el DOM. Todo lo que hubiera dentro de la región y no viniera del servidor —un input a medio rellenar, un acordeón abierto— desaparece al refrescar.

Traducción: pasas de escribir cien líneas de renderizado a escribir veinte de accesibilidad y control de concurrencia. Sigue saliendo a cuenta, pero no es gratis.

Estado real: developer preview

Esto es importante y se pierde en el entusiasmo. Está en vista previa para desarrolladores. Se activa marcando «Liquid July ’26 changes» en las vistas previas de funcionalidades, y la API puede cambiar antes de ser estable. No es material para meter mañana en la tienda que factura.

La buena noticia para quien ya tenga tema en producción: los temas actuales con secciones, ajustes y plantillas JSON siguen funcionando exactamente igual. Esto suma, no sustituye. Nadie tiene que migrar nada por ahora.

Qué haría yo hoy

Tres cosas, en este orden:

1. Activar la preview en un tema de desarrollo y portar una sola cosa: el bloque de precio de la ficha de producto. Es el caso más pequeño que enseña si esto encaja en tu arquitectura.
2. Medir de verdad. Tiempo hasta que el precio cambia en pantalla, con el móvil que usan tus clientes y no con tu portátil. Antes y después.
3. No reescribir el tema. La tentación de rehacerlo todo «ahora que se puede hacer bien» es la forma más rápida de convertir una mejora de rendimiento en un trimestre perdido.

Hay una lectura de fondo que a mí me parece la más interesante de todo esto. Shopify dice explícitamente que con estas etiquetas la estructura de la página vive en la plantilla Liquid, «donde desarrolladores y agentes de programación pueden leerlo y editarlo todo en un mismo sitio». O sea que parte del diseño está pensado para que una IA pueda entender y modificar un tema sin tener que reconstruir mentalmente qué pinta el servidor y qué pinta el cliente. Que es, casualmente, la razón por la que los temas con lógica repartida entre Liquid y JavaScript son tan incómodos de mantener también para los humanos.

Si estás valorando qué implica esto para tu tienda, en Pango Studio, agencia Shopify técnica en Madrid llevamos tiempo peleándonos con el renderizado de variantes; me alegra bastante poder borrar código.

Fuentes

• Shopify changelog — Liquid block and partial tags (developer preview)
• Documentación de la etiqueta Partial
• Section Rendering API, para comparar con lo que había