Elementor widgets panel stuck loading after installing an addon: the 48 MB problem

Quick answer: if the Elementor editor opens but the widgets panel keeps loading, or the editor starts returning 500 errors right after you activate an addon pack, check the size of the widgets configuration the editor downloads. In this case it was 48 MB, described 307 widgets and took 13 seconds to build on the server. Turning off the 173 addon widgets the site never used brought it down to 11.6 MB and the editor loaded normally again.

What happened

A law firm’s site built with Elementor and Elementor Pro, plus two addon packs already installed. At 11:12 someone activated a third addon pack to build a global footer. From 11:18 to 11:41 the editor kept failing: the widgets panel spun, and requests to admin-ajax.php returned errors. The front end of the site was fine the whole time.

Why addon packs do this

When the editor opens, Elementor sends the browser a description of every widget that is registered: each control, each option, each default value. Addon packs register dozens of widgets each, and they are all included whether you use them or not. Three packs on top of Elementor Pro added up to 307 widgets. Building that description took the server 13 seconds, and the response weighed 48 MB. On a busy shared server that is enough to hit time and memory limits.

How to see it

1. Open the editor with your browser’s developer tools on the Network tab.
2. Filter by admin-ajax and look for the request that returns the widgets configuration (the response contains get_widgets_config).
3. Check its size and time. Anything in the tens of megabytes, or a 500 on that request, points here.

Find out which widgets the site really uses

Elementor stores each page’s layout as JSON in the _elementor_data post meta. This snippet counts every widget type in use. Save it as widgets.php and run 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 );

On this site, only one widget from all three addon packs was in use: a blog posts grid on the blog page. Everything else on the pages came from Elementor and Elementor Pro.

The fix

In Elementor > Element Manager, deactivate every widget the site does not use. Elementor shows a usage count next to each one, so you can confirm before switching it off. We turned off 173 addon widgets and kept the one in use. Elementor saves this list in the elementor_disabled_elements option, which is worth backing up before you change it.

The result: the widgets configuration dropped from 48 MB to 11.6 MB and the panel opened without errors. If someone needs one of those widgets later, they switch it back on in the same screen.

Checklist

• Editor broken, front end fine, right after an addon was activated: suspect the widgets configuration.
• Measure the request before raising memory or time limits. Bigger limits hide the problem for a while.
• Count the widgets in use from _elementor_data.
• Disable unused widgets in Element Manager and keep a backup of the option.
• Prefer one addon pack over several that overlap.

Questions we get about this

Will disabling a widget break pages that use it?

Yes, a disabled widget stops rendering where it is used. That is why you check the usage count, or run the snippet above, before turning anything off.

Does this make the public site faster?

The main gain is in the editor. Some addons also load fewer scripts and styles on the front end once their widgets are off, so there can be a small gain there too.

Should I just increase PHP memory and execution time?

It can make the editor open again, but the browser still downloads tens of megabytes every time. Removing what the site does not use fixes the cause.