Severe Elementor and frontend delays with WoodMart on Local

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 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,

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

Hello,

Thank you for your reply. We have now migrated the website to online hosting and created a separate staging copy for your investigation:

https://staging.pharmeka.com/

**The correct homepage is the page named “HOME V1”.** Please use this page when checking the layout issue.

Here is what we have confirmed so far:

– The issue occurred in our previous local environment and also occurs on the online installation.
– We tested enabling “Load HTML dropdown with AJAX” for just one menu item: **Shop by Need → Πρόσωπο & Ανάγκες Δέρματος (Face & Skin Needs)**.
– The HTML Block assigned to this dropdown is named **“Mega Menu – Shop by Need – Face & Skin Care”**.
– After enabling the option and saving the menu, the homepage initially appears correctly.
– After approximately **10–15 seconds**, its styling and layout break automatically, **without hovering over or opening the dropdown**.
– The visible changes affect the rest of the homepage, including typography, card layouts, spacing and alignment.
– Setting the option back to **No**, saving the menu and refreshing the homepage restores the correct appearance.

We have attached a screenshot showing the broken layout.

The staging website has HTTPS enabled, and we have created a dedicated Administrator account for your team. We successfully tested this account in a private browser window. Its WordPress administration language is set to English.

You may reproduce the issue and make troubleshooting changes on the staging installation. Please carry out all tests there and leave the main website at pharmeka.com untouched.

Please let us know the cause and provide details of any changes or fix applied, so that we can implement the solution on the main installation.

The staging login details are provided in the Private content field.

Best regards,
Stelios

Hello,

Thank you very much for thoroughly investigating the issue and for providing the JavaScript workaround.

We confirmed that the code was added under **Theme Settings → Custom JS → On document ready**. We then enabled **“Load HTML dropdown with AJAX”** for all relevant items in both mega menus on the staging website.

The workaround appears to resolve the frontend issue. We tested the homepage for more than five minutes, opened both mega menus and observed no broken layout or other malfunction.

However, the problem remains inside the Elementor editor:

– **Home V1** loaded in approximately **1 minute and 43 seconds**. This is a noticeable improvement compared with our previous local tests, where the same page required more than three minutes to become usable.
– Once the editor loaded, the CSS and layout inside the editing canvas were severely broken. Sections, columns, text and product layouts appeared compressed, overlapping or misplaced.
– **Preview Changes** and the normal frontend display the page correctly. The issue occurs specifically inside the Elementor editor.
– The Console shows several missing image requests with 404 responses and some Chrome extension runtime messages, but no clear WoodMart or Elementor JavaScript exception.

We have left AJAX enabled for both mega menus on the staging website so that you can reproduce the issue directly. The affected page is **Home V1**.

Could you please check whether the workaround also needs to run inside the Elementor editor iframe, or whether AJAX-loaded mega-menu CSS requires separate handling in the Elementor editing environment?

We have not applied these changes to the production website.

We are attaching screenshots of the broken Elementor editor and the browser Console.

Thank you again for your assistance.

Best regards,
Stelios

Hello,

Thank you for investigating the issue.

We would like to add an important observation. On our production website, [https://pharmeka.com/](https://pharmeka.com/), we can open and edit the Home V1 page with Elementor without the CSS or page layout breaking.

The CSS issue occurs on the staging website, where “Load HTML dropdown with AJAX” is currently enabled for both mega menus and the JavaScript workaround has been applied. On the production website, AJAX dropdown loading is still disabled.

Both websites are hosted in the same hosting environment. Although the production Elementor editor may still take some time to load, the page styles load correctly and the editing canvas remains usable.

Could this difference indicate that the cancelled style requests are related not only to server performance, but also to a staging-specific or AJAX-related configuration? Please let us know which requests or diagnostic information you would like us to collect from the production website for comparison.

We have not made any further changes so that the staging issue remains available for investigation.

Best regards,
Stelios

Hello XTemos team,

First, thank you for your previous replies and your assistance with our website’s performance and Elementor editor issues. We appreciate your investigation and guidance.

Following your feedback, we are arranging the migration of our website to a new hosting environment with better specifications and more resources. Our aim is to address the server response times and provide a more suitable environment for developing and running our WooCommerce store.

We would now like your guidance on WoodMart’s **“Mobile version → Choose HTML block (experimental)”** feature.

Our website is **https://pharmeka.com/**, and its static homepage is **Home V1**. The website is still under construction, so ordinary visitors see the coming-soon page. We test through an administrator session or the visitor preview/share link.

We want a simpler, purpose-built mobile homepage, with a different content layout from the desktop homepage, while keeping the same homepage URL.

We created and published an HTML Block named **“Mobile Home – Test”** and selected it under:

**Home V1 → Edit with Elementor → Page Settings → Mobile version**

The mobile version initially worked: our test content appeared both on a real smartphone and in Chrome DevTools with a mobile user agent. However, the regular desktop homepage content now appears again, including on a real smartphone while logged in as an administrator.

So far, we have confirmed the following:

– **Home V1** remains the static homepage in WordPress Reading Settings.
– **Mobile Home – Test** is published and can display its content correctly when opened directly.
– The block remains selected in Home V1’s Mobile version settings after closing and reopening the Elementor editor.
– The issue occurs on a real mobile device, not only in a responsive preview.
– During troubleshooting, the HTML Block selector temporarily failed with “The results could not be loaded.” Its admin-ajax.php request, using the action woodmart_get_posts_by_query, returned HTTP **403** with response **-1**.
– After reopening the editor, the selector worked again and listed the available HTML Blocks. However, the mobile homepage rendering issue remained.

We cannot yet confirm whether the selector error and the frontend behaviour share the same cause.

Could you please clarify the following?

1. **Is this feature intended for production use?**
The “experimental” label leaves us unsure whether this is a fully supported feature suitable for a live store, or primarily a testing/demo capability. Are there any known limitations or plans to change or discontinue it?

2. **How does WoodMart decide when to display the mobile HTML Block?**
Does it rely on WordPress server-side device detection, the user agent, viewport width, or another mechanism? What should we check when the selected block is saved correctly but the regular page content is still displayed?

3. **Are there specific compatibility or caching requirements?**
Please advise whether Elementor’s Atomic elements, page templates, coming-soon mode, or caching configuration can affect this feature. If separate mobile caching or particular cache exclusions are required, please specify them.

4. **What mobile development approach would you recommend for our store?**
Would you recommend:
– A separate mobile HTML Block through this feature;
– One responsive Elementor page with shared content and responsive layouts;
– Separate desktop/mobile sections with visibility settings;
– Or another WoodMart-supported approach?

Our priority is a reliable, fast mobile shopping experience with a lean DOM, minimal unnecessary markup and scripts, and maintainable styling through reusable classes. We would prefer to use Elementor Atomic elements where compatible, alongside WoodMart/WooCommerce widgets where appropriate.

We also want to avoid loading substantial desktop-only content on mobile merely to hide it with CSS, while maintaining essential content and SEO consistency across devices.

Before we continue building the mobile interface, we would appreciate your recommendation on the most robust approach for WoodMart and any diagnostic steps you suggest for the current issue.

We can provide screenshots and administrator access through your private support channel if needed.

Thank you again for your help.

Best regards,
Stelios
Pharmeka

Hello,

Thank you for clarifying how WoodMart detects mobile devices. We confirmed that wp_is_mobile() returns true on our phone when opening the homepage (Home V1, ID 30867), but the homepage still displays its regular content.

We reproduced the issue on a separate test page using the same phone and the same assigned HTML Block:

– **Default template:** The mobile HTML Block appears.
– **Elementor Full Width:** The regular page content appears instead.
– **Back to Default:** The mobile HTML Block appears again.

The only setting we changed on the test page was the page template. The screenshots show the two results.

Is this a known limitation? Is there a supported fix or workaround that lets us keep the current full-width desktop layout on Home V1 while serving the separate HTML Block on mobile?

Best regards,
Stelios
Pharmeka