Elementor + WoodMart wp_head consistently 1.7-1.9s, above your stated 0.5-1.2s

Hi,

I’ve been troubleshooting elevated TTFB on my site (rollspel.eu) and have followed your official performance guide (WordPress performance optimization: a step-by-step WoodMart guide) in full before reaching out.

**Setup:**
– WordPress 7.1, PHP 8.5.9, WooCommerce 11.0.1, Elementor 4.2.4
– WoodMart (parent, currently on the latest available version) + a small child theme
– Hosting: Loopia Boost (managed WordPress hosting), recently upgraded tier

**What I’ve already checked/applied, per your guide:**
– Disable default Gutenberg block styles — already enabled
– Disable Gutenberg blocks — already enabled (both in WoodMart and in Elementor’s own “Optimised Gutenberg Loading”)
– Inline styles size limit — set to 40 KB (within your recommended 40-80 KB range)
– Lazy loading for images — enabled correctly, native WP lazy loading disabled to avoid double-handling
– Removed jQuery Migrate — tested, no measurable difference (1.85s vs 1.7-1.9s baseline), no visible breakage so far
– Cleared Elementor’s CSS/data cache (Elementor → Tools → Clear Files & Data) — helped somewhat (dropped from ~1.8-2.4s to ~0.9-1.9s range) but didn’t resolve it
– CSS Print Method confirmed already set to “External File” (recommended)
– Enabled the “Inline Font Icons” performance experiment — no measurable change

**Isolation testing (via Health Check & Troubleshooting plugin, Troubleshooting Mode):**
– Default theme + all plugins off: init 0.27s, wp_head 0.04s (fast, as expected)
– + WooCommerce only: init 0.39s, wp_head 0.04s
– + Elementor (on top of WooCommerce): init 0.72-0.75s, wp_head jumps to 1.6-1.9s
– + WoodMart theme (still nothing else active): wp_head consistently 1.7-1.9s, init ~0.4-0.45s
– Adding/removing ACF made no measurable difference either way

So with only Elementor + WooCommerce + WoodMart active — no other plugins, no customisations — wp_head alone is costing 1.7-1.9 seconds, consistently and repeatably. Per your own guide, a clean setup shouldn’t exceed roughly 0.5-1.2 seconds even before caching. I’m well above that even in the most minimal configuration I can construct.

Query Monitor shows the time sitting inside wp_head as one solid, unattributed block — no specific hooked function is flagged as the cost, which makes it hard to narrow down further from my side. The wd_all_popup_conditions and wd_all_floating_block_conditions checks appear in every trace (twice each), even though Promo Popup is disabled and I have no floating blocks configured — I couldn’t find a way to disable these checks entirely rather than just having nothing configured for them to act on.

**My question:** is 1.7-1.9s expected for WoodMart + Elementor in this version, or is there a known patch/optimisation (like the Patcher tool mentioned in other threads) that addresses this specifically? Happy to provide access to a staging copy if that helps you look directly.

Thanks for your time.

For context on the full picture: total page load (DevTools Network, document request) is 5.13s with only Elementor + WooCommerce + WoodMart active, versus 5.53s with my entire normal plugin stack (~24 additional plugins) re-enabled. In other words, my whole plugin ecosystem beyond these three core pieces adds under half a second combined, the overwhelming majority of the cost sits inside Elementor + WoodMart + WooCommerce themselves, not in anything else I’m running.

Hi there,

Thanks for the detailed report.

Please compare the wp_head time with a default WordPress theme active while keeping the same Elementor and WooCommerce setup. This will help confirm whether the delay is caused by WoodMart or comes from Elementor/WooCommerce or the server environment.

If the result is significantly faster with the default theme and the issue appears only when WoodMart is enabled, please provide temporary WordPress admin access via the forum’s Private Content field. We will then be able to review the setup and test it further.

Kind regards,
XTemos Studio

Ran the test as requested: switched to Twenty Twenty-Five (default theme), kept Elementor, WooCommerce, and the full plugin stack unchanged. Result: wp_head = 1.8383s — virtually identical to WoodMart’s 1.8566s under the same conditions. Given the theme swap made no measurable difference, this points away from WoodMart as the cause. I don’t think admin access to my WoodMart setup would be useful at this point, since the numbers show it isn’t WoodMart-specific — but happy to help narrow this down further if there’s a next step you’d suggest on the Elementor/WooCommerce side.

Update: further isolation shows Woodmart Core (the companion plugin, separate from the theme) does add a real ~0.6s to init. With Woodmart Core, the theme, and Elementor all removed, ~1.16s of init cost remains, coming from WooCommerce core’s own extensive registration (block types, features, Action Scheduler) plus other active plugins. So the picture is: Elementor is the dominant wp_head cost, WoodMart Core is a real but smaller init contributor, and a meaningful baseline remains that isn’t specific to either Elementor or WoodMart.

Separate issue: wd_all_popup_conditions / wd_all_floating_block_conditions never actually cached

Splitting this out from the wp_head performance thread above, since it’s a distinct issue with its own reproduction steps.

In my original post I flagged that Query Monitor’s Transient Updates panel shows both wd_all_popup_conditions and wd_all_floating_block_conditions (caller: XTS\M\F\Manager->get_all_conditions()) as “Updated” on every single page load, with Expiration: none. At the time I guessed this might be an interaction with my persistent object cache (Redis) — that get_all_conditions() wasn’t reading correctly from a persistent cache backend and was falling back to recompute.

I’ve since ruled that out. I migrated the site to entirely new hosting (different provider, fresh WordPress install, fresh Redis instance, fresh everything) and the exact same behavior reproduces identically: both transients still show as freshly recomputed and rewritten on every page load, regardless of whether a persistent object cache is present or which one it is.

That points away from a caching-backend interaction and toward the function itself: get_all_conditions() appears to never check for an existing cached value before recomputing and rewriting it — on both environments, with no expiration set, it behaves as though the transient is write-only. Since these checks run unconditionally on every page load site-wide (I have Promo Popup disabled and no floating blocks configured, and they still fire), this means the full condition-evaluation cost is paid on every single request, for a feature that isn’t even in use.

Given it’s now confirmed across two unrelated hosting stacks, this looks like a genuine bug in XTS\M\F\Manager->get_all_conditions() rather than a hosting or configuration issue on my end — worth a look independent of the wp_head numbers I sent separately.

Hi there,

Thanks for the additional investigation and detailed reproduction steps.

You are correct that the popup and floating block condition transients are currently updated on each request. We will fix this behavior in a future update.

However, these checks involve only minimal calculations and do not have a significant impact on the overall page performance or the wp_head time you reported. They are not the cause of the 1.7–1.9 second delay.

Kind regards,
XTemos Studio

[Author]

Posts