El panel de widgets de Elementor se queda cargando tras instalar un addon: el problema de los 48 MB

Respuesta rápida: si el editor de Elementor abre pero el panel de widgets se queda cargando, o el editor empieza a devolver errores 500 justo después de activar un paquete de addons, revisa el tamaño de la configuración de widgets que descarga el editor. En este caso eran 48 MB, describían 307 widgets y el servidor tardaba 13 segundos en generarla. Desactivar los 173 widgets de addons que la web no usaba la dejó en 11,6 MB y el editor volvió a cargar con normalidad.

Qué pasó

La web de un despacho de abogados hecha con Elementor y Elementor Pro, con dos paquetes de addons ya instalados. A las 11:12 alguien activó un tercer paquete para montar un pie de página global. De 11:18 a 11:41 el editor no dejó de fallar: el panel de widgets daba vueltas y las peticiones a admin-ajax.php devolvían errores. La parte pública de la web funcionó bien todo el tiempo.

Por qué los paquetes de addons provocan esto

Cuando se abre el editor, Elementor envía al navegador la descripción de cada widget registrado: cada control, cada opción, cada valor por defecto. Los paquetes de addons registran decenas de widgets cada uno, y todos entran, se usen o no. Tres paquetes encima de Elementor Pro sumaban 307 widgets. Generar esa descripción le llevaba al servidor 13 segundos, y la respuesta pesaba 48 MB. En un servidor compartido con carga, eso basta para chocar con los límites de tiempo y de memoria.

Cómo verlo

1. Abre el editor con las herramientas de desarrollo del navegador en la pestaña Red (Network).
2. Filtra por admin-ajax y busca la petición que devuelve la configuración de widgets (la respuesta contiene get_widgets_config).
3. Mira su tamaño y su tiempo. Cualquier cosa en decenas de megabytes, o un 500 en esa petición, apunta aquí.

Averigua qué widgets usa de verdad la web

Elementor guarda el diseño de cada página como JSON en el metadato _elementor_data. Este fragmento cuenta cada tipo de widget en uso. Guárdalo como widgets.php y ejecuta wp eval-file widgets.php:

<?php
global $wpdb;
$used = array();
$rows = $wpdb->get_col( "SELECT meta_value FROM {$wpdb->postmeta} WHERE meta_key = '_elementor_data'" );
foreach ( $rows as $json ) {
	preg_match_all( '/"widgetType":"([^"]+)"/', $json, $m );
	foreach ( $m[1] as $widget ) {
		$used[ $widget ] = ( $used[ $widget ] ?? 0 ) + 1;
	}
}
arsort( $used );
print_r( $used );

En esta web solo se usaba un widget de los tres paquetes: una rejilla de entradas en la página del blog. Todo lo demás venía de Elementor y Elementor Pro.

La solución

En Elementor > Gestor de elementos, desactiva cada widget que la web no usa. Elementor muestra el número de usos junto a cada uno, así que puedes confirmarlo antes de apagarlo. Desactivamos 173 widgets de addons y mantuvimos el que estaba en uso. Elementor guarda esta lista en la opción elementor_disabled_elements, de la que conviene hacer copia antes de cambiarla.

El resultado: la configuración de widgets bajó de 48 MB a 11,6 MB y el panel abrió sin errores. Si alguien necesita uno de esos widgets más adelante, lo vuelve a activar en la misma pantalla.

Lista de comprobación

• Editor roto, web pública bien, justo después de activar un addon: sospecha de la configuración de widgets.
• Mide la petición antes de subir los límites de memoria o tiempo. Unos límites más altos esconden el problema durante un tiempo.
• Cuenta los widgets en uso a partir de _elementor_data.
• Desactiva los widgets sin uso en el Gestor de elementos y guarda copia de la opción.
• Mejor un paquete de addons que varios que se solapan.

Preguntas que nos hacen sobre esto

¿Desactivar un widget rompe las páginas que lo usan?

Sí, un widget desactivado deja de mostrarse donde se usa. Por eso se comprueba el número de usos, o se ejecuta el fragmento de arriba, antes de apagar nada.

¿Esto hace más rápida la web pública?

La mejora principal está en el editor. Algunos addons también cargan menos scripts y estilos en la web cuando sus widgets están desactivados, así que ahí también puede notarse algo.

¿No basta con subir la memoria y el tiempo de ejecución de PHP?

Puede que el editor vuelva a abrir, pero el navegador sigue descargando decenas de megabytes cada vez. Quitar lo que la web no usa resuelve la causa.