El constructor web que usa tu despacho —Elementor, Divi, Bricks o el editor nativo de WordPress— no es un detalle estético: decide cuántos kilobytes de código carga cada visita y cuántas de tus páginas aprueban los criterios de experiencia que Google usa para clasificar resultados. Un despacho que capta leads por formulario de contacto no puede permitirse que la mitad de sus páginas tarden de más en mostrar el titular. Esto es lo que diferencia a los constructores más usados en WordPress, cuánto cuesta cada licencia y qué conviene mirar antes de cambiar de uno a otro.
Gutenberg, el editor nativo de WordPress, aprueba los Core Web Vitals en el 41,5% de las páginas móviles; Divi en el 34,5%; WPBakery en el 32,7%; y Elementor, el más usado, solo en el 30%, según datos de CrUX de julio de 2026. La diferencia no descarta ningún constructor: la compensa una buena configuración, no el cambio automático de herramienta.
Qué mide el Core Web Vitals en WordPress
El estudio que compara constructores no analiza opiniones de usuarios: cruza datos reales de navegación de Chrome con la detección de qué constructor corre detrás de cada sitio, sobre 2,1 millones de dominios WordPress medidos en julio de 2026. El percentil que usa es el 75, el habitual para decidir si una página aprueba o suspende.
Core Web Vitals son las tres métricas con las que Google mide la experiencia de carga real de una página: LCP (velocidad con la que aparece el contenido principal), INP (rapidez de respuesta a un clic) y CLS (si el diseño se mueve mientras carga). Aprobar las tres sitúa la página entre las de «buena experiencia».
El estudio aisla qué métrica falla más en cada constructor y el patrón se repite: el problema no es la interactividad ni la estabilidad visual, es el LCP. Un despacho que tarda más de 2,5 segundos en mostrar el titular de un artículo pierde visitas antes de que el lector llegue al formulario de contacto, y esa pérdida no la corrige ningún texto, por bien escrito que esté.
Por qué Elementor carga más peso por página
Elementor es, con diferencia, el constructor más instalado: ronda el 31-32% de los sitios WordPress con constructor detectado, muy por delante del segundo (WPBakery, en torno al 8,5%). Esa cuota no es casualidad: su editor visual es el más conocido entre diseñadores freelance. Pero el mismo motivo que lo hizo popular, un widget para cada necesidad, infla el código que manda al navegador.
El contenedor que Elementor añade a cada widget
La propia documentación de Elementor para desarrolladores explica el problema: por defecto, el constructor carga el CSS y el JavaScript de todos sus widgets en cada página, aunque esa página solo use tres. La función de carga de activos mejorada corrige parte de esto cargando solo lo que está en uso, y reduce el CSS sin usar hasta en más de la mitad en la mayoría de páginas. El experimento de salida de DOM optimizada ataca la otra causa: cada widget envuelve su contenido en capas de contenedores anidados que no aportan nada visual, solo estructura para el editor. Ninguna de las dos viene activada de fábrica, así que el despacho que no revisa sus ajustes de rendimiento carga la versión más pesada del constructor.
Gutenberg y los constructores ligeros que ganan velocidad
El editor de bloques que trae WordPress de serie, Gutenberg, no es un añadido de terceros: sale del núcleo, así que no suma una librería de JavaScript aparte ni una hoja de estilos con reglas para widgets que no vas a usar. Eso explica buena parte de su 41,5% de aprobados. Bricks, aunque no entra en el estudio citado, sigue la misma lógica desde fuera del núcleo: genera HTML semántico sin contenedores de sobra y sin dependencias heredadas de jQuery, lo que mantiene el documento ligero sea cual sea el tema que lo vista.
Qué pierde un despacho al cambiar a Gutenberg
La velocidad no sale gratis. Gutenberg no trae una librería de plantillas prediseñadas para una página de área de práctica: cada sección se monta bloque a bloque, lo que exige más tiempo de maquetación o un tema que aporte sus propios patrones. Tampoco iguala el control visual pixel a pixel que ofrece Elementor sobre márgenes o animaciones de entrada. Para un despacho con una sola persona llevando la web, ese control manual pesa más que el medio segundo de carga que se gana. Para uno con contenido editorial constante, la ganancia de velocidad compensa, porque el diseño ya está resuelto en la plantilla y lo que cambia cada vez es solo el texto.
Cuánto cuesta cada constructor web al año
El precio de la licencia no es el único coste, pero marca el suelo. Cada fabricante publica su tabla en su propia moneda —Elementor en euros, Divi y Bricks en dólares— y los planes de entrada parten de una idea distinta: por sitio activado (Elementor, Bricks) o por uso ilimitado desde el primer plan (Divi). Esto es lo que cobra cada uno en octubre de 2026, según sus propias páginas de precios, incluida la de Bricks:
| Constructor | Plan de entrada | Sitios incluidos | Qué añade el plan superior |
|---|---|---|---|
| Elementor Pro | 59 €/año (Essential) | 1 | Advanced, 99 €/año, amplía a 3 sitios |
| Divi | 89 $/año (~82 €) | Ilimitados | Divi Pro, 277 $/año, suma IA, Cloud y 4 puestos de equipo |
| Bricks | 79 $/año (Starter) | 1 | Agency, 249 $/año, cubre sitios ilimitados |
| Gutenberg | Gratis, incluido en WordPress | Ilimitados | No hay plan superior: lo avanzado se añade con plugins sueltos |
La lectura que importa no es cuál es más barato suelto, es qué pasa si el despacho crece. Divi y Gutenberg no penalizan por número de sitios desde el primer euro; Elementor y Bricks sí, y un despacho con la web principal más un microsite de campaña paga por cada una hasta saltar al plan superior.
Cambiar de constructor web sin perder posiciones
Migrar de Elementor a Bricks o a Gutenberg no es instalar un plugin y desactivar el anterior: cada constructor guarda el contenido en su propio formato (la meta _elementor_data en un caso, bloques HTML comentados en otro) y el siguiente no lee el formato del que se va. El texto hay que volver a maquetarlo, página a página: en un blog con cien artículos son semanas, no una tarde. Antes de cambiar, conviene revisar si el problema es realmente el constructor o si el despacho sigue usando WordPress sin plan de mantenimiento, que acumula plugins y es la causa real de la lentitud en más casos de los que parece.
- Comprobar cuántas páginas usan plantillas guardadas del constructor actual: son las que más cuesta reconstruir.
- Exportar antes de migrar: Elementor y Bricks permiten exportar plantillas en JSON, una copia que evita partir de cero si la migración falla a mitad.
- Migrar primero las páginas con menos tráfico, no la home: un error de maquetación ahí no hunde el posicionamiento general.
La decisión de partida —un constructor visual o una plantilla a medida— condiciona esto: lo a medida no arrastra ninguno de estos problemas, pero cuesta más de entrada y cualquier cambio pasa por un desarrollador, no por el despacho.
Mantenimiento que el precio del constructor no cubre
La licencia anual no incluye que alguien revise cada actualización antes de aplicarla. Elementor publica actualizaciones con frecuencia mensual, y una versión mayor puede desactivar temporalmente un widget que el tema del despacho usa en la home: el constructor avisa de la actualización disponible, no de si rompe algo. Divi actualiza con su propio gestor (Divi Dash) sobre las mismas condiciones. Bricks, al ser más joven, cambia su forma interna de guardar datos con más frecuencia que los otros dos, lo que exige revisar el registro de cambios antes de cada salto de versión, no solo pulsar «actualizar».
El peso de cada constructor también sube la exigencia sobre el LCP del hosting: un plan compartido que ya iba justo con el tema solo no sostiene bien un constructor que añade cientos de kilobytes adicionales por carga. El coste real de un constructor pesado no aparece en la factura de la licencia, aparece en la factura del hosting el día que hay que subir de plan para que la web no se note lenta.
Preguntas frecuentes sobre constructores web
¿Elementor es mejor que Gutenberg para la web de un despacho?
No en velocidad: Gutenberg aprueba más Core Web Vitals. Pero Elementor da más control visual sin tocar código y más plantillas. Para un despacho sin diseñador, esa facilidad compensa el medio segundo de carga que se pierde, si se activa la carga de activos optimizada.
¿Cuánto cuesta migrar de Elementor a Bricks o Gutenberg?
No hay una cifra fija: depende de cuántas páginas tenga la web. Un desarrollador tarifa por página reconstruida, no por el proyecto entero, porque cada plantilla hay que maquetarla de nuevo en el formato del constructor nuevo. Una web de diez páginas se mueve en días; un blog de cien artículos, en semanas.
¿Afecta el constructor web al SEO del despacho?
De forma indirecta sí, a través de la velocidad de carga: el LCP es un factor de clasificación reconocido por Google. El constructor no cambia el contenido, el título ni la estructura de encabezados, que dependen de quien escribe, no de la herramienta que lo maqueta.
¿Se puede cambiar de constructor sin perder el diseño actual?
No de forma automática: cada constructor guarda la maqueta en un formato propio que el siguiente no entiende. Lo que se conserva es el contenido de texto e imágenes, que hay que volver a colocar manualmente dentro de la plantilla nueva, apartado por apartado.
Fuente: PageSpeedMatters, estudio de Core Web Vitals por constructor de WordPress