Severe Elementor and frontend delays with WoodMart on Local

Hello WoodMart Support Team,

We are currently developing a WooCommerce website with WoodMart and Elementor in a local environment using Local.

We are experiencing severe performance issues both in the Elementor editor and on the website frontend.

MAIN PROBLEMS

1. Elementor editor performance

Opening a page in the Elementor editor can take more than four minutes in Google Chrome. We also experience significant delays while editing and designing pages.

The same behaviour occurs in Microsoft Edge and in Google Chrome Incognito mode.

However, Elementor loads and works normally in Mozilla Firefox.

2. Frontend performance

The website frontend is also noticeably slow. Opening or navigating to a page usually takes approximately 7–8 seconds, even though the website is running locally on the same computer.

Since the website is hosted locally, we would normally expect pages to load almost immediately. This loading time therefore appears unusually high.

IMPORTANT TEST WITH HELLO THEME

The most important finding from our troubleshooting is the following:

* With WoodMart active, both the Elementor editor and the website frontend are very slow.
* When we temporarily switch to the Hello Elementor theme, everything works smoothly and quickly. The Elementor editor opens almost immediately, and the website navigation is also much faster.
* When we reactivate WoodMart, the severe delays return.

This strongly suggests that the performance issue may be related to WoodMart or to an interaction between WoodMart, Elementor and Chromium-based browsers.

Created a completely blank Elementor page named “Elementor Speed Test”, without any content, widgets or complex layout. The same severe loading delays occurred when opening and editing this empty page. This indicates that the issue is not caused by the amount of content or the complexity of the page.

TROUBLESHOOTING ALREADY PERFORMED

We have already completed the following tests:

1. Temporarily switched from WoodMart to Hello Elementor. Both the editor and frontend then worked smoothly and quickly.
2. Reactivated WoodMart. The delays immediately returned.
3. Tested Elementor’s “Switch Editor Loader Method” both enabled and disabled, without improvement.
4. Tested Google Chrome Incognito mode to exclude browser extensions and cached data.
5. Tested Microsoft Edge, which showed similar delays.
6. Tested Mozilla Firefox, where Elementor works normally.
7. Disabled Avast antivirus shields and added exclusions for Local and the local website.
8. Completely uninstalled Avast. The issue remained.
9. Changed the Local web server from Nginx to Apache. This did not resolve the problem, so we are currently using Nginx again.
10. Created and tested a cloned copy of the website in Local.
11. Reinstalled Google Chrome and created a completely new Chrome user profile.
12. Restarted the computer and the Local environment several times.
13. Monitored the Elementor loading process through Chrome DevTools. We observed a very long idle period near the end of the loading process before the editor became available.
14. During Elementor’s Speed Test, we also observed an ERR_CONNECTION_RESET error in Chromium-based browsers.

SYSTEM INFORMATION

* WordPress: 7.1
* WoodMart theme: 8.6.0
* WoodMart Core: 1.1.9
* WooCommerce: 11.1.0
* Elementor: 4.2.4
* PHP: 8.2.29
* MySQL: 8.4.0
* Local: 10.1.2+7004
* Current web server: Nginx
* Operating system: Windows 10
* Google Chrome: 153.0.8010.37

The website is currently hosted only in Local and is not publicly accessible from the internet.

QUESTIONS

Could you please advise us on the following?

1. Are you aware of any performance or compatibility issue between WoodMart, Elementor and Chromium-based browsers in a Local environment?
2. Which WoodMart scripts, modules, requests or settings could delay the Elementor editor for several minutes?
3. Are there specific WoodMart features we should temporarily disable to isolate the cause?
4. Could the issue be related to WoodMart sliders, AJAX requests, external resources, frontend assets or editor-specific scripts?
5. What could cause frontend pages to require approximately 7–8 seconds to load in a local environment when the same website works quickly with the Hello Elementor theme?
6. Is there any additional diagnostic information, console output, Network recording or system report you would like us to provide?

We can provide screenshots, Chrome DevTools Network recordings, console messages and WordPress/Elementor system information if required.

Thank you in advance for your assistance.

Kind regards,

Stelios Lioudakis
Pharmeka

Attachments:

You must be logged in to view attached files.

Hello,

Thank you for the detailed diagnostic breakdown. Based on your DevTools Network logs, the delays are caused by a severe request-queueing bottleneck in your local server environment. Your network trace shows 1,147 requests with individual admin-ajax.php calls taking 10+ seconds each. Because local environments run PHP sequentially, WoodMart’s concurrent AJAX requests (dynamic CSS compilation, cart fragments, and theme checks) get trapped in a long processing queue. Hello Elementor avoids this as a bare-bones theme, while Chromium browsers handle local socket pooling and local domain lookups far more strictly than Firefox.

To resolve these delays, we recommend upgrading your local server limits by editing your php file.
https://xtemos.com/docs-topic/requirements-wordpress-setup/

Disable heavy development settings: Go to WoodMart > Theme Settings > Performance and turn off CSS/JS Combining during local development.

For optimization settings and preparing the site for live deployment, you can also review our official guides:
https://xtemos.com/blog/wordpress-performance-optimization-a-step-by-step-woodmart-guide/

Also, you can read more details about the accessibility optimization guide here:
https://xtemos.com/woodmart-accessibility-optimization-guide/

Best Regards

Hello,

Thank you for your response and recommendations.

We performed additional checks and tests:

* Increased WP_MEMORY_LIMIT and WP_MAX_MEMORY_LIMIT to 512M.
* Confirmed that the remaining PHP limits are already high: max_execution_time 1200, max_input_vars 4000, post_max_size 1000M, and upload_max_filesize 300M.
* Tested both Nginx and Apache in Local, without any significant difference.
* Tested a completely blank Elementor page named “Elementor Speed Test”. The same severe delay occurred, so the problem is not related to page size or complexity.
* Checked the running processes during the delay. Multiple php-cgi.exe processes were active, but PHP, MySQL and Apache remained at approximately 0% CPU usage.
* Tested with WoodMart Core temporarily disabled, but the issue remained.
* Changed the local domain from .local to .test, without improvement.
* Reinstalled Chrome and tested with a new browser profile, Incognito mode and Microsoft Edge.

Unfortunately, the problem has not been resolved. Elementor remains extremely slow in normal mode, and frontend pages still require approximately 7–8 seconds to load.

We also confirmed two important results:

1. With the Hello Elementor theme active, both Elementor and the frontend work smoothly and quickly.
2. With Elementor Safe Mode enabled, the editor also works normally, without delays or other problems.

Since the same Local environment works correctly with Hello Elementor and in Elementor Safe Mode, the issue appears to involve the active WoodMart environment or an interaction between WoodMart and another component, rather than Local server performance alone.

If it would help your investigation, we can provide a complete export of the Local website, including the database and required files, so that you can reproduce and analyse the issue in your own environment. We can also provide a HAR/Network recording, console logs, or create a temporary staging copy.

Please let us know which option you prefer and how we can share the files securely.

Kind regards,

Stelios Lioudakis
Pharmeka

Hello,

Can you please move the site to the live domain and share the WP admin login details of your site so I will check it further and let you know the solution.

Best Regards.

Hello XTemos Support,

Following our previous discussion about slow Elementor loading on our local WoodMart installation, we have now isolated a major contributor to the delay: the mega menus in the header.

We tested the same homepage in Chrome, using a duplicate test header, and measured the time until Elementor became usable:

– Shop By Product only: 45 seconds.
– Shop By Product + Shop By Need: 3 minutes 38 seconds.
– After removing Shop By Need again: 55 seconds.

Adding Shop By Need also increased DOM nodes from 21,136 to 27,067 and JavaScript event listeners from 3,671 to 4,398. These measurements cover the complete Elementor editing environment.

Our setup uses WoodMart’s native Header Builder and menus, with Elementor HTML Blocks for the mega-menu content. The blocks contain category links, images, promotional banners and nested layouts. Shop By Need also contains several carousels.

We have already simplified Shop By Product by removing all Best Sellers sections and replacing its carousels with static category layouts. We are now reviewing Shop By Need in the same way.

Could you please advise on the following?

1. Can mega-menu HTML Blocks be excluded from loading or initialization inside the Elementor page editor, while keeping the normal header functionality on the frontend?
2. On the frontend, can each mega-menu block load only when its dropdown is first opened, instead of loading all blocks during the initial page load?
3. Can carousel initialization be deferred until the corresponding dropdown becomes visible?
4. What structure and settings do you recommend for multiple large mega menus built with Elementor HTML Blocks?

We previously tried AJAX dropdown loading, but it caused problems on the homepage, so we disabled it. We would appreciate guidance on whether this feature is suitable for our setup and how to troubleshoot it.

Firefox remains considerably faster than Chrome/Edge, and Elementor also loads quickly with the header disabled or in Safe Mode. The earlier server and browser adjustments did not resolve the issue.

These tests strongly implicate the additional mega-menu content, but we still need to determine whether the main delay comes from requests, block rendering, JavaScript initialization or a combination of these.

We can provide screenshots, a site export and database, or any diagnostic recordings you need to reproduce and investigate the issue.

Best regards,
Stelios

Hello,

Thank you for the detailed tests. Your results indicate that the large Elementor HTML Blocks in the header are the main source of the delay. By default, WoodMart renders the complete content of each mega-menu HTML Block in the page header, including in the Elementor preview. Therefore, large blocks with nested layouts and carousels substantially increase the DOM and the amount of JavaScript processing.

– There is no built-in WoodMart option to exclude mega-menu HTML Blocks only in the Elementor editor while keeping them on the frontend. This would require custom development.

– For each heavy menu item, you can enable Load HTML dropdown with AJAX under Appearance → Menus → select the parent menu item → Dropdown settings. This replaces the block in the initial page HTML and loads it through AJAX after the page starts. It can reduce the initial DOM size and improve the initial editor/frontend load.

– Please note that this is not “load on first dropdown opening.” All AJAX-enabled blocks belonging to the menu are requested after page load, then cached in the browser. The Open on mouse event option changes only how the menu opens and does not defer its content loading.

– Carousels are initialized with lazy/viewport-based handling, but there is no dedicated option to initialize them only after a dropdown is opened.

For your structure, we recommend keeping mega-menu blocks as lightweight as possible:
– Use static category grids where possible instead of several carousels.
– Minimize deeply nested Elementor containers.
– Avoid duplicating the same heavy block across multiple menu items.
– Use separate, simpler content for the mobile menu if the same HTML Blocks are currently displayed there as well.
– Enable AJAX loading selectively for the largest dropdowns and test one item at a time.

If AJAX dropdown loading caused an issue on the homepage, please provide the browser Console errors and the Network response for the admin-ajax.php request made when the menu loads. In particular, we need to check whether the woodmart_load_html_dropdowns request returns an error or whether a widget inside the HTML Block is not initializing after the AJAX content is inserted.

After changing AJAX settings or HTML Block content, please also clear the browser cache/local storage for the local domain before retesting, as the dropdown content may be cached in the browser.

Mega-menu documentation:
https://xtemos.com/docs-topic/create-mega-menu/

Best Regards.

Hello,

We tested your AJAX recommendation on a duplicate local installation after simplifying both Shop By Product and Shop By Need and removing the carousels and other unnecessary elements.

To isolate the issue, we enabled “Load HTML dropdown with AJAX” for only one Shop By Need menu item, using Elementor HTML Block ID 29738. We then cleared the browser cache and Local Storage.

The AJAX request completed successfully:

– Action: woodmart_load_html_dropdowns
– ID: 29738
– Status: 200
– Response time: 1.89 seconds
– Response size: 5.6 kB

The homepage initially loaded, but approximately 25 seconds after the test started—when the AJAX content was inserted—the layout of multiple Elementor sections became severely distorted.

Chrome DevTools continued recording network and browser activity after the visible problem had appeared. It reported 1,269 requests, DOMContentLoaded at 5.7 minutes, Load at 5.8 minutes and Network completion at approximately 6 minutes. These figures represent continued background processing and do not mean that we waited six minutes for the layout problem to appear.

After disabling AJAX, clearing Local Storage and repeating the test with the same DevTools settings, the homepage returned to normal. The page generated 635 requests, DOMContentLoaded took 9.20 seconds, Load took 11.44 seconds and Network activity finished after 53 seconds.

The AJAX response itself appears valid and reports:

status: success
message: At least one HTML block loaded

It returns the HTML Block together with the following Elementor CSS files:

– elementor-post-29738.css
– base-desktop.css
– global-29738-frontend-desktop.css
– local-29738-frontend-desktop.css
– base-mobile.css

No direct JavaScript exception appeared in the Console.

Could these dynamically inserted Atomic Elementor CSS files be overriding the existing homepage styles? Is AJAX dropdown loading fully compatible with Elementor Atomic HTML Blocks, or is an additional initialization or configuration required?

We have attached screenshots of the broken homepage, the Network results with AJAX enabled and disabled, the request Payload, the Local Storage entry, and the complete AJAX response.

Best regards,
Stelios

Attachments:

You must be logged in to view attached files.

Hello,

We have tested Elementor Atomic Elements inside HTML Blocks used in dropdown menus, and they work correctly on our side. The required styles are loaded and applied properly and should not affect or break the styles of the rest of the page.

Since you are experiencing a different behavior on your installation, could you please upload or migrate the website to a temporary/staging hosting environment and provide us with access to it?

This would allow us to reproduce the issue directly on your website, inspect what happens when the AJAX dropdown is loaded, and determine why the dynamically loaded Elementor styles are affecting the existing page layout in your particular case.

Best Regards.

[Author]

Posts