Atomic Editor v4 ties generated CSS to uploads and adds request-time checks

[rajandangi]

Problem

Atomic Editor v4 puts Elementor-generated CSS under WordPress's uploads directory. There is no supported way to set the generated assets' filesystem path and public URL separately from media uploads. This now has a measured frontend cost, beyond the deployment limitation I originally reported.

I ran repeated off/on/on/off tests with Editor V4 and Containers active, leaving the other plugins and existing page content unchanged while toggling only Atomic Elements. On three pages, the Atomic rendering path added 44 to 48 CSS manager lookups and 2 to 6 generated-CSS file checks per request. With offloaded media, those Elementor checks became 2 to 6 synchronous S3 metadata calls. The storage layer increases the cost of the checks; Elementor initiates them during frontend rendering.

The reproducible WP-CLI plugin measures the on/off response times and can trace this call path. It runs without S3; S3 tracing is optional. It contains no private routes or site reports.

What needs to change

Please remove unnecessary checks from the valid CSS cache path and provide a supported way to set Elementor-generated assets' filesystem path and public URL independently of media uploads. Media could then remain offloaded while generated CSS stays local, without overriding WordPress's global uploads directory. A local-path override is a mitigation to test, not a substitute for fixing unnecessary request-time work.

The measured slowdown is in #37472. The question of rewriting unchanged CSS in #36713 is separate. Please treat this as an Elementor generated-asset design and performance issue, not a request to configure a particular storage provider.

Agreement

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

[rajandangi]

This request now has a measured frontend performance impact and needs priority. Follow-up testing for #37472 traced Atomic Elements' generated-CSS existence checks through the S3 uploads stream wrapper into synchronous remote metadata requests.

With Editor V4 opt-in and Container held active, changing only Atomic Elements added 148 to 668 ms to median TTFB across three tested pages, equivalent to 9.4% to 45.0%. The other plugins and page content stayed unchanged. Repeated off/on/on/off tests reproduced the effect, and PHP profiles showed 2 to 6 additional S3 metadata calls per request in the Atomic styling path.

That makes the inability to separate generated assets from media storage a practical deployment problem. Existing public pages pay the extra request cost simply from enabling Atomic Elements. Please provide or identify a documented, supported way to override the generated CSS filesystem base path and its public URL independently of the media uploads directory.

The intended configuration is straightforward: keep media offloaded while allowing Elementor's generated assets to stay local. That would let us test a supported mitigation without patching Elementor or changing storage for the entire media library. Local storage has not yet been benchmarked as a fix, so I am not claiming that configuration is already verified.

Please confirm who owns this work, whether a supported mitigation exists today, and when the path/URL override or another supported solution can be delivered. The detailed, anonymized measurements and call path are in #37472. The repeated-write question in #36713 remains separate; these new measurements establish remote file-check overhead, not repeated writes.