Themeisle Docs

Appearance

super-page-cache

Instant speed boost – enable lazy-loading, defer scripts, and fine-tune caching for blazing-fast pages. Priority support included.

See Pro Plans →

Optimizing Super Page Cache for Large Sites ​

Sites with thousands of posts can experience severe CPU spikes from resource-intensive cache operations. This guide explains which Super Page Cache settings to adjust to reduce server load and maintain a healthy cache on large sites.

Why Super Page Cache Can Cause CPU Spikes on Large Sites ​

Several default settings are designed for convenience on small sites but can become a serious problem when your site grows to tens of thousands of posts. Here are the four most common causes of CPU spikes on large sites.

  1. Purging the whole cache on every post edit — When this option is enabled, every single post edit triggers a complete rebuild of the entire cache. On a site with tens of thousands of posts, that means the server must invalidate and regenerate an enormous number of cached pages all at once, creating massive I/O and CPU load. Smart (granular) purging only invalidates the URLs directly affected by the edit — the edited post itself, its category and tag archives, and the homepage — which is far cheaper and almost always sufficient.

  2. Auto-starting the preloader after a purge — When the preloader is configured to start automatically after a purge, it immediately begins crawling every page on your site to warm the cache. On a large site, this crawl can run for hours and continuously saturate the CPU while it works through the full page list.

  3. Disabled purge queue — Without a purge queue, all cache purge requests fire synchronously in real time. If a burst of post edits or other purge triggers happens at the same time, the server must handle all of them simultaneously, which can cause an instant CPU spike. Enabling the purge queue batches and staggers these requests so they are processed asynchronously.

  4. Fallback cache — The fallback cache generates static HTML snapshots for pages that are not yet stored in the main cache. While useful on smaller sites, regenerating these snapshots across a massive site creates a large upfront CPU hit every time the cache is cleared.

Open Settings > Super Page Cache in your WordPress admin to make the following changes.

1. Disable "Purge Whole Cache on Post Edit" ​

  • Where to find it: Cache tab > Purge cache options section > Purge whole cache on post edit toggle.
  • Action: Turn this off.
  • What it does: The plugin switches to smart purging, which only purges the URLs related to the edited post — the post itself, its category and tag archives, and the homepage. This avoids a full-cache rebuild on every save and is the single most impactful change you can make on a large site.

2. Disable "Start Preloader When Cache Is Purged" ​

  • Where to find it: Preloader tab > Start preloader when cache is purged toggle.
  • Action: Turn this off.
  • What it does: Stops the preloader from automatically crawling the entire site every time a purge occurs. You can still run the preloader manually from the Preloader tab, or schedule it via WP-Cron to run during off-peak hours. See the automation guide for instructions.

3. Enable the Purge Queue ​

  • Where to find it: Cache tab > Purge cache options section > Enable purge queue toggle.
  • Action: Turn this on.
  • What it does: Purge requests are batched and processed asynchronously rather than all at once. This prevents a flood of simultaneous purge requests from overwhelming the server during busy periods.

4. Disable the Fallback Cache ​

  • Where to find it: Cache tab > Fallback cache section > Enable fallback cache toggle.
  • Action: Turn this off (unless it is essential for your specific setup).
  • What it does: Stops the plugin from pre-generating static HTML snapshots for uncached pages, eliminating the large upfront CPU hit that occurs when the cache is cleared on sites with thousands of pages.

Verifying the Changes ​

After saving your settings, confirm that the changes are working as expected:

  1. Edit a post and save it. Monitor your server CPU usage via your hosting dashboard or a monitoring tool — you should see significantly lower CPU usage compared to before the changes.
  2. Confirm that only the affected URLs were purged by checking the plugin's status page or your server logs for purge activity. Unrelated pages should remain cached and unaffected.
  3. If you disabled auto-preloading, run the preloader manually from the Preloader tab to warm the cache at a time of low traffic.

Troubleshooting ​

Cache is not being served after edits ​

Smart purging correctly invalidates only the pages affected by an edit. If visitors are seeing stale content on pages that are unrelated to the edit, check that smart purging is functioning as expected. Also verify that no other caching layer — such as Cloudflare or a hosting-level cache — is serving outdated content independently of Super Page Cache.

CPU spikes still occur after changes ​

  • Confirm that all four settings above are correctly applied and saved.
  • Check whether another plugin or theme is triggering full cache purges programmatically, which would bypass the settings you have configured.
  • Consider scheduling the preloader to run via a cron job during low-traffic hours rather than triggering it on demand. See the automation guide for details.

Testing on staging first ​

It is strongly recommended to test these configuration changes on a staging environment before applying them to production. This lets you confirm that smart purging meets your site's cache freshness requirements without risking a poor experience for live visitors.