Lo que cuesta un constructor visual
Empecemos por reconocer lo evidente: Elementor resolvió un problema real. Antes de los constructores visuales, cambiar el orden de dos secciones significaba tocar PHP. Millones de webs existen porque alguien pudo montarlas arrastrando bloques.
Yo trabajo con Divi, así que esto no va de convencerte de que los constructores son malos. Va de que tienen una factura, casi nadie la mira antes de firmar, y si no haces nada por reducirla la paga tu web todos los días.
Lo que cuesta de verdad
Un constructor visual añade entre 300 KB y 900 KB de CSS y JavaScript a cada página, cargues los componentes que cargues. Es peso fijo: lo paga igual una landing con tres bloques que una página de producto compleja.
Ese peso se traduce en LCP más alto, INP más alto y una penalización que no compensa ninguna optimización posterior. Puedes poner encima el mejor plugin de caché del mercado; sigues sirviendo 600 KB que no necesitas.
El problema del marcado
Los constructores generan <div> anidados. Muchos. Un hero típico sale con seis o siete niveles de contenedores donde bastaban dos.
Eso importa por dos motivos que no son estéticos:
- Accesibilidad. Un lector de pantalla necesita
<section>,<nav>,<h1>. Una torre de divs no comunica estructura, y desde 2025 la accesibilidad es obligación legal en la UE. - SEO. Google entiende jerarquía. Si tus titulares son divs con estilo de titular, estás renunciando a una señal gratis.
La dependencia
Este es el coste que nadie calcula al principio. Una web hecha con un constructor no se puede sacar de ese constructor. El contenido vive en atributos propietarios dentro de la base de datos. Si el plugin sube de precio, cambia de licencia o deja de mantenerse, no tienes una salida sencilla.
Hemos migrado webs así. No es una tarde de trabajo: es rehacerlas.
Qué hago para pagarla barata
Uso Divi, y encima escribo un tema hijo con la estructura, los estilos y el rendimiento. Suena a más trabajo y lo es. A cambio:
- Se cargan sólo los módulos que la página usa, no la librería entera.
- El CSS crítico va en línea y el resto se difiere, que es lo que salva el LCP.
- Las imágenes salen en AVIF con dimensiones declaradas: ahí se va la mitad del peso.
- Los titulares son titulares de verdad y no divs con estilo, así que la accesibilidad y la jerarquía dejan de ser una pelea.
- Lo que personalizo vive en el tema hijo, así que una actualización de Divi no se lleva por delante el diseño.
Y se puede comprobar, que es lo único que vale. bacorispain.com está hecha así, con Divi, y puntúa 100 en escritorio y 95 en móvil en PageSpeed Insights. Ábrelo tú: el informe es público y tarda treinta segundos.
O sea que el problema nunca fue el constructor. Es entregarlo tal y como viene.
Cuándo un constructor NO es la respuesta
Sigue habiendo un punto donde no llega, y no es una cuestión de velocidad:
| Señal | Por qué el constructor se queda corto |
|---|---|
| Lógica propia: cálculos, estados, permisos | No cabe en un módulo, y forzarlo es peor que programarlo |
| Integración con tu ERP, tu CRM o una API | Vive en el servidor, no en la página |
| Un panel interno que use tu equipo | Lo que importa es la velocidad de uso, no la de portada |
| Volumen alto de datos | La base de datos de WordPress deja de ser la herramienta |
Cuando aparece cualquiera de esas cuatro, lo honesto es irse a código y dejar WordPress fuera: eso es el desarrollo a medida, con Astro, Next.js o React.
Lo que no es razonable es pagar precio de desarrollo a medida y recibir una plantilla con el constructor tal cual viene de fábrica.
Si quieres saber qué mide exactamente Google —y qué no— antes de decidir si tu web tiene un problema real, está en Core Web Vitals: qué mide Google y qué no. Y así es como monto WordPress sobre Divi con tema hijo propio.