Akeneo PIM se encuentra con el storefront de Magento: por qué la capa de frontend es el verdadero cuello de botella

Akeneo ofrece un modelo de datos de producto limpio y heredable. El storefront predeterminado de Magento no puede llevarlo al navegador sin que se rompan el rendimiento, la búsqueda por facetas o la localización. Si te tomas Akeneo en serio, necesitas un storefront desacoplado, y eso no tiene por qué ser un proyecto de nueve meses.

Veamos dónde reside realmente la fricción.

Qué te da realmente Akeneo, y por qué eso es valioso para el frontend

Akeneo no es una hoja de cálculo de producto sofisticada. El núcleo de la plataforma es un modelo de datos estructurado construido en torno a cuatro conceptos que conviene entender con precisión:

Family: Una Family agrupa todos los atributos que se aplican a una categoría de productos. La Family "Outerwear" tiene campos obligatorios distintos de la Family "Audio Speakers". Esto significa que el PIM sabe exactamente qué atributos debe tener un producto, cuáles son opcionales y cómo se relacionan entre sí. Una Family define el contrato entre la estructura de datos y lo que el frontend recibe.

Family variant: Cuando los productos tienen variaciones, tallas S/M/L, colores rojo/azul, la Family variant define cómo funciona la herencia de atributos entre los niveles de variante. El precio puede residir en el nivel de variante, mientras que la imagen principal y los textos de marketing residen en el nivel de product model. Es esta jerarquía la que hace posibles páginas de producto limpias con una separación intencionada de atributos. El modelo de variante es explícito: los atributos no se duplican al azar entre niveles, sino que residen exactamente donde corresponde.

Channel: Un Channel representa un destino de salida con su propio conjunto de locales, monedas y categorías activadas. Tu tienda web B2C es un Channel. Tu portal B2B es otro. Un feed de Amazon es un tercero. Los atributos pueden tener un ámbito ligado al Channel: lo que expones en el Channel B2C no es necesariamente lo que recibe el portal B2B.

Locale: Dentro de un Channel, un atributo puede ser localizable, es decir, mantener valores distintos por idioma. Título del producto en inglés, título del producto en alemán, título del producto en francés: todos almacenados por separado, todos servidos correctamente según el locale que solicita el frontend.

El resultado: Akeneo entrega al frontend una carga JSON coherente y estructurada, con jerarquías explícitas, valores sensibles al locale y selecciones específicas por Channel. Se supone que el frontend solo tiene que "renderizar y ya".

El problema: el storefront predeterminado de Magento no fue diseñado para gestionar este modelo en su totalidad.

Dónde el storefront de Magento rompe el modelo

Magento tiene su propia estructura de producto, configurable products, simple products, grouped products, que se remonta a principios de la década de 2000 y se ha ido ampliando de forma incremental desde entonces. La integración con Akeneo pasa por plugins conectores que traducen la estructura de Akeneo a los attribute sets de Magento.

Surgen de forma recurrente tres problemas estructurales:

Problema 1: rigidez de las plantillas

Los temas Luma y la mayoría de los temas Hyva tienen estructuras de plantilla fijas por tipo de producto. Una Family variant con tres niveles de herencia (product model, submodel, variant) no se mapea de forma limpia sobre un configurable product de Magento. El conector aplana la estructura. Las jerarquías que se definieron con cuidado en Akeneo llegan al storefront como una lista de atributos indiferenciada.

Un ejemplo práctico: en Akeneo decidiste que "Material" es un atributo a nivel de Family compartido por todas las variantes, mientras que "Size" es específico de la variante. En el storefront de Magento ambos atributos aparecen en la misma interfaz de configuración, porque Magento no tiene ningún concepto semántico de esa distinción. El frontend los trata de forma idéntica.

Problema 2: limitaciones del índice y búsqueda por facetas

Akeneo exporta los productos hacia Magento a través de los Channel. Magento luego indexa esos datos en su propio índice Elasticsearch. Este proceso de indexación tiene dos debilidades recurrentes.

Primero, el índice es plano. Ejecutar una búsqueda por facetas sobre los atributos de Family de Akeneo, por ejemplo "muestra todo el outerwear con certificación de sostenibilidad" cuando la "certificación de sostenibilidad" es un atributo a nivel de Family, solo funciona si ese atributo se tradujo correctamente al attribute set de Magento y luego se configuró como atributo filtrable en la layered navigation. Cada adición de un atributo en Akeneo implica un paso manual de configuración en Magento.

Segundo, la layered navigation en catálogos grandes es un lastre para el rendimiento. Por encima de 50.000 productos con muchas facetas activas, la búsqueda predeterminada de Magento alcanza sus límites. Resolver esto requiere o bien un plugin de búsqueda (Algolia, Klevu, Elasticsuite) o una arquitectura diferente.

Problema 3: cambio de locale y renderizado sensible al Channel

Akeneo separa de forma nítida los Channel de los locales. Magento abstrae todo esto como store views: una store view corresponde aproximadamente a una combinación de idioma y sitio web. El mapeo entre los Channel de Akeneo y las store views de Magento no es trivial.

Un patrón habitual: activas el Channel "US Webstore" en Akeneo con los locales en_US y es_US. Magento tiene cuatro store views: US/English, CA/English, MX/Spanish y un fallback internacional. Qué store view consume qué Channel de Akeneo y qué locale de Akeneo debe configurarse en el conector, y revisarse cada vez que la configuración de Akeneo evoluciona.

El resultado: lo que estaba nítidamente separado en el PIM se convierte en una tarea de gestión de configuración en Magento, y cada cambio de configuración requiere un desarrollador.

Tres patrones de desacoplamiento con plazos concretos

No hay una respuesta universal a la pregunta "¿cuánto desacoplamiento necesito?". Pero existen patrones consolidados con un alcance predecible.

Patrón 1: tema Hyva con optimización del conector de Akeneo

El punto de partida pragmático. Hyva sustituye a Luma por un renderer más ligero y con mejor rendimiento. El conector de Akeneo permanece en su sitio, pero las plantillas del tema se ajustan para gestionar de forma más limpia las estructuras de atributos específicas de Akeneo.

Plazo: de 4 a 8 semanas de desarrollo, muy dependientes de la complejidad de la configuración de Akeneo.

Límites: la rigidez de las plantillas persiste. Las limitaciones de búsqueda no se resuelven sin un plugin de búsqueda adicional. El cambio de locale sigue siendo complejo si el mapeo entre store view y locale involucra varios mercados.

Cuándo tiene sentido: cuando tu configuración de Akeneo cubre uno o dos mercados, tus jerarquías de producto son relativamente planas y el problema principal es el rendimiento de renderizado más que la complejidad de los atributos.

Patrón 2: Hyva más una capa de búsqueda dedicada (Algolia o Klevu)

Resuelve el problema de la búsqueda. Algolia y Klevu indexan directamente desde el attribute set de Magento con mucho más control sobre facetas, reglas de boost y relevancia que la layered navigation nativa.

Plazo: de 6 a 12 semanas, más los costes recurrentes de licencia del plugin de búsqueda.

Límites: la rigidez de las plantillas y la complejidad del cambio de locale permanecen. El plugin de búsqueda aborda el problema del índice, no el del renderizado.

Cuándo tiene sentido: cuando el rendimiento de búsqueda y la búsqueda por facetas son impulsores de conversión primarios y estás dispuesto a asumir costes recurrentes de herramientas.

Patrón 3: storefront desacoplado con una capa FMP

Aquí la arquitectura cambia de forma fundamental. El storefront no se comunica a través de las plantillas de Magento, sino a través de una capa de API. Los datos de Akeneo pueden entregarse directamente o mediante una capa BFF (Backend for Frontend), evitando el motor de plantillas de Magento.

Plazo: de 8 a 16 semanas, según la complejidad de la integración y cuánto haya que mapear el modelo de datos de Akeneo a la estructura de componentes del frontend.

Ventajas: las jerarquías de Family variant pueden renderizarse correctamente. El cambio de locale ocurre a nivel de storefront, no como un salto entre store views de Magento. La búsqueda puede integrarse directamente con los Channel de Akeneo. Los cambios en las Family de Akeneo ya no desencadenan un proceso de configuración en Magento.

Cuándo tiene sentido: cuando sirves más de tres locales, tienes jerarquías de producto complejas que necesitan una representación precisa en el frontend, o cuando la búsqueda por facetas juega un papel crítico para la conversión.

Para un análisis más profundo de qué opciones de arquitectura existen para tu stack de Magento, consulta nuestra guía sobre frontend headless para Magento 2.

Qué asume realmente una capa FMP

Una Frontend Management Platform (FMP) no es Hyva ni PWA Studio. Es la capa que se sitúa entre el mundo backend de Magento y Akeneo y el navegador, dando tanto a los desarrolladores como a los marketers el control sin que cada cambio requiera una pipeline de despliegue.

Para el contexto Akeneo-Magento, tres capacidades son especialmente relevantes:

Cambio de locale a nivel de storefront. Una FMP renderiza datos de producto sensibles al locale directamente desde la API, sin un salto entre store views. Si Akeneo guarda un nombre de producto distinto para en_US frente a es_US, el storefront lo renderiza correctamente sin que nadie tenga que tocar la configuración de store views de Magento.

Renderizado sensible al Channel. Una FMP puede distinguir entre los Channel de Akeneo en el momento del renderizado. Un visitante B2C ve el Channel "US Webstore", un visitante B2B ve el Channel "B2B US", con precios distintos, atributos visibles distintos y categorías distintas. En una arquitectura Magento estándar, esto requiere instancias de Magento separadas o un middleware complejo.

Adaptador de API de búsqueda. En lugar de usar Elasticsearch de Magento directamente, una capa FMP puede construir su propia integración de búsqueda, Algolia, Typesense o indexación directa desde Akeneo. Las facetas provienen directamente de la estructura de atributos de Akeneo, no de una interfaz de configuración de Magento.

Esta es la diferencia arquitectónica entre Hyva (un renderer más rápido sobre Magento) y un desacoplamiento FMP (una capa de renderizado separada que trata a Akeneo y Magento como servicios de backend).

Para una comparación directa de las opciones de frontend para Magento, Hyva, PWA Studio y FMP, consulta Alternativa de frontend para Magento: ¿Hyva, PWA Studio o FMP?.

Marco de decisión: cuándo Hyva es suficiente, cuándo el desacoplamiento FMP es el mejor camino

No es una decisión técnica única para todos los casos. Depende de lo que necesites durante los próximos 18-24 meses.

Hyva es probablemente suficiente cuando:

• Tu configuración de Akeneo cubre menos de tres locales y un único Channel.
• Tus jerarquías de producto son poco profundas, sin estructuras complejas de Family variant.
• El rendimiento de búsqueda no es un impulsor de conversión primario.
• Tu equipo tiene capacidad para gestionar las actualizaciones de configuración de Magento cuando Akeneo cambia.
• Necesitas salir a producción dentro de una ventana de 4-8 semanas.

El desacoplamiento FMP merece la inversión cuando:

• Sirves más de tres locales o estás planificando seriamente una expansión multimercado.
• Tus estructuras de Family variant en Akeneo son complejas y necesitan una representación precisa en el frontend.
• La búsqueda por facetas juega un papel central en la conversión.
• No quieres que cada cambio en la estructura de Akeneo genere un ticket para un desarrollador de Magento.
• Estás construyendo hacia un stack de composable commerce en el que Magento debería ser sustituible en el lado del backend a medio plazo.

Para contextualizar dónde se sitúan Magento y el composable commerce de cara a la segunda mitad de 2026, la panorámica disponible en Composable Commerce en 2026: qué hizo bien el 83 por ciento y dónde siguen tropezando merece la pena leerla junto a este artículo.

Para ver cómo se ve en la práctica el desacoplamiento FMP en una configuración de Magento con Akeneo, organizamos una sesión de demo enfocada, con un breve campo de contexto "usamos Akeneo" que se rellena de antemano, para poder adaptar la conversación a tu stack real.

En resumen

Akeneo es una inversión sólida en la calidad de los datos de producto. Pero una inversión en la calidad de los datos de producto solo se rentabiliza si el frontend es realmente capaz de renderizar esa calidad.

El storefront predeterminado de Magento no es un mal sistema. Se construyó para otra época, una que no anticipó jerarquías PIM limpias con complejidad multi-locale y multi-channel que necesitan una entrega precisa al navegador.

Si Hyva con un plugin de búsqueda te basta, o si el desacoplamiento FMP es el siguiente paso adecuado, depende de tu configuración específica de Akeneo, de tu cobertura de mercado y de tus requisitos de conversión. Podemos ayudarte a averiguarlo.

Solicita una demo, con el contexto de Akeneo por adelantado

*Este post forma parte del clúster Laioutr frontend headless para Magento 2. El argumento sigue el Pillar 2 (headless-per-backend) y el Pillar 3 (Composable Commerce) de nuestra estrategia de contenidos.*

Lecturas relacionadas en Laioutr

• Composable Digital Experience Platform
• Composable Headless Frontend