A la hora de elegir CMS, hay que tener muchos parámetros en cuenta. Uno de ellos es sin duda la elección entre una arquitectura tradicional, monolítica, en la que backend y frontend siguen siendo matrimonio inseparable, o elegir la arquitectura moderna, headless, sin cabeza. Decantarse por esto último tiene muchas ventajas y algunos inconvenientes, pero parece que el mercado no ha percibido correctamente dichas ventajas o ha pensando que los inconvenientes son muy grandes, pues desde CMS MAG no apreciamos un gran recibimiento del headless en España.
Cambia de CMS gratis con expertos
¿Tu CMS te tiene desesperado?
Cambia a un nuevo CMS más rápido y seguro, con inteligencia artificial (IA) e incluso consigue ahorro:
No vamos a detenernos en este artículo en explicar de nuevo qué es un CMS headless, puesto que ya lo hicimos en su momento. Quizás sí es de recibo volver a repasar sus principales ventajas:
Las ventajas de los CMS headless son muchas y muy variadas:
- Mayor seguridad. El backend puede esconderse mejor de los ciberdelincuentes.
- Más estabilidad y actualizaciones: El backend se puede actualizar sin afectar al frontend.
- Escalabilidad: Desde un CMS headless también se podría alimentar una app y muchos otros canales sin necesidad de más CMS ni duplicar los contenidos. Mejor reutilización del contenido.
- Flexibilidad: En el frontend se pueden diseñar versiones adaptadas a cualquier dispositivo con, en teoría, mayor y mejor rendimiento. Y, por otro lado, flexibilidad también en el sentido de que mediante APIs, y microservicios es realtivamente fácil conectar cualquier servicio moderno de terceros.
- Ahorro de costes: Generalmente suelen suponer ahorro de costes a largo plazo, pero a corto plazo los precios suelen ser más altos que con la arquitectura tradicional.
- Aumenta la velocidad: Backend y frontend pueden trabajar de forma independiente sin bloquearse mutuamente, lo que redunda en mayor velocidad de lanzamientos al mercado.
- Menor riesgo de vendor lock-in: Mediante la API el cliente siempre puede extraer los datos cuando desee y el dueño del CMS no tiene ni por qué enterarse.
Repasemos también sus desventajas:
- Mayor complejidad técnica: Al separar back y front, debe haber diferentes equipos para cada cosa que deben coordinarse bien.
- Coste inicial: El headless puede implicar mayor precio al principio. En proyectos con mucha personalización, el coste, obviamente, se puede disparar bastante.
- Sin frontend listo para usar: Muchos CMS headless ofrecen su parte, el backend, si bien no la parte frontal, la que ve el usuario. Solo los mejores ofrecen también buenas plantillas para el front desde las que comenzar a trabajar en la personalización.
- Se usa un integrador: Debido a la complejidad técnica, a veces los dueños del CMS no son los que hacen la implemetación, sino que delegan en terceros.
- Ritmo de mejoras condicionado por el proveedor: Es frecuente que el backend lo lleve la empresa de CMS y se encuentre en la nube. En muchos casos, además, todos los clientes evolucionan juntos y no hay demasiado poder a la hora de priorizar ciertas peticiones. Deben ser los propios clientes entonces los que procedan con las personalizaciones.
- Funcionalidades que pueden ser clave no incluidas: En varios headless, aspectos como suscripciones, paywall, anuncios, newsletters o impresión no vienen integrados y requieren de la conexión con terceros, aunque esto último no suele ser para nada un problema.
- Experiencia de edición: A pesar de que los CMS headless son modernos, sus experiencias de edición suelen ser bastante tradicionales y basadas en la clásica botonera de toda la vida.
Ventajas que no lo son tanto: cazando mitos
Ya hemos adelantado que nosotros en hemos apreciado un gran recibimiento en el mercado de la arquitectura headless. A propósito de esto hemos observado que WordPress VIP, que también ofrece esta posibilidad, ha publicado un artículo de Shane Schick en el que desmonta mitos sobre el headless, comentando que algunas supuestas ventajas no lo son tanto como parecen.
Shane habla de que referirse a los CMS tradicionales como monolíticos no ayuda y que, además, según sus datos, la adopción de CMS headless ha caído del 28 % al 16 % en un solo año. Siempre según este artículo de WP VIP:
- No siempre un CMS headless produce frontend más rápidos y personalizados. Esto depende de la ejecución. Una buena optimización de un CMS tradicional puede dar también excelentes resultados.
- Se dice que los CMS headless producen ahorro de costes, pero son ahorros a largo plazo, que se producen principalmente por eliminar la necesidad de volver a cambiar de CMS y migrar. Su propio complejidad técnica va en contra del ahorro. El ahorro vendría por lanzamientos más rápidos y por surfear mejor las tendencias, pero determinar exactamente el ROI de esto es más que complicado.
- Se dice tamibén que un CMS sin interfaz, headless, potencia a los equipos de contenido. Esto es cierto en los mejores y más modernos, pero no en todos.
- Un CMS sin cabeza aporta mayor agilidad al poder enviar contenido y generar tantas salidas o frontend personalizados y optimizados como desees. La realidad es que esto depende de tus recursos de desarrollo, recursos que suelen ser muy reducidos.
- Se comenta también que los CMS sin cabeza ofrecen mayores cotas de seguridad. Aunque se reduce lo que está expuesto, lo cierto es que nadie puede garantizar la seguridad al 100% y, por otro lado, el hecho de utilizar APIs para enviar y recibir peticiones y contenido conlleva sus propios riesgos que no tienen los CMS tradicionales.
- Un CMS headless facilita la expansión omnicanal: Esto es cierto en alguna medida, pero cubrir diferentes necesidades o públicos con diferentes frontend aumenta la complejidad, el trabajo de coordinación entre muchos departamentos y es complicado de mantener. Cuando solo hay un frontend responsive, puede que no sea perfecto en todos los casos, pero seguro que es adecuado en la mayoría y, desde luego, mucho menos complejo de mantener.
- El CMS in cabeza mejora el SEO: Las mejoras en la velocidad y la personalización, así como los datos estructurados, deberían mejorar el SEO, que proporciona una valiosísima audiencia. La realidad es que el equipo del frontend debe ser bueno y generar unas páginas mediante Javascript que Google pueda leer bien y comprender, esto no siempre ocurre así.
Nuestra opinión sobre los CMS headless
En CMS MAG tenemos bastante información y experiencia con respecto a este tipo de CMS por diversos motivos. En primer lugar, hemos observado que el precio inicial suele ser una gran barrera de entrada para los periódicos digitales y empresas que lo desean adoptar. Los ahorros a largo plazo no se suelen observar demasiado; en general reina el aquí y ahora.
También hemos visto que no es fácil de adoptar ni siquiera cuando la empresa del CMS ofrece también un frontend para empezar y, además, tiene en su portafolio un producto especialmente barato, ya se llame Go, Lite, Light o como sea. Ni en estas condiciones un CMS headless suele ser accesible.
Noticias relacionadas: Headless CMS
El precio, por tanto, es un gran hándicap, como también lo es cierta incomprensión del mercado sobre la oferta. Supone que la empresa del CMS se encarga del backend y, el propio periódico, del frontend, que es donde se juega la fiesta de verdad de los códigos, la publicidad, etc. Muchos periódicos y empresas consideran que, de esta forma, la empresa de CMS se quita de encima lo realmente doloroso de llevar.
La complejidad técnica del sistema headles no es tampoco para nada bien vista por el mercado, por un mercado que suele estar en precario y que realmente busca precisamente menor complejidad e incluso sistema no code para sus redactores y product managers.
Para más INRI, los últimos movimientos de Google, que suponen adueñarse del contenido para entrenar a su IA y privar a los medios de gran parte del tráfico colocan al sector aún más en precario, de forma que aún menos pueden considerar soluciones modernas headless. Son pocos los medios que se pueden permitir el lujo de cambiar y calcular el ROI a 3 o 5 años vista, puesto que el resto es realmente sobrevivir.
CMS híbridos: ¿La solución?
En el mundo de la automoción, existen los dos extremos, los motores de combustión y los eléctricos y, en medio, los híbridos no enchufables. Vamos a hacer una analogía con los CMS tradiciones y los headless, quienes tienen también de una forma equidistante a los CMS híbridos, que son los que se pueden comportar como un CMS tradicional o headless según se necesite. WordPress, Drupal, Comitium… Hoy en día son pocos los CMS tradicionales que no hayan integrado una forma de comportarse como headless.
En automoción, los híbridos no enchufables de Toyota son líderes mundiales. Tienen lo mejor de los dos mundos o, según se mire, lo peor. Sea como sea son líderes con esta tecnología. Digo que pueden tener lo peor de los dos mundos (en un Toyota Corolla, por ejemplo) porque cuentan con el gran preso de las baterías y, por otro lado, el ahorro de combustible que producen es de apenas 2 litros por cada 100 kilómetros, que no es mucho, aunque sí se note en las emisiones.
De la misma forma, los sistemas híbridos pueden ser vistos desde el punto de vista de los CMS ideales porque cuentan con todos los casos de uso, o los peores en el sentido de que si uno quiere ser headless, es mejor escoger un buen CMS headless como Glide directamente. Y si no se necesitan las capacidades headless, tener el sistema de API disponible es un peligro de seguridad.
En conclusión, cada caso de uso es único y probablemente tendrá que elegir en función de su causística particular.
¿Headless sí o no? Nuestra conclusión
Lo mejor es lo que acabamos de comentar: revisar bien nuestro caso particular y decidir qué arquitectura nos conviene más en función de las necesidades. Elegir un CMS híbrido solo porque nos ofrece todas las posibilidades no es argumento suficiente.
La elección importa mucho, pero en CMS MAG siempre decimos es que solo la mitad del viaje. La otra mitad es la ejecución. Si la implementación del CMS no es buena ni la migración, por muy bueno que sea el CMS, el resultado va a ser pérdida de clientes y/o audiencia y de eso en España podemos contaros muchos casos.
En general, es una arquitectura muy apta sobre todo para grandes empresas y periódicos con un presupuesto decente y recursos internos, tanto de ingenieros como de profesionales avanzados en la redacción. Una buena implementación puede ser muy beneficiosa para el SEO, robusta y escalable, permitir un buen go to market y efectivamente generar más ingresos y ahorro, pero no siempre ocurre.
Deja una respuesta