When a WordPress save slows down as old revisions are pruned, measure the save request before disabling revision history. WP Rocket 3.24 includes a targeted change that avoids unnecessary Used CSS and Performance Hints deletion work for revision IDs. It is not a general fix for every slow editor request.
Recognize the relevant pattern
The upstream fix distinguishes revision records from their parent post. Revision cleanup could trigger database lookups for optimization records that did not belong to those revision IDs. The release notes list the change in 3.24.
Your evidence should show a slow save, revision pruning during that save, and the relevant optimization callbacks or database activity. If the delay happens before the request leaves the browser, investigate editor JavaScript instead. If a remote API consumes the time, removing local revision lookups may make little visible difference.
Use a disposable staging post
Copy the relevant plugin settings to staging and create a test post without customer information. Preserve the existing revision policy. Ask the administrator how revisions are limited and when pruning occurs before creating test history. Do not lower the production limit merely to force a reproduction.
Record the installed versions, active optimization features, request duration and number of revisions before the test. Capture a save that does not prune history and a comparable save that does. Keep the content size and other plugins constant. Treat this as a controlled comparison, not a benchmark claim about every WordPress installation.
Read the request, not just the spinner
Use an authorized query profiler on staging to group database work by caller. The editor's spinner includes more than the database: browser processing, network time, PHP execution and response handling can all contribute. Separate those observations in your notes.
| Observation |
Interpretation to investigate |
| Delay before the request starts |
Editor or browser work |
| Long PHP request with repeated optimization lookups |
Relevant server-side path |
| Slow external HTTP calls |
Integration or remote service |
| Fast save but stale public page |
Invalidation or delivery problem |
Record the revision IDs involved and the parent post ID. Do not confuse a parent-page invalidation with an unnecessary lookup for a revision. Avoid copying complete query output into public tickets if it includes content, identifiers or infrastructure details.
Revision cleanup and parent-page invalidation have different jobs; removing unnecessary revision work must not leave the public page stale. Explanatory example, not a customer test.
Compare the supported update
Take a staging backup, update to a supported WP Rocket release containing the fix, and repeat the same save sequence. Compare the caller-level work and duration across several equivalent requests. A single unusually fast save is weak evidence, especially if the database and object cache were warmed by the earlier test.
The desired outcome is less unnecessary revision-related work without breaking parent-page invalidation. Do not promise a fixed percentage improvement. The total time saved depends on how much of the original delay came from this path. If unrelated queries dominate, preserve that result and investigate their owner separately.
Verify that the published page still changes
Change a harmless visible marker on the test post and save it. Check the logged-out public page after the normal optimization regeneration completes. Verify both content and layout. A fast save that leaves old content in the CDN is not an acceptable repair.
Also confirm that a normal parent post still triggers its expected Used CSS refresh when appropriate. If the layout breaks after the refresh, continue with Remove Unused CSS troubleshooting. That is a different acceptance test from the save-time query reduction.
Keep revisions useful
Do not delete revision history simply to hide the symptom. Revisions can provide a recovery path for editorial mistakes, and a sweeping cleanup changes the test conditions. If a retention policy needs to change, make that a separate approved decision with a backup and a clear business requirement.
Remove temporary profiling after collecting evidence, retain a short redacted before-and-after record, and note any unrelated slow callers. HandL WP performance support can help identify whether the remaining delay belongs to database work, cache regeneration or an external integration.
Sources reviewed October 31, 2026. The suggested checks and diagrams are diagnostic aids, not claims of tests performed on your site.