El editor de bloques que añadió divs infinitos · WordPin 011

El sitio era un portfolio de arquitectura con cinco páginas principales. Proyectos residenciales, obra pública, rehabilitaciones, un par de galerías y una página de contacto. Visualmente, todo estaba bien. Tipografía cuidada, imágenes grandes, secciones limpias. Pero el navegador tardaba más de lo razonable en pintar cada página, y el scroll arrastraba una lentitud fina que no encajaba con un sitio tan ligero de contenido. El hosting respondía rápido. Las imágenes estaban optimizadas. No había plugins pesados ni scripts de terceros fuera de control.

Esto no encajaba. Un sitio así debería ser liviano por definición.

Lo que el editor de bloques dejaba ver y lo que escondía

Lo primero que noté fue la desproporción. Las páginas apenas tenían tres o cuatro párrafos de texto y unas pocas imágenes, pero al inspeccionar el código fuente, el volumen de HTML era enorme. El marcado ocupaba varias veces más de lo que ese contenido justificaba. El editor de bloques había construido todo aquello, y en superficie parecía correcto. Pero algo por debajo estaba inflando la estructura sin que el resultado visual lo explicara.

Abrí DevTools y fui directamente al panel de rendimiento. El tiempo de renderizado era alto para una página con tan poco contenido visible. La cascada mostraba que el navegador estaba dedicando demasiado tiempo a la fase de layout y paint. No era un problema de red, ni de carga de recursos externos. El cuello de botella estaba en el propio documento.

Revisé el árbol del DOM. La página de proyectos residenciales, con apenas cuatro bloques de texto y seis imágenes, tenía más de 1.800 nodos DOM. Para ese volumen de contenido, una cifra razonable habría sido algo entre 300 y 500. Había una cantidad desproporcionada de div envolventes que no aportaban estructura semántica ni funcional.

La sospecha del tema activo

La primera hipótesis fue el tema. El portfolio usaba un tema comercial orientado a arquitectura que incluía sus propios estilos para bloques. Algunos temas inyectan contenedores extra alrededor de cada bloque para aplicar márgenes, paddings o efectos visuales. Si el tema estaba envolviendo cada bloque en capas adicionales de HTML, eso explicaría la inflación del DOM.

Para comprobarlo, activé Twenty Twenty-Four en un entorno de staging y cargué la misma página. El resultado fue revelador, pero no en la dirección esperada: el número de nodos DOM apenas bajó. La estructura hinchada seguía ahí con el tema por defecto. El tema comercial añadía unos pocos contenedores propios, pero no era responsable del grueso del problema. Descartado como causa principal.

El plugin de bloques extendidos

El sitio tenía instalado un plugin que añadía bloques personalizados: separadores con animación, contenedores con bordes graduales y columnas con opciones avanzadas. Era razonable sospechar que esos bloques generaban marcado adicional excesivo. Algunos plugins de este tipo producen HTML bastante más pesado que los bloques nativos para conseguir efectos visuales.

Desactivé el plugin y revisé las páginas que solo usaban bloques del core de WordPress. La diferencia fue mínima. Las páginas construidas exclusivamente con bloques nativos —grupos, columnas, imagen, párrafo— también tenían un DOM inflado. El plugin añadía algo de peso en las páginas donde se usaba, pero las páginas sin él mostraban el mismo patrón. Otro sospechoso descartado.

Ejecuté un análisis con Lighthouse para confirmar lo que ya veía en DevTools. El informe devolvió esta advertencia:

Avoid an excessive DOM size
1,847 elements
Maximum DOM Depth: 18
Maximum Child Elements: 42

Una profundidad de 18 niveles y un máximo de 42 hijos en un solo nodo. Para un portfolio con contenido breve, esos números no tenían sentido. WordPress no siempre falla donde grita. A veces falla donde todavía parece obedecer.

La pista estaba en la estructura que el propio editor de bloques había generado, no en lo que los plugins o el tema añadían por encima.

El peso invisible del editor de bloques

Antes de confirmar nada, quise entender cómo se había construido cada página. Abrí el editor y empecé a revisar bloque por bloque. La persona que había maquetado el sitio tenía experiencia en diseño pero no en estructura HTML. Había utilizado Gutenberg como si fuera una herramienta de diseño gráfico: cada sección estaba envuelta en un bloque de grupo, dentro de otro grupo, dentro de otro grupo. Las columnas contenían grupos que contenían más columnas. Y cada uno de esos contenedores generaba sus propios div en el HTML final.

No era un error de WordPress ni un fallo del editor de bloques. Era una forma de trabajar que producía un resultado visual correcto pero un HTML estructuralmente desproporcionado.

El DOM que nadie vio crecer

La causa era clara una vez que miraba el marcado de salida. El uso excesivo de bloques anidados había multiplicado el DOM sin aportar valor real. Cada decisión de maquetación —centrar un texto, separar dos imágenes, añadir un margen— se había resuelto envolviendo el contenido en un nuevo bloque contenedor en lugar de usar las opciones de espaciado o alineación del propio bloque.

Abrí el código fuente de la página de proyectos y extraje un fragmento representativo. Lo que en pantalla era un título con un párrafo debajo, en HTML se veía así:

<div class="wp-block-group">
  <div class="wp-block-group__inner-container">
    <div class="wp-block-group">
      <div class="wp-block-group__inner-container">
        <div class="wp-block-group">
          <div class="wp-block-group__inner-container">
            <h2>Residencial Alameda</h2>
            <p>Proyecto completado en 2022.</p>
          </div>
        </div>
      </div>
    </div>
  </div>
</div>

Tres niveles de grupo para contener un título y un párrafo. Y ese patrón se repetía en toda la página. Cada sección del portfolio estaba construida de la misma forma: capas de bloques contenedores apilados sin función estructural. El editor de bloques no estaba generando ese HTML por un fallo interno. Lo estaba haciendo porque la maquetación se lo pedía.

El impacto era directo. Un DOM sobredimensionado obliga al navegador a recalcular layout con más frecuencia, ralentiza el painting y puede aumentar el tiempo dedicado al procesamiento y afectar negativamente al rendimiento percibido, incluida la evolución de métricas como Largest Contentful Paint e Interaction to Next Paint. En móvil, donde la capacidad de procesamiento es menor, el efecto era más visible. Lighthouse ya lo marcaba como problema de rendimiento.

Además, los rastreadores tenían que procesar un volumen de HTML innecesario para llegar al contenido real. La proporción entre marcado y contenido útil estaba completamente invertida. El contenido de texto ocupaba menos del 8% del peso total del HTML en la página más pesada. Que una página cargue no significa que su estructura esté bien resuelta.

Los falsos positivos anteriores parecían plausibles porque tanto el tema como el plugin de bloques sí añadían algo de peso. Pero su contribución era marginal comparada con la estructura base. El problema no era lo que se añadía por encima, sino cómo estaba construida la base desde el editor de bloques.

Reducir sin borrar lo que funcionaba

La primera tentación era vaciar cada página y reconstruir la maquetación desde cero con el mínimo de bloques posible. Parecía el camino más limpio. Pero ese portfolio tenía un diseño cuidado, con espaciados, alineaciones y proporciones que el propietario había ajustado durante semanas. Tirarlo todo y empezar de nuevo habría sido rápido a nivel técnico pero costoso en tiempo de rediseño y en confianza del cliente.

El otro extremo tampoco servía: eliminar contenedores a ciegas podía romper la maquetación en puntos concretos donde un grupo sí cumplía una función real, como aplicar un color de fondo a una sección o agrupar columnas con un ancho máximo.

Qué simplificar primero sin romper el diseño

El criterio fue revisar cada bloque contenedor y hacerle una pregunta concreta: ¿este div aporta algo que no se pueda resolver con una propiedad del bloque hijo? Si un grupo solo existía para centrar un párrafo, ese grupo sobraba, porque el propio bloque de párrafo permite alineación. Si un grupo envolvía a otro grupo solo para añadir un margen superior, ese margen podía ir directamente en el bloque de destino usando el espaciado nativo que Gutenberg ofrece desde hace varias versiones.

Trabajé página por página en staging. Empecé por la más pesada —proyectos residenciales— y fui eliminando bloques contenedores redundantes. Cada vez que quitaba uno, comprobaba que el diseño visible no cambiara. En la mayoría de los casos, no cambiaba nada. El div extra no tenía estilos aplicados ni cumplía ninguna función de layout.

En los casos donde un grupo sí era necesario —secciones con fondo de color, agrupaciones de columnas con ancho personalizado—, lo mantuve. No se trataba de prohibir los bloques de grupo, sino de no usarlos como muñecas rusas.

También sustituí estructuras donde se habían usado columnas para colocar un solo elemento. Había bloques de columnas con una sola columna activa, que generaban todo el markup de un layout multicolumna solo para contener una imagen. Eso se resolvía con un bloque de imagen directo y su configuración de ancho.

Después de la limpieza, el resultado en la página de proyectos fue este:

El editor de bloques seguía siendo la herramienta de maquetación. No hizo falta cambiar de sistema, ni instalar un page builder alternativo, ni escribir HTML a mano. Solo hacía falta usarlo con criterio estructural, no solo visual.

Validé el resultado con Lighthouse de nuevo. La advertencia de DOM excesivo desapareció. Las métricas de rendimiento mejoraron sin tocar servidor, caché ni imágenes. El problema nunca había estado fuera del contenido: estaba en cómo el contenido estaba empaquetado.

Repliqué el mismo proceso en las cuatro páginas restantes. En total, el sitio pasó de más de 7.200 nodos DOM combinados a unos 2.100. El peso HTML total bajó casi un 70%. Un error parcial suele ser más peligroso que una caída total, porque deja demasiadas cosas funcionando.