⌛ Editor V4 generates very large Atomic Cache Validity database entry

[TadeasKula]

Description

Extremely large elementor_atomic_cache_validity-local with autoload had to be forced to off through db cleaner. It got to a point where the whole wordpress stopped functioning.

Agreement

• I confirm I have read and followed the Editor V4 Discussion Form guidelines, and agree this discussion may be closed without warning.

[nicholaszein]

Hi @TadeasKula!

Thank you for sharing this information! We are investigating this information, but so far we could not reproduce it on our side.

Usually for this kind of report we ask users to submit a 🐛 Editor V4 Bug Report. This way we can gather more information such as the Elementor System Info, and try to reproduce the issue on our end with more accuracy.

Would you mind elaborating a little more about your issue? We are looking for the following information:

1. Steps to Reproduce - How you found out this was the error, where, and how did you use the Editor V4 features so we can try to reproduce it on our end.
2. Elementor System Info - Please share your full Elementor System Info so we can replicate your environment, including installed plugins, theme, active features, element usage, and error logs.

Looking forward to hear from you! 🙏

Kind regards

[nicholaszein]

Hi @TadeasKula!

We are investigating this issue, and having a hard time to reproduce it. Would it be possible for you to copy the contents of this database entry and share it in a text file with us? There is no sensitive data in this entry, so it's safe to share it here. We need to investigate this further and having this information would help us a lot!

Also, if you could please share a little more about the site you are testing this with, it would be awesome!

We're looking to understand the following:

• How many posts, pages, and any other CPT you have in this site.
• if you have any functionality that duplicates posts, pages, or CPTs.

We want to ensure this is not a problem that could affect production sites once V4 is released. Your help will make Editor V4 be more stable!

Thank you in advance! 🙏

[nicholaszein]

Hi @TadeasKula!

Any news on this?

[nicholaszein]

Hey @TadeasKula,

we've been working on changing how we handle the cache validity, and soon this won't be a problem anymore.

But we still would love to hear your feedback regarding the other comments I made.

Please let me know.

Kind regards!

[juxehq]

Independent confirmation at larger scale, plus three findings that compound
what's reported here.

Environment: Elementor 4.2.3, WP 7.1, PHP 8.4, nginx, 3 dedicated cores.
Marketplace theme, ~2,700 published posts, ~40 items rendered per listing
page. Validity options at steady state: __global 575 KB, __local 575 KB,
__global_related 287 KB, __component-styles-related-posts 128 KB (~1.5 MB).

1. The cost multiplies when a theme fires the style hooks per loop item.
Themes that render Elementor templates inside a loop fire
elementor/post/render and elementor/frontend/after_enqueue_post_styles
once per item — both public API. On a 40-item feed that runs the full
validity pipeline ~40x per page rather than once. Our numbers with this
multiplication present:

	uncached TTFB
listing feed page	5–8 s
homepage (multiple feed widgets)	~17 s

2. The write path has no dirty check.
Cache_Validity_Item::validate_nested_node() always ends in
update_stored_data() → update_option(), even when the node is already
true and nothing changed. WordPress then deep-compares the full stored tree
before deciding not to write — O(tree size) on every call.
Atomic_Styles_Manager::render() (atomic-styles-manager.php:135) calls
validate( $breakpoint_path ) unconditionally per breakpoint × style key, so
this fires many times per render regardless of state. This is separate from
the by-value/by-reference copying already reported, and needs its own fix.

3. $post_ids is never reset.
enqueue_styles() early-returns only while $post_ids is empty, and
register_hooks()'s elementor/post/render listener appends without ever
clearing. So after the first item, every subsequent
after_enqueue_post_styles fire redoes the entire pipeline.

Dose-response (same URL, load-verified idle server):

validity data	uncached TTFB
~0 KB (options deleted)	1.2 s
~890 KB (partially rebuilt)	~4.4 s
~1.5 MB (steady state)	5.5 s

Deleting the options is only transient — they rebuild within a day and the
times return, which matches the unbounded-growth finding above.

Our hosting provider's independent forensics over 18 hours: 1,932 requests
exceeded 10 s, 61% inside this module, 41% of total time in a single
unserialize call.

Theme-independent reproduction. With only Elementor + Hello theme active
and a few hundred KB in the validity options, in a frontend request:

for ( $i = 0; $i < 40; $i++ ) {
    do_action( 'elementor/post/render', $template_id );
    do_action( 'elementor/frontend/after_enqueue_post_styles' );
}

[Jpegtobbe]

I got this on a site now. The solutions was to disable the new Atomic Editor. Isnt this fixed by now?