What does WP Rocket cache lifespan actually control?
Cache lifespan controls the age of WP Rocket's page-cache files, with an hourly check. It is not a precise countdown for every visitor response and does not control every optimized asset or upstream cache. The official lifespan documentation distinguishes page files from minified assets, documents the global setting, and explains when a host disables WP Rocket page caching.
Before changing the interval, answer three questions: which layer owns the stale HTML, which event clears it, and whether rebuilding completes before the next purge. A lifespan change cannot correct an undefined PHP function in a purge integration. For SiteGround installations, use the helper-function and purge propagation checks.
Keep the decision specific. An outdated HTML marker calls for a freshness investigation. Correct HTML with recurring load calls for a purge-and-rebuild timeline. A broken stylesheet calls for an asset-generation check. Document the symptom and baseline before touching the global interval so improved performance cannot conceal stale business content.
Account for new cookie variants after an update
A cache update can increase legitimate cache variants rather than shorten their lifespan. WP Rocket 3.24 includes changes to dynamic-cookie declarations and a specific Polylang language mode. Compare the generated configuration before and after the change, and count the intended public states before interpreting extra files as a leak.
For example, two independent settings with two permitted values each can require four public combinations. That is a test model, not a claim about your site's actual file count. Do not put session IDs or unbounded tracking values into shared cache keys to reproduce it.
Record whether load occurs once after configuration regeneration or returns on every purge cycle. Verify the correct public response for each approved state, not only lower CPU. Use the multiple dynamic-cookie test when a second choice appears to be ignored. The official dynamic-cookie documentation explains why mandatory and variant cookies have different jobs.
Quick answer
Repeated CPU peaks can come from repeated cache deletion followed by regeneration. Before upgrading hosting or disabling caching, align the peaks with WP Rocket lifespan checks, preload activity, and settings or content changes. A short global lifespan may increase rebuild frequency. It is not a general solution for one widget that needs fresher data.
Confirm which component caches the page
Some managed hosts replace WP Rocket's page-caching function with their own layer. Confirm the hosting integration before assuming the plugin lifespan setting controls the HTML visitors receive. You can still have asset optimization, a host cache, and a CDN operating alongside each other.
List the owners of page HTML, optimized assets, object cache, and edge cache. Give each layer its own row. A screenshot of one plugin setting is not enough to explain a site with four cache layers. Keep the initial investigation read-only, especially during a live traffic spike.
Join the relevant timestamps
Take a host CPU chart covering several cycles. Beside it, record deployments, content imports, plugin setting changes, scheduled purge events, and preload activity. Normalize time zones before comparing them. A task at 09:00 in WordPress may be displayed differently in the hosting dashboard.
WP Rocket documents an hourly lifespan check and the rocket_purge_time_event cron event. It also documents automatic cache clearing after several kinds of configuration and content changes. A recurring import that updates many pages may explain the pattern even when the configured lifespan looks reasonable. The sequence matters: determine whether deletion precedes the expensive work.
Distinguish expiration from a stalled worker
A rebuild that completes and repeats after the next purge is different from a queue that never drains. Measure the pending workload at two or more points instead of reacting to one count. Compare completion progress and server load over the same interval.
If work never progresses, investigate the scheduler using the related guide. If it progresses but starts over frequently, focus on the trigger. Increasing worker concurrency in that second situation can make CPU peaks worse. Do not clear the queue merely to make its count look healthy; you would lose the evidence that explains repeated generation.
Choose a bounded change
Record the original settings and a rollback owner. On staging or during an agreed low-risk window, test one change: for example, removing an unnecessary purge integration or returning an overly aggressive lifespan to an appropriate supported setting. Do not change lifespan, preload, database caching, and hosting resources in the same experiment.
WP Rocket's documented default lifespan is ten hours, but that is not a promise that every site should use the same interval. Freshness requirements, form tokens, host caching, and the actual feature in use all matter. Setting zero disables lifespan-driven clearing; it does not mean every cache invalidation mechanism has been disabled.
UTC time | change or event | queued work | completed work | CPU
record | before purge | record | record | record
record | after purge | record | record | record
record | after rebuild | record | record | record
Verify freshness as well as capacity
After the change, test an updated public page, an unchanged page, and the forms or interactive components that depend on fresh responses. Use a logged-out session and compare the actual public HTML. Check the host and CDN layers independently when they can retain an older version.
Observe at least one expected cycle under comparable traffic. If CPU drops only because visitors stopped arriving, the configuration has not been proven. Record both workload and traffic context. A successful result has bounded rebuild work, correct content, and no new failures in lead forms or checkout.
Keep the conclusion specific
Close with the identified trigger and evidence, not a claim that caching caused every slowdown. Note any separate slow queries or PHP errors for their own investigation. Preserve the before-and-after chart and settings snapshot so the next import or deployment can be compared against a known working state.
Illustrative diagnostic example. Use your own redacted evidence.When to bring in help
Bring WordPress performance troubleshooting the host CPU chart, cache settings, cron evidence, and deployment timeline. Those records help distinguish cache churn from an unrelated slow request.
Related troubleshooting
For the adjacent diagnostic path, read WP Rocket preload queue troubleshooting. Keep its evidence separate from this test so a change in one component does not hide a failure in another.
Helpful references
WP Rocket cache lifespan. WP Rocket cache clearing triggers.
Editorial update October 31, 2026: current documentation and diagnostic guidance reviewed. Original publication date and existing illustrative assets preserved.
Editorial update November 2, 2026: diagnostic distinctions and related guidance reviewed. Existing publication date and illustrative assets retained.