Autopsia nº2: el page builder pesaba más que la web entera

Volvemos al quirófano. Si en la primera autopsia el villano fue el cementerio de plugins, hoy el sospechoso es uno solo, pero gordo: el page builder. El mismo que le vendieron al cliente como «para que puedas editar tú». Spoiler: no editaba nada, y le costaba la mitad de la velocidad de su web.

El paciente: una web de una clínica, ocho páginas, sin blog, hecha con uno de los constructores visuales más populares de WordPress. Bonita por fuera. Por dentro, otra cosa.

Ficha técnica · antes / después

• CSS + JS del builder por página · WordPress (antes): ~900 KB · Next.js (después): 0 KB
• Nodos del DOM en la home · WordPress (antes): 3.100 · Next.js (después): 640
• Tiempo hasta interactivo (móvil) · WordPress (antes): 5,1 s · Next.js (después): 0,7 s
• Lighthouse (móvil) · WordPress (antes): 36 · Next.js (después): 98
• ¿Editaba el cliente? · WordPress (antes): No, desde hacía 2 años · Next.js (después): —

Un builder no es «un plugin»

Aquí está la clave que casi nadie explica. Un plugin normal añade una función. Un page builder añade una capa entera entre tú y tu web: su propio sistema de columnas, su propio CSS, su propio JavaScript, sus propios «widgets». Y lo carga en todas las páginas, uses lo que uses. Para pintar tres columnas con un texto y un botón, esta web descargaba 900 KB de código del builder. Casi un megabyte para algo que en HTML son cuatro líneas.

No es culpa del cliente. Le vendieron autonomía —«edítalo tú mismo»— y en la práctica no tocó la web en dos años, porque editar en un builder da más miedo que arreglo. Pagó el peso del builder para siempre a cambio de una promesa que no usó. Es el patrón más común que vemos.

Cómo lo detectamos

No hace falta magia: el builder deja huellas por todas partes. En el HTML, clases con su prefijo por todos los nodos; en la red, un puñado de ficheros CSS y JS con su nombre cargándose en cada página; en el DOM, una anidación de div dentro de div dentro de div para montar una rejilla que el navegador hace nativa con tres líneas. Cuando ves 3.100 nodos en una home de ocho bloques, el diagnóstico está claro antes de abrir nada.

La operación

Reconstruimos las ocho páginas en Next.js con el mismo diseño —píxel a píxel donde importaba— pero con HTML limpio y CSS propio, sin builder. El resultado: la web pesa una fracción, el DOM cabe en una pantalla y el móvil deja de sudar. Y el diseño no solo se mantiene: al quitar el ruido, carga antes y se ve más nítido.

De 36 a 98 en Lighthouse. Pero, como siempre, lo interesante no es el número: es que el 62% de la lentitud vivía en una herramienta que el cliente ni usaba.

¿Y si quiere seguir editando?

Buena pregunta, y honesta: si de verdad necesitas editar a menudo, no te dejamos tirado. Conectamos un editor de contenido moderno (headless) para las partes que cambian, sin arrastrar el peso del builder a la web pública. Pero para una web de ocho páginas que se toca dos veces al año, lo honesto es decirlo: no necesitas un builder, necesitas una web rápida.

¿Tu web va lenta y sospechas del builder? En la auditoría gratuita te decimos cuánto pesa el tuyo y qué ganarías quitándolo. Y si quieres el panorama completo, empieza por la guía de migración.