Blog
Content Fragments o Experience Fragments: cuándo usar cada uno.
En resumen. Usa Content Fragments cuando lo que se reutiliza es el contenido: datos estructurados, sin diseño, que se muestran en varios canales o se entregan a una aplicación por API. Usa Experience Fragments cuando lo que se reutiliza es una experiencia ya armada: un grupo de componentes con su diseño que aparece igual en varias páginas, como un encabezado, un pie o una promoción. La pregunta que decide es si el diseño viaja con el contenido o lo pone cada canal.
¿Cuál es la diferencia real entre los dos?
Los dos sirven para no repetir contenido, y por eso se confunden. Pero resuelven problemas distintos:
- Un Content Fragment es contenido sin presentación. Sigue un modelo con campos tipados (texto, fecha, número, referencias a otros fragmentos) y vive en Assets, bajo /content/dam.
- Un Experience Fragment es contenido con presentación. Se arma con componentes sobre una plantilla editable, igual que una página, y vive bajo /content/experience-fragments.
- Al Content Fragment le da forma cada canal: el sitio con un componente, una aplicación móvil con su propio diseño. Al Experience Fragment lo diseña el autor una vez y se ve igual donde se inserte.
¿Cuándo conviene un Content Fragment?
Cuando el mismo contenido tiene que llegar a más de un lugar y cada lugar lo presenta a su manera. Los casos típicos:
- Entrega headless: una aplicación móvil, una SPA o un sitio fuera de AEM consumen el contenido por la API de GraphQL de AEM, con consultas persistidas que la CDN puede cachear.
- Contenido con estructura estable: fichas de producto, perfiles de personas, preguntas frecuentes, sucursales o avisos legales.
- Contenido que se consulta y filtra: listados por fecha, por categoría o por cualquier campo del modelo.
- Variaciones de un mismo texto (una versión corta y una larga, por ejemplo) sin duplicar el fragmento.
¿Cuándo conviene un Experience Fragment?
Cuando lo que se repite es una sección completa, con su diseño, y el autor quiere editarla en un solo lugar:
- Encabezados y pies de página compartidos por todo el sitio o por varios sitios.
- Banners, promociones y bloques de llamada a la acción que aparecen en muchas páginas.
- Ofertas para personalización: un Experience Fragment se puede exportar a Adobe Target como oferta.
- Canales que aceptan HTML ya armado: la representación en HTML plano (selector .plain.html) lo deja disponible para otros sistemas.
- Variaciones del mismo bloque por canal o por contexto, como una versión para web y otra para correo.
¿Se pueden combinar?
Sí, y a menudo es lo mejor. Un Experience Fragment puede incluir un componente de Content Fragment: el diseño queda en el Experience Fragment y los datos en el Content Fragment. Así, una promoción se arma una vez, y el precio, la vigencia o el texto legal se actualizan en su fragmento de contenido y llegan también a la aplicación que los consume por API.
¿Qué errores de modelado conviene evitar?
Estos son los patrones que buscamos cuando revisamos un proyecto de AEM heredado, porque cuestan caro de deshacer una vez que hay contenido real:
- Usar Experience Fragments como fuente de datos para otro canal y obligarlo a extraer el contenido del HTML.
- Guardar diseño dentro de un Content Fragment: campos de texto enriquecido con tablas, columnas o estilos que solo tienen sentido en una página.
- Modelos genéricos, con un título y un cuerpo libre, que no aprovechan los campos tipados y que no se pueden filtrar.
- Cadenas de referencias entre fragmentos demasiado profundas, que complican las consultas y la edición.
- Crear un Experience Fragment por página: si no se reutiliza, es un componente más y debería vivir en la página.
- No decidir desde el principio cómo se traduce cada tipo de fragmento: las copias por idioma y el flujo de traducción son distintos para cada uno.
¿Qué pasa con la caché al publicar un fragmento?
Es la parte que más sorprende en producción. Cuando una página incluye un Experience Fragment o un Content Fragment, AEM lo resuelve al renderizar la página, y el HTML que queda en la caché de Dispatcher y de la CDN ya lo trae dentro. Publicar el fragmento no invalida por sí mismo las páginas que lo usan.
Por eso conviene definir desde el diseño cómo se invalidan esas páginas: con la configuración de invalidación de Dispatcher, con tiempos de caché acordes a qué tan seguido cambia el fragmento o, en el caso de encabezados y pies, cargándolos por separado. En la entrega headless, lo que se revisa son las cabeceras de caché de las consultas persistidas.
Las preguntas con las que decidimos
Antes de crear el primer modelo o la primera plantilla, respondemos esto:
- ¿Este contenido se muestra en más de un canal, o solo en páginas del sitio?
- ¿El diseño lo decide el autor una vez, o cada canal lo presenta distinto?
- ¿Hace falta consultarlo o filtrarlo por sus campos?
- ¿Quién lo edita y con qué frecuencia cambia?
- ¿Cómo se traduce y cómo se invalida la caché cuando cambia?
En resumen
Si el diseño viaja con el contenido, es un Experience Fragment; si cada canal pone el suyo, es un Content Fragment; y si necesitas las dos cosas, combínalos. Si tu proyecto de AEM ya tiene fragmentos que nadie se atreve a tocar, una revisión del modelo de contenido antes de migrar o de rediseñar ahorra rehacerlo dos veces.