Tres constructores cubren la mayor parte del mercado WordPress en 2026. Gutenberg viene en cada instalación. Elementor esta presente en aproximadamente 6 millones de sitios activos. Divi ronda los 3 millones. El dato interesante es cuantos sitios corren realmente un tema de bloques con full site editing - esa cifra sigue en un porcentaje pequeno, lo que significa que la mayoria del parque WordPress sigue con temas clasicos y Gutenberg solo en el cuerpo del post, Elementor en plantillas, o Divi de extremo a extremo.
La eleccion entre ellos no es un concurso de belleza. Es un compromiso entre overhead de assets, lock-in de proveedor, flujo de desarrollo, y como un cliente no tecnico edita el sitio tras la entrega. Esta guia recorre cada eje con el compromiso real al que se enfrenta.
Respuesta corta: Gutenberg para sitios de contenido donde un equipo editorial sera formado y un desarrollador mantiene theme.json. Elementor para flujos de agencia centrados en landing pages donde el editor de marketing necesita publicar páginas sin tocar codigo. Divi para freelancers solos que entregan sitios acabados a clientes no tecnicos con retainer a largo plazo.
1. Que produce realmente cada constructor
La diferencia arquitectonica no es un eslogan: es lo que acaba en la base de datos y en el cable.
Gutenberg
El markup de bloques se almacena como HTML con delimitadores de comentario (<!-- wp:paragraph -->). Al renderizar, los bloques emiten HTML semantico; los estilos viven en theme.json y en hojas de estilo de bloques. Si desactiva Gutenberg (imposible en la práctica al ser core), el HTML sigue siendo válido. Si migra a otra plataforma, el cuerpo del contenido es portable.
Elementor
El contenido se guarda en _elementor_data como postmeta - un arbol JSON de definiciones de widget. La columna post_content esta normalmente vacia en páginas Elementor. Si desactiva Elementor, el frontend cae a lo que haya en post_content, que suele ser nada.
Divi
El layout vive en shortcodes dentro de post_content: [et_pb_section][et_pb_row][et_pb_column][et_pb_text].... Si desactiva Divi, el frontend muestra los corchetes de shortcode crudos. El patron de lock-in es más antiguo que el de Elementor, pero visualmente identico para el lector.
La conclusion: Gutenberg produce HTML portable, Elementor y Divi producen estructuras propietarias que atan su contenido al runtime del plugin.
2. Rendimiento: numeros reales, no vibras de Lighthouse
| Eje | Gutenberg + tema de bloques | Elementor (Pro) | Divi |
|---|---|---|---|
| CSS anadido en una página tipica | 0-30 KB | 150-300 KB | 120-280 KB |
| JS anadido | 0-20 KB | 100-200 KB (frontend.js, swiper, dialog) | 80-180 KB |
| Nodos DOM en una página de marketing | base | 3-5x base (wrapper-por-widget) | 2-4x base |
| INP bajo carga editorial intensa | bajo | sensible al numero de widgets | sensible al numero de modulos |
Dos observaciones de practitioner detras de esos rangos:
Una tienda WooCommerce con 30+ plantillas Elementor en producto, archivo, single y checkout muestra rutinariamente TTFB superior a 1.5s en hosting compartido tipico (caso real visto en cliente de retail .es), porque Elementor parsea el JSON de widgets en cada peticion antes de renderizar. La cache ayuda, el experimento de carga de assets de Elementor ayuda, pero el overhead estructural no desaparece.
Un sitio Gutenberg con 100+ patterns de bloque y sin disciplina de registro central se convierte en su propio problema de mantenimiento: los editores copian un pattern de hero, lo personalizan inline, y acaba con 40 variantes de hero en producción sin fuente unica. Las ganancias de rendimiento de Gutenberg no sobreviven a la deriva editorial sin alguien responsable de theme.json y la libreria de patterns.
Divi se sitúa entre los dos: más ligero que el Elementor heredado tras la reescritura de la version 5, más pesado que Gutenberg, con el mismo impuesto de lock-in por shortcode.
3. Experiencia de desarrollador y pipeline de build
Aqui la comparativa deja de ser sobre usuarios finales.
Gutenberg asume un pipeline React + ESNext. Para enviar un bloque custom necesita @wordpress/scripts, un archivo block.json de metadatos y registerBlockType() en el lado JS. La curva de aprendizaje es real - los estudios WordPress que crecieron con temas PHP clasicos (muy comun en agencias espanolas pequenas) la sienten al primer contacto. La recompensa es que los bloques custom se comportan como ciudadanos WordPress de primera clase: soporte REST API, plantillas de bloque, patterns y overrides de theme.json.
Elementor permite que un no-desarrollador publique páginas sin codigo. La API de widgets custom existe, pero la mayoria de agencias nunca la tocan: ensamblan a partir de la libreria interna y de packs de terceros. Esta es la razón real por la que Elementor gana las entregas agencia-cliente: el cliente puede editar el sitio sin romperlo, y la agencia no recibe llamadas a las 2 de la madrugada por un syntax error. Estudios espanoles como Cero Estudio y otros de Madrid y Barcelona han construido buena parte de su pipeline sobre este modelo.
Divi se sitúa entre ambos. El Divi Builder es amigable para no-tecnicos como Elementor; la API de modulos via child theme se acerca más al modelo developer de Gutenberg que la de widgets de Elementor. Los freelancers solos que disenan pero no escriben React tienden a aterrizar aqui - patron habitual entre freelancers de ecommerce minorista en .es que entregan tiendas a clientes que solo quieren cambiar precios y fotos.
Si necesita saber cual aprender: un desarrollador WordPress de 2026 envia bloques Gutenberg y plantillas FSE, conoce Elementor lo suficiente para migrar sitios fuera de el, y sabe que Divi existe para trabajo de retainer.
4. Lock-in y coste de migración
Dos modos de fallo que aparecen repetidamente:
Un sitio brochure de 200 páginas construido en Elementor con 30+ plantillas Elementor y sin herencia de plantilla. Anadir un solo campo a la plantilla “caso de estudio” significa editar 200 páginas a mano porque las plantillas Elementor son copy-on-create, no por referencia. La agencia que lo construyó facturó mantenimiento trimestral durante anos exactamente sobre esta friccion.
Una inmobiliaria en Divi durante ocho anos. Cambiar de tema implica reconstruir manualmente cada página porque los shortcodes Divi estan ligados a modulos Divi, y no existe migrador que preserve la fidelidad del layout. El sitio esta funcionalmente atrapado en Divi hasta que alguien presupueste una reconstrucción.
La portabilidad de Gutenberg es la respuesta práctica. El markup de bloque sobrevive a cambios de tema, a la rotación de plugins, e incluso a flujos export-to-static.
5. AEPD, RGPD y widgets de terceros
Un punto especifico para el mercado espanol que rara vez se menciona en comparativas en ingles: la AEPD ha endurecido la fiscalización sobre cookies y tracking de terceros. Muchos widgets de Elementor (formularios con reCAPTCHA, video embeds, mapas, sliders con servicios externos) cargan recursos de terceros antes del consentimiento si no se configuran cuidadosamente. La sancion media en casos resueltos por la AEPD se mueve en rangos de cuatro a cinco cifras, y el “lo configura Elementor por mi” no es defensa.
Gutenberg, al ser HTML plano renderizado en servidor, deja la decisión sobre cargar terceros en el desarrollador y en el plugin de consentimiento - el bloqueo previo al consent es trivial. En Elementor y Divi, hay que auditar widget por widget cual carga terceros y cual no, y reconfigurar la integración con el banner de consentimiento.
Para sitios .es regulados (banca, salud, ecommerce con datos sensibles), este punto solo ya inclina la decisión hacia Gutenberg en muchas auditorias.
6. Flujo editorial y herencia de plantillas
Donde Gutenberg y Elementor divergen más es en edicion editorial en bulk.
Gutenberg tiene patterns sincronizados (antes “bloques reutilizables”): edita una vez, propaga en todas partes. Esta es la feature decisiva para equipos editoriales de revistas, knowledge bases o documentación. Combinado con plantillas de bloque y template parts en FSE, hay herencia real: cambia el template part del footer del articulo y todos los articulos lo reflejan.
Elementor tiene widgets globales en Pro y theme parts en el Theme Builder, pero las instancias de plantilla suelen ser copy-on-create. Equipos editoriales que no aprendieron el patron de widget global temprano acaban con N copias del mismo hero, deriva entre ellas y una factura de mantenimiento.
Divi tiene modulos globales y Theme Builder, similar a Elementor.
Para un sitio de contenido con 500 articulos, los patterns sincronizados de Gutenberg con plantillas de bloque son la unica de las tres opciones que escala sin presupuesto de mantenimiento dedicado.
7. Coste: la licencia es el numero pequeno
La pregunta sobre la licencia importa menos que la pregunta sobre renovación y migración.
| Eje de coste | Gutenberg | Elementor Pro | Divi |
|---|---|---|---|
| Licencia | gratis | precio individual (suscripción) | precio individual (licencia tipo lifetime historica) |
| Tiempo dev para enviar un bloque/widget custom | mayor (pipeline React) | menor (editor visual) | menor (builder visual) |
| Renovación a nivel cartera | ninguna | crece con el numero de sitios | plana tras compra lifetime |
| Coste de migración al irse | bajo (HTML portable) | alto (requiere reconstrucción) | alto (reconstrucción de shortcodes) |
| Mantenimiento editorial a escala | bajo (patterns sincronizados) | alto sin disciplina | alto sin disciplina |
La factura que hunde proyectos no es la licencia, es el coste de migración dentro de tres anos y la deriva editorial dentro de dos. El precio gratis de Gutenberg es moderadamente interesante; su bajo coste de migración es el ahorro real.
El precio de Elementor y Divi es individual - solicite presupuesto a nivel de cartera, no por sitio aislado.
8. Comunidad y soporte en el mercado espanol
Un detalle de mercado: la comunidad WordPress espanola en los meetups de WordPress Madrid y WordPress Barcelona ha pivotado claramente hacia Gutenberg y FSE en los ultimos dos anos, con charlas regulares sobre block themes, theme.json y custom blocks. La WordCamp Espana mantiene track tecnico centrado en bloques. La traducción al espanol de Gutenberg al core esta al dia; las traducciones de Elementor y Divi tienen huecos historicos en strings de widgets nuevos, especialmente en versiones recientes de Pro.
Si el equipo del cliente final consume documentación en espanol, Gutenberg suele presentar menos friccion linguistica que los plugins de terceros.
9. Eligiendo uno
Una regla de decisión a nivel practitioner:
Elija Gutenberg si:
- El sitio es de contenido pesado (blog, documentación, revista, knowledge base)
- Habrá un equipo editorial formado, no asumido competente desde el dia uno
- Puede presupuestar tiempo de desarrollo para theme.json y una libreria de patterns gestionada
- Espera que el sitio sobreviva a cualquier proveedor de plugin individual
- El cumplimiento RGPD/AEPD requiere control fino sobre que se carga antes del consentimiento
Elija Elementor si:
- El entregable son landing pages y la editora es la responsable de marketing
- El pixel-pushing importa más que la limpieza del HTML
- La entrega agencia-a-cliente es el modo de fallo que más necesita evitar
- Ha procesado el coste de renovación en toda la cartera y lo acepta
Elija Divi si:
- Es un freelancer solo o un estudio de dos personas con cartera de retainer larga
- La licencia tipo lifetime hace que las cuentas cuadren en muchos sitios pequenos
- Los clientes son no-tecnicos y editan poco
La pregunta equivocada es “que constructor es el mejor en 2026”. La pregunta correcta es “que compromiso puede sostener mi equipo durante los próximos cuatro anos”.
10. Preguntas frecuentes
Es Gutenberg un constructor de páginas? En 2026 si - con FSE, plantillas de bloque, template parts, theme.json y patterns sincronizados, cubre la superficie funcional de un constructor de páginas para la mayoria de casos.
Puedo correr Elementor y Gutenberg juntos? Tecnicamente si. Operativamente, paga ambos impuestos de rendimiento y confunde a los editores. Elija uno por sitio.
Que suite de bloques Gutenberg debo anadir? GenerateBlocks para sitios donde rendimiento es prioridad, Kadence para marketing más rico, Stackable para landing pages. Ninguno obligatorio - bloques nativos y theme.json cubren la mayoria.
Desaparecera Elementor? Improbable - 6 millones de sitios son un foso. Lo que cambia es su estatus de opcion por defecto; las construcciones nuevas empiezan cada vez más en Gutenberg.
Funciona WooCommerce con Gutenberg? Si. Los bloques Cart y Checkout son la ruta recomendada en 2026. Las tiendas heredadas con shortcodes siguen funcionando pero ya no reciben la misma inversion.
Por que se quejan los desarrolladores de Elementor? Bloat de DOM, lock-in en postmeta y el impuesto de migración. La queja no es tanto sobre la edicion visual como sobre lo que el editor visual deja detras.
Esta FSE listo para producción? Para construcciones nuevas si. Para migrar grandes sitios existentes con tema clasico, parcialmente - configuraciones hibridas (tema de bloques para nuevas plantillas, clasico para legacy) funcionan en práctica.
Existe migrador automatico de Elementor a Gutenberg? No. Toda migración creible es manual o semimanual. Las herramientas que prometen conversión automatica producen HTML que igual hay que limpiar a mano.
Ultima actualización: 2026-04-01
Autor: wppoland.com
Si necesita ayuda para elegir el constructor adecuado o migrar de Elementor o Divi a Gutenberg, contacte con WPPoland. Ofrecemos servicios de desarrollo WordPress, optimización de velocidad y rediseño web.
Recursos relacionados
- Desarrollo WordPress profesional - Implementación con Gutenberg
- Optimización de velocidad - Core Web Vitals
- Rediseño WordPress - Migración desde page builders
- Desarrollo WooCommerce - Tiendas optimizadas
