El debate ACF vs bloques de Gutenberg lleva años dividiendo a la comunidad WordPress. Algunos argumentan que Gutenberg es el futuro y ACF es legado. Otros se mantienen con ACF y consideran que Gutenberg es inmaduro para trabajo en producción serio. La verdad, como siempre, está en algún punto intermedio — y depende del contexto del proyecto.
En este artículo comparto mi posición técnica, basada en proyectos reales de los últimos años. En la gran mayoría de mis proyectos, sigo usando ACF. Pero no por nostalgia — por razones concretas que explicaré a continuación.
El debate ACF vs Gutenberg, sin ideología
Permíteme enmarcar este debate en términos prácticos. ACF (Advanced Custom Fields) es un plugin que permite crear campos personalizados para CPTs, páginas y taxonomías, con una UX cuidadosamente diseñada para los editores. Gutenberg es el editor nativo de WordPress, que utiliza un sistema basado en bloques e incluye FSE (Full Site Editing).
No son exactamente lo mismo. ACF es principalmente para estructurar contenido (campos repetibles, relaciones, galerías, datos específicos). Gutenberg es principalmente para componer la maquetación visual. Se solapan en la gestión de contenido dinámico en páginas con layouts flexibles.
Cuándo gana ACF (y por qué sigo usándolo en la mayoría de proyectos)
1. Contenido estructurado y repetible
Para CPTs con datos bien definidos (proyectos, productos, miembros del equipo, eventos), ACF es incomparablemente superior. Los campos son explícitos, validados, y la UX para los editores es clara. En Gutenberg, esto tendría que implementarse como bloques personalizados, lo que supone trabajo innecesario para datos estructurados.
2. Relaciones entre contenidos
Los campos Relationship y Post Object en ACF permiten construir fácilmente relaciones complejas entre tipos de contenido (un proyecto pertenece a un cliente, tiene varios miembros del equipo, está relacionado con otros proyectos). En Gutenberg, esta lógica es mucho más difícil de modelar de forma limpia.
3. UX para clientes no técnicos
Este es el argumento decisivo. Un cliente que abre el backend para cambiar el precio de un servicio, el número de empleados o la fecha de un evento, quiere un único campo claro. No quiere navegar entre bloques — quiere hacer clic en un campo «Precio» y escribir el valor.
Gutenberg, por mucho que haya mejorado, sigue ofreciendo una experiencia confusa para usuarios no técnicos con contenido estructurado. ACF es, en comparación, brutalmente más sencillo.
4. Rendimiento y control
Con ACF, el desarrollador escribe el HTML que quiere en la plantilla, con control total sobre la estructura y el rendimiento. Con Gutenberg, el HTML lo genera el sistema de bloques, y el control fino es más difícil de conseguir.
5. Madurez y ecosistema
ACF existe desde hace más de una década, tiene un ecosistema maduro, documentación sólida y un modelo de negocio sostenible (ahora propiedad de WP Engine). Los bloques de Gutenberg siguen teniendo cambios que rompen la compatibilidad entre versiones, documentación dispersa y el ecosistema de bloques de terceros es inconsistente.
Cuándo tiene sentido Gutenberg
No soy dogmático. Hay escenarios en los que Gutenberg es la elección correcta.
Páginas de contenido editorial con layouts variables
Artículos de blog de formato largo, landing pages experimentales, páginas de campaña, donde el editor necesita componer visualmente una secuencia de secciones diferentes en cada pieza. Para esto, el editor de Gutenberg con un conjunto bien seleccionado de bloques personalizados es excelente.
Proyectos pequeños con un cliente autónomo
Si el cliente gestionará el sitio solo, tiene cierta alfabetización digital y necesita flexibilidad para crear nuevas páginas sin un desarrollador, Gutenberg con un tema preparado para FSE puede tener sentido.
Bloques reutilizables en múltiples contextos
Si la misma unidad de contenido (testimonio, CTA, tarjeta de característica) necesita aparecer en decenas de lugares diferentes del sitio, un bloque de Gutenberg reutilizable es más elegante que repetir campos ACF en múltiples páginas.
El escenario híbrido que uso en la mayoría de proyectos
En la práctica, mis proyectos raramente son 100% ACF o 100% Gutenberg. La arquitectura que utilizo es:
- CPTs con datos estructurados: ACF (proyectos, productos, equipo, eventos)
- Páginas institucionales fijas (inicio, sobre nosotros, contacto): ACF Flexible Content o una plantilla rígida con ACF
- Entradas del blog: Gutenberg, con un conjunto limitado de bloques personalizados (pullquote, cita, imagen con pie de foto, CTA)
- Landing pages: Gutenberg con bloques personalizados específicos
Este enfoque ofrece al cliente la UX adecuada para cada tipo de contenido: campos claros para datos estructurados, flexibilidad visual para contenido editorial.
Lo que Automattic no te cuenta
La narrativa oficial es que Gutenberg y FSE son el futuro inevitable de WordPress. Eso es parcialmente cierto. Pero hay realidades que no forman parte de esa narrativa:
- Gutenberg tiene cambios que rompen la compatibilidad con frecuencia, lo que aumenta el coste de mantenimiento a largo plazo
- FSE (Full Site Editing) sigue teniendo limitaciones serias para sitios corporativos con requisitos complejos
- Muchos desarrolladores con experiencia siguen usando ACF porque la productividad real es mayor
- La curva de aprendizaje para crear bloques de Gutenberg personalizados es significativamente más pronunciada que crear grupos de campos ACF
- La compatibilidad con temas antiguos y las migraciones son más complejas con Gutenberg
¿Qué hay de ACF Blocks?
Una solución intermedia que uso cada vez más es ACF Blocks. Permite crear bloques de Gutenberg utilizando la sintaxis y la UX de ACF. Se obtiene la flexibilidad de composición de Gutenberg con la simplicidad de implementación de ACF.
No es perfecta — el rendimiento puede ser ligeramente inferior al de los bloques React nativos, y existen limitaciones en algunos casos de uso avanzados. Pero para la mayoría de escenarios en los que necesito un bloque personalizado, es la opción más productiva.
Conclusión: no es Gutenberg vs ACF, es el contexto del proyecto
La pregunta correcta no es «cuál es mejor». Es «qué necesita este proyecto concreto y quién va a gestionar el contenido». La respuesta varía de un proyecto a otro.
Si estás pensando en reconstruir tu sitio y no tienes claro qué enfoque elegir, hablemos. Puedo ayudarte a mapear los requisitos y proponer la arquitectura más adecuada para tu caso.
