Fix Elementor Stuck on Loading Screen: Increase Limits and Server Rules

You click “Edit with Elementor”, and you’re stuck staring at that gray screen with the spinner that never stops. It’s almost always one of three culprits: PHP ran out of memory, an execution timer killed the process midway, or a security rule/Nginx buffer severed the connection between the React canvas and WordPress.

I ran into this exact wall last week setting up a landing page on a fresh VPS. The WP admin dashboard felt quick, but the second Elementor tried to initialize its editor canvas, it hung forever. A quick look through the logs revealed two distinct problems: PHP choked on a 128MB ceiling when rendering custom widget templates, and an aggressive FastCGI buffer in Nginx truncated the AJAX payload mid-stream.

Inspect Browser Console and Network Errors

Before touching config files, open DevTools. The frontend editor just hangs quietly, but the browser console usually screams about whatever failed.

Press F12 (or right-click anywhere and pick Inspect), then head over to the Console tab. Look for red errors:

• 500 Internal Server Error hitting admin-ajax.php or /wp-json/elementor/v1/globals
• 403 Forbidden blocking REST API endpoints or admin scripts
• Uncaught TypeError or script failures thrown by an incompatible third-party add-on

Next, flip to the Network tab, filter by Fetch/XHR, and refresh the page. Look for requests highlighted in red. If admin-ajax.php returns a 500, PHP ran out of memory or timed out while generating the widget payload. If it returns 403, a firewall rule, file permission, or bad nonce blocked the request.

Bump PHP Memory Limit in wp-config.php

Elementor officially recommends a 256MB minimum, but honestly, once you stack a custom theme, WooCommerce, and a couple of add-on packs, 512MB is where things actually stay stable. WordPress defaults to 40MB for single-site installs (64MB for multisite), which will choke the builder immediately.

Open your wp-config.php and paste these limits right above the /* That's all, stop editing! Happy publishing. */ line:

// Define WordPress memory limits for frontend and admin tasks
define( 'WP_MEMORY_LIMIT', '512M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

The first constant tells WordPress what front-facing visitors can consume, while WP_MAX_MEMORY_LIMIT dictates the ceiling for admin tasks like the Elementor editor canvas. You can check the WordPress wp-config documentation for a full breakdown of these constants. If you update these values and then get an expired link error while saving templates, take a look at our fix for The Link You Followed Has Expired in WordPress.

Raise PHP Execution Limits in .htaccess and php.ini

Defining constants in wp-config.php only works if your host’s PHP runtime allows WordPress to allocate that memory. If your server caps PHP at 128MB inside php.ini, WordPress cannot override it. You have to lift the ceiling at the server level.

If you run Apache or LiteSpeed with mod_php, drop these directives into your root .htaccess file outside the core # BEGIN WordPress block:

# Increase PHP execution boundaries for Elementor editor
php_value memory_limit 512M
php_value max_execution_time 300
php_value max_input_time 300
php_value post_max_size 64M
php_value upload_max_filesize 64M
php_value max_input_vars 5000

If your host runs PHP as PHP-FPM or suPHP, placing PHP flags inside .htaccess might trigger a 500 server error. In that case, add them to a .user.ini file (or php.ini depending on your control panel) right in your public_html root instead:

; Custom runtime settings for PHP-FPM environments
memory_limit = 512M
max_execution_time = 300
max_input_time = 300
upload_max_filesize = 64M
post_max_size = 64M
max_input_vars = 5000

Setting max_input_vars to 5000 is critical here—without it, saving heavy pages with dozens of nested columns and inner sections will silently drop form data. Compare your values against the official Elementor system requirements to make sure nothing else is under-allocated.

Fix Nginx Buffers and FastCGI Timeouts

If you run WordPress on Nginx and PHP-FPM, the loader often spins indefinitely because Elementor’s massive JSON response overruns Nginx’s default FastCGI buffer sizes. When Nginx can’t buffer the payload in RAM, it tries to write the response to a temporary cache file on disk. If permissions are restricted or worker timeouts occur, the connection drops silently without a clear error.

Here is what I add to the server block or PHP location block inside /etc/nginx/sites-available/your-site.conf to resolve the buffer bottleneck:

# Increase fastcgi buffers and timeouts for complex editor payloads
location ~ .php$ { include snippets/fastcgi-php.conf; fastcgi_pass unix:/run/php/php8.2-fpm.sock; fastcgi_buffers 16 16k; fastcgi_buffer_size 32k; fastcgi_connect_timeout 300s; fastcgi_send_timeout 300s; fastcgi_read_timeout 300s;
}

Test the syntax before restarting so you don’t take your site down:

sudo nginx -t && sudo systemctl reload nginx

If you run multi-domain setups or staging copies under subfolders, verify that root directives aren’t colliding with child rules. Review our troubleshooting walkthrough on how to fix root .htaccess inheritance on subdomains to prevent inherited rules from overriding your API paths.

Adjust ModSecurity and Firewall Rules

Another common cause of the freeze is a Web Application Firewall (WAF) blocking requests to the WordPress REST API or admin-ajax.php. ModSecurity and Cloudflare frequently classify Elementor’s raw HTML and CSS payloads as cross-site scripting (XSS) or SQL injection attempts.

If your server uses Apache with ModSecurity (OWASP Core Rule Set), you’ll see 403 Forbidden entries in your Apache error log (/var/log/apache2/error.log) pointing to rule IDs like 941100 or 949110. You can whitelist these transactions for the admin panel in your virtual host configuration:

SecRuleEngine Off

If you prefer not to disable rule processing entirely across the admin endpoint, grab the exact rule ID from your error log and disable only that specific rule for Elementor paths:

SecRuleRemoveById 941100 941160 949110

If you route traffic through an external reverse proxy or CDN, make sure edge caching isn’t intercepting dynamic admin queries. Check our guide on how to bypass CDN edge cache for admin-ajax.php in WordPress so dynamic builder hooks reach your origin server unmodified.

Switch the Loader Method in Elementor Settings

Elementor has a built-in fallback switch called Switch Editor Loader Method. By default, Elementor initializes the editor canvas inside an iframe. If server rules, an SSL mismatch, or strict HTTP headers (like X-Frame-Options: SAMEORIGIN) interfere, that iframe handshake hangs.

To toggle this setting manually from your WordPress dashboard:

1. Navigate to Elementor > Settings in the left sidebar.
2. Click the Advanced tab.
3. Locate the Switch Editor Loader Method dropdown.
4. Change the value from Disable to Enable.
5. Click Save Changes and reload the target page in the editor.

When enabled, this mechanism bypasses standard iframe initialization and injects canvas controls using alternative event listeners. While it’s a workaround rather than a cure for server misconfigurations, it gets you working immediately while you fix underlying hosting constraints.

Regenerate CSS, Sync Library, and Test Addon Isolation

Corrupted transients or outdated asset caches can freeze the editor parsing sequence before the UI draws. This happens constantly after core Elementor updates or after migrating a site between domains.

Clear Elementor’s internal asset tree by heading to Elementor > Tools > General. Click Regenerate Files & Data, then click Sync Library. This deletes stale generated CSS files in /wp-content/uploads/elementor/css/ and pulls clean widget manifests from the remote library repository.

If the canvas still won’t load, isolate rogue third-party plugins using WP-CLI. Turning off add-ons from the terminal is way faster than clicking around the admin panel:

# List active plugins to review third-party Elementor add-ons
wp plugin list --status=active # Deactivate non-essential visual builder addons temporarily
wp plugin deactivate elementor-pro essential-addons-for-elementor-lite

If Elementor opens smoothly once secondary add-ons are deactivated, re-enable them one by one until the loader breaks again. If you’re dealing with bloated themes imported with heavy demo dependencies, you can also consult our tutorial on how to install an Envato theme and import demo data without timeouts to ensure bundled components aren’t missing required database tables.

Verify Active Configuration with WP-CLI

Never assume your changes worked just because you saved a file. Servers often have multiple php.ini files, or CLI and PHP-FPM run on completely separate configs. You can verify your active PHP environment directly using WP-CLI.

Run this command over SSH to confirm that PHP-FPM and your active WordPress installation reflect the new memory thresholds:

# Check effective memory_limit and execution time under WordPress
wp eval 'echo "WP Memory: " . WP_MEMORY_LIMIT . " | PHP Limit: " . ini_get("memory_limit") . " | Max Exec: " . ini_get("max_execution_time") . PHP_EOL;'

The output should return matches for your targeted allocations:

WP Memory: 512M | PHP Limit: 512M | Max Exec: 300

If ini_get("memory_limit") still reports 128M while WP_MEMORY_LIMIT reports 512M, your web server is ignoring the local php.ini or .htaccess overrides. In that case, locate the active loaded configuration file path using standard PHP CLI:

php -i | grep "Loaded Configuration File"

Open the file returned by that path (such as /etc/php/8.2/fpm/php.ini), alter the directives globally, and restart the PHP-FPM service to enforce the changes.

Frequently Asked Questions

Why does Safe Mode make Elementor load, but regular mode fails?

Elementor Safe Mode disables all plugins and themes other than Elementor itself for the current user session without modifying your database. If the editor opens in Safe Mode, your server environment and core files are functional, and the freeze is caused by a conflicting extension, an outdated child theme hook, or an injected script.

Can I fix the loading issue without SSH access?

Yes. You can edit wp-config.php and .htaccess using your hosting control panel’s File Manager or through an SFTP client like FileZilla. Most managed hosting dashboards also feature a PHP Configuration screen where memory limits and execution timeouts can be adjusted directly from dropdowns.

Why does Elementor work on simple pages but freeze on single complex pages?

Complex pages containing multiple nested columns, dynamic query loops, or heavy CSS gradients generate massive JSON configuration blobs. When loading that specific post, PHP exhausts its memory budget or hits the max_input_vars ceiling during deserialization, causing the canvas to stall while lighter pages continue to load normally.

Will increasing max_execution_time slow down my website?

No. The max_execution_time directive merely establishes the maximum duration a script is allowed to run before the server kills it. Efficient scripts still terminate in milliseconds; the higher threshold simply acts as a safeguard against premature termination during heavy backend tasks like generating page templates.

Once your editor is responsive, make sure your production asset pipelines run lean. Check our guide on how to dequeue unused CSS and JavaScript in WordPress themes to keep page loads fast for end users.