Divi vs Gutenberg: comparativa de rendimiento

Divi 5 ya está disponible. ¿Tienes ganas de probarlo? Veamos si realmente hay motivos para hacerlo, porque las versiones anteriores de Divi eran conocidas por ser lentas y pesadas, incluso cuando todos los otros blogs te decían lo bueno que es y cuántas cosas puedes hacer (y así se llevan su comisión…). Pero bueno, ahora afirman que ahora es rápido y ligero (fast and lean).

En este artículo comparo una página hecha con Divi con una página hecha con el editor de bloques nativo de WordPress, Gutenberg. Como Divi también funciona como tema, utilizaré el tema por defecto de WordPress (Twenty Twenty-Five) al probar Gutenberg. Estas son las versiones utilizadas en la prueba:

Divi: v5.0.1
WordPress: v6.9.1
Twenty Twenty-Five: v1.4

Condiciones de las pruebas

He utilizado un servidor Hetzner CX22 con 2 vCPU y 4 GB de RAM; nada impresionante, pero suficiente para las pruebas. Todos los tests se han hecho en las mismas condiciones:

El tema Twenty Twenty-Five activo al hacer las pruebas con la página creada con Gutenberg (Divi en sí mismo es un tema).
Divi 5 instalado desde cero, no actualizado desde Divi 4.
Tanto Divi como Gutenberg ejecutándose con la configuración por defecto (Gutenberg técnicamente no tiene opciones de configuración, pero no se ha modificado su comportamiento por defecto).
No se ha instalado ningún otro plugin, excepto Code Profiler Pro para medir el rendimiento.
Sin sistemas de caché.
Se ha creado una página de ejemplo con cada maquetador, utilizando únicamente bloques nativos de WordPress en Gutenberg y módulos nativos de Divi en Divi, con el siguiente contenido:
- Una sección de ancho completo con una imagen de fondo, texto y un botón.
- Una galería simple de 5 imágenes. Configuramos Gutenberg para cargar el tamaño de miniatura Medium. Divi no permite cambiar el tamaño de miniatura. En su lugar, crea muchos tamaños adicionales y decide dinámicamente cuál cargar.
- Un par de botones.
- Dos columnas con dos cadenas de texto.
- Un bucle con la lista de entradas, que contiene solo cuatro publicaciones.

Así es como se ve la página con Twenty Twenty-Five y Gutenberg:

Y así es como se ve la página con Divi:

Parámetros de rendimiento

El rendimiento de cada plugin se ha medido utilizando los siguientes parámetros:

Tiempo de ejecución de PHP (ms) de las páginas creadas en la vista pública. Como Gutenberg está integrado en WordPress, no tenemos una forma sencilla de distinguir qué parte del tiempo total de ejecución pertenece únicamente a Gutenberg. Por lo tanto, medimos el tiempo total de ejecución de todos los plugins y del tema activo.
Tiempo de ejecución de PHP (ms) de la pantalla del escritorio de WordPress (con la misma limitación mencionada anteriormente).
Time To First Byte (TTFB) y evento Load (ms) del editor y de las páginas creadas en la vista pública. Medimos Load en lugar de DOMContentLoaded porque los editores son aplicaciones muy dependientes de JavaScript cuya interfaz y funcionalidad solo se inicializan después de que sus scripts y otros recursos se hayan cargado y ejecutado completamente, que es cuando se dispara el evento Load. TTFB y Load se calcularon automáticamente utilizando las herramientas de desarrollo del navegador junto con un fragmento de código que recarga la misma página 10 veces y calcula el promedio.
Tamaño total de CSS y JS y número de archivos (KB) de las páginas del frontend (vista pública). En el caso del CSS, también contamos el tamaño del CSS en línea (inline), que es tan importante para el rendimiento como el CSS en archivos separados.
Tamaño total de CSS y JS y número de archivos (KB) del editor.
Tamaño del HTML (KB) generado en el frontend.
Resultados de Lighthouse, emulando un Moto G Power con conexión Slow 4G y limitación de CPU de 4x, el mismo perfil que usa PageSpeed Insights.

Los tiempos de ejecución se han medido utilizando el plugin Code Profiler Pro. Cada test se ha ejecutado cinco veces y se ha calculado el promedio para asegurar resultados precisos.

Resultados

Tiempo de ejecución de PHP (ms)

Contexto	Divi	Gutenberg
Escritorio	0.200	0.012
Página pública	1.087	0.045

Resultado: La diferencia es dramática y evidente. Al añadir Divi estamos añadiendo aproximadamente un segundo completo al tiempo de ejecución, lo que también afecta directamente al tiempo de carga.

Se podría decir que, dado que no podemos aislar Gutenberg al medir el tiempo de ejecución, el tiempo medido al usar Divi también incluye Gutenberg. Pero ese es precisamente el problema. Para utilizar otro maquetador de páginas como Divi es necesario instalarlo «encima» del maquetador existente (Gutenberg), lo cual inevitablemente afecta los tiempos de carga. La pregunta que queremos responder aquí es cuánto.

TTFB del frontend y tiempo de carga completo (ms)

Contexto	Divi	Gutenberg
TTFB	904	485
Load	1405	938

Resultado: El TTFB es casi el doble cuando se utiliza Divi. El evento Load es aproximadamente un 50% más lento con Divi que con Gutenberg. Este indicador representa el tiempo necesario para cargar todos los recursos que están directamente referenciados por el documento HTML, no los recursos que se cargan posteriormente mediante scripts.

Divi ofrece muchos más módulos y opciones de personalización, pero eso tiene un coste que no desaparece cuando se visualiza la página en el frontend.

TTFB del editor y tiempo de carga completo (ms)

Contexto	Divi	Gutenberg
TTFB	856	711
Load	4692	1488

Resultado: El TTFB es bastante similar entre ambos editores, aunque sigue siendo algo mejor en Gutenberg. Sin embargo, el evento Load muestra una diferencia mucho mayor. Con Divi, el navegador tarda más de tres veces en cargar completamente la interfaz del editor.

Archivos CSS y JS

Contexto	Divi	Gutenberg
Frontend CSS	0 solicitudes (129 KB en línea, 115 KB solo de Divi)	2 solicitudes, 36 KB transferidos (62 KB en línea en total)
Editor CSS	44 solicitudes solo de Divi (3548 KB transferidos)	8 solicitudes en total (1359 KB transferidos)
Frontend JS	14 solicitudes (227 KB transferidos)	3 solicitudes (68 KB transferidos)
Editor JS	138 solicitudes solo de Divi (20136 KB transferidos)	93 solicitudes en total (6465 KB transferidos)

Resultado: Divi parece incluir todo el CSS en línea en la vista pública (frontend), lo cual en realidad es contraproducente en cuanto al rendimiento. Al incluir el CSS en línea, Divi impide que el navegador lo almacene en caché para futuras visitas o para visitas a otras páginas dentro de la misma sesión. Además, esto aumenta el tamaño del HTML; incluir algo de CSS en línea puede tener ventajas, pero incluirlo todo no. Tener 115 KB de CSS en línea es demasiado para justificar esta estrategia.

En cuanto a JavaScript, el código en línea es insignificante en ambos casos, pero vemos que el número de solicitudes es significativamente mayor en Divi.

Es en el editor donde se aprecia con mayor claridad lo pesado que es Divi, incluso después de una actualización importante. Se cargan más de 20 MB de archivos JavaScript, frente a menos de 7 MB en Gutenberg. Desafortunadamente, estos 20 MB incluyen archivos de dudosa utilidad como uno de 2 MB llamado et-ai-app.bundle.js (IA en demasiadas partes…).

Tamaño del HTML

Divi	Gutenberg
161 KB	96 KB

Resultado: Primero de todo, hay que tener en cuenta que el servidor no utiliza ningún método de compresión como Brotli, Zstandard o Gzip. En un sitio bien optimizado estos tamaños serían menores porque la compresión HTTP estaría activada. Aun así, esta prueba muestra claramente el efecto de incluir todo el CSS en línea: aumenta considerablemente el tamaño del documento HTML.

Lighthouse

Divi

Gutenberg

Resultado: Divi empeora casi todos los indicadores de Lighthouse, especialmente el CLS. Esto ya era un problema en versiones anteriores y parece seguir siéndolo. También es preocupante que Divi introduce una gran cantidad de JavaScript sin utilizar, algo que Lighthouse señala durante la prueba sintética de rendimiento.

Puntos clave

Lamentablemente, no puedo decir muchas cosas positivas sobre Divi, incluso después del gran re-desarrollo de la versión 5.

El editor es mucho más agradable de utilizar y mucho más ágil que la versión anterior de Divi, pero tarda mucho más en cargarse que Gutenberg.
Divi genera páginas mucho más pesadas que Gutenberg y utiliza malas prácticas en términos de rendimiento, como JavaScript sin usar y demasiado CSS en línea.
En general, todos los aspectos medidos de Divi son peores que los de Gutenberg.
Todas las Core Web Vitals se ven afectadas negativamente al usar Divi, especialmente el CLS, que sigue siendo un problema en Divi 5.

Conclusión

Después de probar la nueva versión de Divi, debo admitir que el editor es un soplo de aire fresco, incluso tardando mucho más que el de Gutenberg en cargarse. En la versión 4 el editor era lento y en servidores poco potentes podía tardar años en cargar. Ese problema parece haberse solucionado.

Sin embargo, parece que solo se ha mejorado la sensación de respuesta del editor. El rendimiento sigue siendo un problema, especialmente el CLS, que a estas alturas casi parece ya una característica de Divi.

Sí, Divi ofrece muchas funcionalidades, pero creo que el coste en rendimiento es difícil de justificar. Gutenberg ya es una opción válida para la mayoría de los usuarios, está mejor integrado con WordPress porque forma parte de él, es más fácil de usar y genera páginas considerablemente más rápidas.

Entonces, ¿es realmente «rápido y ligero» como afirman? Lamentablemente, todavía no lo es.