Why is Elementor still rewriting unchanged CSS files?

[rajandangi]

Problem

Elementor appears to regenerate and rewrite generated CSS even when the page content has not changed. Support told me that a 24-hour regeneration is expected. That still leaves the important question: does Elementor compare the generated output with the existing file before writing it?

If the bytes are unchanged, writing the file again creates avoidable filesystem work on a normal local WordPress site. Offloaded storage makes the same work more expensive, but it does not cause Elementor to decide to regenerate or write the file. Please confirm the current behavior and skip unchanged writes safely, or explain why rewriting identical output is required.

I have since measured a second, distinct problem. Enabling Atomic Elements adds generated-CSS file-existence checks during ordinary frontend requests, with no page conversion. On our setup, 2 to 6 of those checks became synchronous remote metadata calls per request. That request-time behavior is documented in #37472 and the reproducible WP-CLI plugin. The plugin measures on/off response times and call counts; it does not test the 24-hour rewrite behavior raised here.

Please investigate both behaviors without merging them into an S3 integration issue. Unnecessary writes and request-time checks originate in Elementor's generated-CSS handling, and the rewrite question applies to locally stored CSS too.

Agreement

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

[rajandangi]

I have completed controlled profiling and found a second, separate filesystem cost alongside the unchanged CSS rewrites raised here.

With Atomic Elements enabled, Elementor checks whether generated CSS files exist during ordinary frontend requests. On our S3-backed uploads setup, those checks pass through the filesystem wrapper and trigger additional remote metadata requests. Across three tested pages, toggling only Atomic Elements added 2, 2, and 6 metadata requests per page; median response time rose by 0.148s, 0.220s, and 0.668s (9.4% to 45.0%).

This is synchronous work on normal page views, separate from the once-daily CSS regeneration behavior. The issue here is already about avoidable filesystem operations; please investigate both the repeated no-change writes and these request-time file-existence checks. The extra requests create recurring storage cost and a serious risk for sites using remote uploads.

I have kept the measurements anonymized and have not attached the report.