Inspect supported WordPress cache layers, compare their settings and purge coverage, and check the page after one change with WPPilot Pro.
WPPilot Pro caching and page speed
Every module has a distinct data model and operating boundary. Open its page for a capability map, workflow examples, validation sequence, and safety notes.
Inspect LiteSpeed Cache settings for pages, CSS, JavaScript and images. WPPilot maps 23 keys and checks live support before writing.
Read WP Rocket settings and change mapped options for page caching, assets, preloading and database cleanup through WPPilot Pro.
Inspect WP Fastest Cache settings and request a whole-cache, URL or post purge through the callbacks available on your site.
Work with SiteGround Speed Optimizer settings for assets, images and caching. Check which cache services your host actually enables.
Read WP-Optimize settings, adjust mapped asset and page-cache options, and inspect the result after a supported purge.
Inspect W3 Total Cache configuration and its separate cache layers. WPPilot maps eight shared settings and exposes native keys.
Inspect Autoptimize asset settings and clear shared CSS and JavaScript bundles. Autoptimize does not provide a page cache.
Read SpeedyCache settings for page caching, object caching, CDN and preloading, then check which purge scopes the installed plugin supports.
Inspect Breeze cache and asset settings through MCP. The purge bridge declares a whole-cache callback, with no URL or post purge candidate.
Inspect Cache Enabler page caching and image settings. Its shared map covers three keys, with separate candidates for cache purging.
Read Perfmatters option rows and edit existing native keys. Shared setting meanings are unverified, and there is no cache to purge.
Inspect FlyingPress native settings and available purge callbacks. WPPilot has no shared settings map for this commercial plugin.
Read WP Super Cache option rows and inspect purge support. Its main file-based configuration is outside this settings driver.
Inspect Redis Object Cache and request a flush when its callback is available. Redis must be configured and reachable.
Inspect Jetpack Boost local options. Cloud sync can replace local changes, and its purge candidate needs a registered callback.
Inspect Aruba HiSpeed Cache local options. The driver has no callable purge entry point; use the host or plugin controls to clear it.
Inspect NitroPack local options and available purge callbacks. Cloud optimization settings remain in the NitroPack dashboard.
Inspect Hummingbird option rows and request a purge through its page-cache module when that module is available.
Inspect 10Web Booster local options. Cloud optimization remains with 10Web, and the driver declares no callable purge entry point.
Inspect Docket Cache options and request an object-cache flush. This file-backed cache has no page-cache settings map.
Inspect SQLite Object Cache options and flush supported object-cache state. This driver does not manage page-cache settings.
Read Powered Cache local options and inspect its whole-cache purge callback. Shared settings mappings are not available.
Inspect Swift Performance option rows and its whole-cache purge callback. Check native keys against the installed edition.
Inspect Swift Performance Lite using its own detected edition. Shared option storage does not establish support for paid features.
Inspect Super Page Cache for Cloudflare local options and its purge callback. Verify edge-cache state in Cloudflare after a change.
Inspect Converter for Media options for WebP and AVIF delivery. It converts images; it is not a page-cache or purge driver.
What plugin-aware prevents
Caching is stacked, not singular, and the layers do not know about each other. An asset optimiser sits in front of a page cache, a CDN sits in front of both, and an object cache sits underneath. Purge one and the site serves a mix of old and new markup, which reads as a failed write rather than a stale cache. The second trap is quieter: a setting can be written, read back correctly, report success, and still do nothing, because whatever would carry it out lives outside WordPress - a host with no rewrite file, an edge that is not caching HTML, a next-gen image setting with no converter producing the files.
How to check the work: In a browser, not on a settings screen. A write that reports success cannot see that the header logo is now a transparent placeholder, that a combined stylesheet returns a 404, or that deferring JavaScript stopped the menu opening. Core Web Vitals do not exist until a browser renders, so LCP and CLS come from the rendered page, and the request timings say whether an above-the-fold image started downloading late.
Read the cache ability referenceShared operating model
The Pro module extends WPPilot Free; it does not replace authentication, WordPress permissions, safety profiles, per-ability controls, confirmation, change evidence, or human judgment.
Detect every layer first, then take a baseline before touching anything: purge, warm, and measure, in that order, because measuring straight after a purge times WordPress building the page rather than the cache serving it. Then change one setting, repeat the loop, and keep it or roll it back. A batch of changes with one check at the end tells you nothing about which one did the damage.
Use a dedicated credential and the smallest useful safety profile.
Confirm setup health, discover abilities, and read the exact input schema.
Check the native plugin UI, rendered site, and external providers that matter.
Common questions
If your question is about a specific plugin rather than the category, its module page has the capability map and the boundary notes.
Almost always a cache rather than a failed write. Confirm the database actually changed by reading the post back; if it did, a page cache is still serving HTML built before the edit. Purging one layer is not enough on a stacked site, which is why the purge here reaches every detected layer at once and reports which entry point it called for each.
Those are gated. Combining CSS or JavaScript, critical CSS, unused-CSS removal, deferring JavaScript and caching for logged-in users are refused without an explicit confirmation, and the refusal names which keys it stopped. They are the settings that most often break a site while leaving the settings screen looking perfectly correct.
It never invents one. Server-side measurement reports time to first byte, whether the cache answered HIT or MISS, HTML weight, and how many stylesheets and scripts block the first paint. LCP, CLS and INP do not exist until a browser renders, so those come from a real browser, along with the PageSpeed report itself - no API key involved.
Then it says so, and says whose job it is. A host with no rewrite file makes browser-cache headers and WebP delivery inert while both still read back as enabled; an edge reporting DYNAMIC for the HTML means every visitor reaches the origin however well the page cache performs. Each of those comes back with which settings it silently neutralises and the steps for whoever owns that panel.
Driver comparison
26 detected layers; 10 shared settings maps. Purge candidates are entry points in the source, not proof that a callback exists on your installed version.
| Plugin | Layer | Mapped keys | Purge candidates |
|---|---|---|---|
| LiteSpeed Cache | page | 23 | all, url, post |
| WP Rocket | page | 24 | all, url, post |
| WP Fastest Cache | page | 11 | all, url, post |
| Speed Optimizer (SiteGround) | page | 12 | all, url |
| WP-Optimize | page | 14 | all, url, post |
| W3 Total Cache | page | 8 | all, url, post |
| Autoptimize | asset | 8 | all |
| SpeedyCache | page | 6 | all, url, post |
| Breeze | page | 12 | all |
| Cache Enabler | page | 3 | all, url, post |
| Perfmatters | asset | Native options only | None declared |
| FlyingPress | page | Native options only | all, url |
| WP Super Cache | page | Native options only | all, url, post |
| Redis Object Cache | object | Native options only | all |
| Jetpack Boost | page | Native options only | all |
| Aruba HiSpeed Cache | page | Native options only | None declared |
| NitroPack | page | Native options only | all, url |
| Hummingbird | page | Native options only | all |
| 10Web Booster | page | Native options only | None declared |
| Docket Cache | object | Native options only | all |
| SQLite Object Cache | object | Native options only | all |
| Powered Cache | page | Native options only | all |
| Swift Performance | page | Native options only | all |
| Swift Performance Lite | page | Native options only | all |
| Super Page Cache for Cloudflare | edge | Native options only | all |
| Converter for Media | asset | Native options only | None declared |
A changed heading can be saved in WordPress while an older copy remains in a page cache or CDN. Re-read the post first, identify the stale layer, then use the available purge route. Check the affected URL as a logged-out visitor afterward. A cache flush does not establish a speed improvement.
Your site · your policy · your AI client
Start with the Free MCP foundation, then use the LiteSpeed Cache, WP Rocket, WP Fastest Cache, Speed Optimizer (SiteGround), WP-Optimize, W3 Total Cache, Autoptimize, SpeedyCache, Breeze, Cache Enabler, Perfmatters, FlyingPress, WP Super Cache, Redis Object Cache, Jetpack Boost, Aruba HiSpeed Cache, NitroPack, Hummingbird, 10Web Booster, Docket Cache, SQLite Object Cache, Powered Cache, Swift Performance, Swift Performance Lite, Super Page Cache for Cloudflare, Converter for Media modules when your installed stack needs plugin-native depth.