La tabla de decisión que usamos de verdad con los clientes, y los tres casos en los que headless cuesta más de lo que aporta.
La versión honesta de esta decisión no tiene nada que ver con preferencias tecnológicas. Se reduce a cuánta gente edita la web, con qué frecuencia, y si alguien del equipo es capaz de mantener un proceso de Node vivo a las tres de la madrugada.
Cuándo headless se gana el sitio
Headless se amortiza cuando el front end tiene que servir a más de una superficie —una web, una aplicación móvil y una API para socios desde un único modelo de contenidos—. También se amortiza cuando el tráfico tiene picos lo bastante pronunciados como para que renderizar en el edge salga más barato que escalar PHP, o cuando el diseño exige interacciones con las que un motor de plantillas no coopera.
Cuándo no
Tres casos en los que hemos disuadido a clientes de hacerlo. Una web corporativa con dos editores y cuarenta páginas: el paso de compilación extra no aporta nada y cuesta un pipeline de despliegue. Un equipo sin ingeniero de JavaScript: ha trasladado la carga de mantenimiento a un sitio al que nadie puede llegar. Y una web cuyo problema principal son imágenes sin optimizar —algo que headless no soluciona, solo reubica.
WordPress clásico con una biblioteca de bloques disciplinada le da el 90 % del rendimiento por una fracción del peso operativo. Empiece por ahí, y deje que sea una restricción real la que le empuje a salir de él.