Atomic Editor v4 slows existing pages before conversion

[rajandangi]

Problem

Enabling Atomic Elements slowed existing frontend pages before we converted their content to Atomic widgets. This needs product performance triage. It is not a request to optimize our storage service.

The first comparison covered 40 pages. All 40 page medians increased, and median time to first byte went from 1.109 s to 1.311 s, about 18%. I then ran two tighter controlled comparisons on three representative pages. Editor V4 and Containers stayed active. The other plugins and page content stayed unchanged. I changed only e_atomic_elements in off/on/on/off blocks. Every page was slower with Atomic Elements on in both runs:

Anonymized page	First controlled run	Plugin recheck
A	13.0% slower	13.5% slower
B	9.4% slower	15.9% slower
C	45.0% slower	52.4% slower

These percentages vary by page and run. The 18% in the old title was one historical aggregate, not a fixed cost of V4. All measured requests returned HTTP 200.

Separate PHP traces in both controlled runs found the same added work with Atomic Elements on: 44 to 48 Elementor Atomic CSS manager lookups and 2 to 6 generated-CSS file-existence checks per page request. In our offloaded-media setup, those checks became 2 to 6 synchronous S3 metadata and AWS client calls. Elementor's Atomic rendering path initiates the extra checks. S3 increases their cost; I do not claim that the same percentage slowdown occurs with local storage.

I built a reproducible WP-CLI plugin so the team can run the same on/off comparison on a local WordPress site. Its S3 call trace is optional. The repository contains no private routes, credentials, or raw site reports.

Production impact and requested action

If page speed matters, I cannot recommend enabling this V4/Atomic Elements stack on a live site without testing representative pages on staging first. In our tested configuration, the frontend cost and lack of a supported mitigation make it too immature for production. A previous activation coincided with a site crash, which these timing tests did not reproduce and which remains unresolved.

Please assign this to the Atomic frontend/CSS engineering team as a performance defect. Investigate why the valid CSS cache path still makes synchronous file checks, remove avoidable request-time work, and identify a supported interim mitigation. The generated-asset path request in #36712 is related. The unchanged-CSS rewrite question in #36713 is separate.

Please also check frontend performance in every Editor V4 iteration, including existing pages that have not been converted. Repeated HTTP timing and a tool such as WP-CLI's profile command can catch added PHP work before customers discover slower sites after an update. If you already have a release performance check, please explain what it measures and how this regression passed it.

This discussion is currently filed as a Feature Request. I cannot move it to the Editor V4 category with my account. Please reclassify it for bug triage.

Agreement

• I confirm I have read and followed all the guidelines and instructions outlined in the Feature Request form.
• I agree that my discussion may be closed without further action if it doesn't meet all the requirements outlined in the Feature Request form.

[rajandangi]

Please escalate this to the Atomic frontend/CSS engineering team. Follow-up testing has isolated a reproducible frontend slowdown to Atomic Elements interacting with S3-backed generated CSS. Enabling the feature adds blocking storage requests to existing public pages, without converting their content.

I kept Editor V4 opt-in and Container active and changed only e_atomic_elements. The theme, plugins and page content stayed the same. I repeated off/on/on/off blocks, with a warm-up before each block's page samples and six measured requests per state on each of three pages.

Anonymized page	Median TTFB, Atomic off	Median TTFB, Atomic on	Added time	Increase
Page A	1.692 s	1.912 s	220 ms	13.0%
Page B	1.582 s	1.730 s	148 ms	9.4%
Page C	1.484 s	2.152 s	668 ms	45.0%

Separate real-request PHP profiles identified the added work:

• Atomic_Styles_Manager::enqueue_styles() calls CSS_Files_Manager::get().
• The valid-cache path still enters has_non_empty_file(), which calls WP_Filesystem_Direct::exists().
• With S3-backed uploads, file_exists() reaches S3_Uploads\Stream_Wrapper::url_stat() and the AWS HTTP client.
• This added 2, 2 and 6 remote S3 metadata calls per request on the three tested pages. The file-existence checks occupied approximately 198 ms, 198 ms and 605 ms in the enabled profiles. Those profiled timings include instrumentation overhead; the table above comes from separate, unprofiled requests.

The CSS manager made 44 to 48 lookups, but caching reduced the actual additional remote calls to the counts above. The problem is that the remaining remote checks still block the frontend response on warmed requests.

The original 40-page test showed the 18% increase in this discussion's title. These later controlled tests establish a specific causal path and a route-dependent cost; they do not claim that every page slows by exactly 18% or 45%. All measured requests succeeded. The earlier crash remains a separate, unresolved issue.

This needs to be handled as a performance defect, even though the discussion is currently in Feature Request. An extra 148 to 668 ms on existing pages is a serious obstacle to enabling V4 in this configuration. Please confirm an engineering owner, a supported interim mitigation, and the intended fix or target release.

The generated-assets location request in #36712 is directly relevant. We need a supported way to keep generated CSS independent of remote media storage, alongside a review of why valid cached CSS requires synchronous remote metadata checks on frontend requests.