Caching and page speedPro
LiteSpeed Cache MCP: server-side caching an AI agent can tune and prove
With LiteSpeed Cache MCP access through GoBuildWP Pro, an AI agent works on a cache that lives in the web server rather than in wp-content. It saves settings through the plugin's documented configuration hook, purges the whole site, one URL or one post, starts the crawler, and then fetches the page to see whether the x-litespeed-cache response header says hit. The proof comes from the response, never from the settings screen.
GoBuildWP Pro eligibility is separate from the LiteSpeed Cache plugin and supported cache-server prerequisites.
litespeed- Layer
- page
- Declared purge scopes
allurlpost- Shared keys
- 22
- Detected by
- constant LSCWP_V
Installed class, method or listener checks and per-layer results determine whether a purge ran. Neither a declaration nor a returned ran flag proves public freshness.
- Edition
- Pro
- Abilities
- 16
- Requires
- WordPress 6.9+, PHP 8.0+
Before changing cache settings, inspect captured drivers and not_captured. After reverting, inspect restored, deleted, not_restored, verified and purged_layers. Use a separate cache-purge result when you need details for each layer. Storage verification checks captured values; it does not establish functional recovery or public freshness. Revert may overwrite later settings, and vendor configuration regeneration or a re-save can still be required.
Check each measurement run’s fetched_via before treating it as public-path evidence. cache-verify-in-browser supplies checks and does not operate a browser. Automatic purge coalesces targets within the request and runs on shutdown; it is not necessarily one immediate flush per call. Verify generated files, object/page/edge caches and actual visitor behavior separately.
Abilities
The cache abilities against a LiteSpeed server
| Ability | What it does here | Undo and limits |
|---|---|---|
cache-check-setupcache-measure-pagecache-warm | Detection keys off the LSCWP_V constant. The measurement requests a URL from the server itself and records x-litespeed-cache next to time to first byte, so a warmed page can report a hit. A miss after warming has several possible causes, including the server type, an exclusion, a cookie or query string that bypasses the cache, or a setting; check each before blaming one. | Nothing here changes settings; cache-warm requests pages, which can fill the cache. x-litespeed-cache comes from a LiteSpeed web server or from QUIC.cloud in front of the site, so on a plain Apache or Nginx origin with no QUIC.cloud it will not appear, and no plugin option can add it. |
cache-get-settingscache-set-settings | Shared keys land on LiteSpeed ids: page_cache.ttl on cache-ttl_pub, css.unused_css_removal on optm-ucss, images.next_gen on img_optm-webp, preload.enabled on crawler. JavaScript delay is left unmapped because LiteSpeed folds it into the defer selector and stores an include list, the reverse of an exclusion list. | Logged-in caching, both combine switches, critical CSS, unused CSS, defer and the CDN switch refuse to write without confirm. Each write is recorded with the affected litespeed.conf rows, so rollback-change restores them. |
cache-set-native | Guest mode, ESI, the crawler schedule and per-asset exclusions have no shared name, so they are written by LiteSpeed id after include_native has shown the current value. | Confirmation is mandatory and carries no risk tier. The ledger adds the row the key lives in, so the undo covers it. |
cache-list-presetscache-apply-preset | Every key in all three presets has a LiteSpeed equivalent, so nothing is skipped here. Aggressive brings combining, critical CSS and defer with it. | Aggressive needs confirm. A preset is one ledger entry, and rolling it back reverts the whole set together. |
cache-purgecache-list-actionscache-run-action | Purge fires litespeed_purge_all, litespeed_purge_url or litespeed_purge_post, each only after has_action confirms LiteSpeed is listening. The single action is the crawler, started through LiteSpeed\Crawler::start() and run inline. | No state to undo. The crawler must be enabled and allowed by the server, and a reply of ran with no sitemap behind it means nothing was crawled. |
cache-verify-in-browsercache-begin-experimentcache-revert-experiment | The browser check reports when a LiteSpeed or Apache server has no .htaccess in the WordPress root, where browser-cache headers and WebP delivery read as enabled and do nothing. An experiment captures every litespeed.conf row plus any optimiser stacked in front. | Revert needs confirm and writes rows back directly; save LiteSpeed's settings screen once afterwards so its generated rules match. |
Reference: /docs/reference/cache
Shared cache module; do not add this count across drivers. Edition and effect labels describe the source catalogue. The installed schema, dependency versions, licence, WordPress capability, safety profile and per-ability policy determine availability; labels alone do not prove confirmation or recovery.
Worked example
Defer scripts, then prove the cache still answers
Expected outcome to verify on the installed stack; this sequence has not been recorded as a runtime test.
A deferred homepage with before and after figures taken the same way. A new console error means rollback-change on that write puts optm-js_defer back. A missing HIT does not prove the server is not LiteSpeed. Check cache eligibility, bypass rules, headers and delivery topology before diagnosing the layer.
After revert, re-save through the native plugin where required and inspect derived server rules. Verify expected content and actual visitor interactions separately from a cache HIT.
Defer JavaScript on the homepage, but keep it only if nothing breaks and LiteSpeed is still serving it from cache.
wppilot/cache-begin-experimentWriteReturns an experiment id holding every litespeed.conf row as it stands.
wppilot/cache-measure-pageReadBaseline: time to first byte over repeated requests, the x-litespeed-cache value and the count of head scripts.
wppilot/cache-set-settingsWriteAfter the owner approves, js.defer is sent with confirm, written to optm-js_defer through litespeed_save_conf, and the page cache is purged.
wppilot/cache-warmWriteRequests the homepage again and reports whether that response came back as a hit.
wppilot/cache-verify-in-browserReadHands back console and typeof jQuery checks to run in an open browser, the likeliest casualties of defer.
A suggested sequence from the ability reference, not a recorded run.
Data model
Option rows in WordPress, cached pages in the server
Every LiteSpeed setting is its own option row, named litespeed.conf. followed by the setting id, so the public page lifetime is litespeed.conf.cache-ttl_pub and JavaScript defer is litespeed.conf.optm-js_defer. GoBuildWP takes those ids from the plugin's Base class constants rather than from documentation, and reads each one through the litespeed_conf filter; an id this install does not answer for comes back as unsupported instead of being written anyway.
The pages are somewhere else entirely. LiteSpeed's FAQ says the server stores and manages cached pages and nothing lands in the WordPress file structure, which is why the page cache needs OpenLiteSpeed, LiteSpeed Enterprise, LiteSpeed-based hosting or QUIC.cloud, while CSS, JavaScript and image optimisation run on any server.
So an agent holds two very different things. The option rows can be snapshotted and put back. The cache can only be asked to empty itself, and whether the server is caching at all shows up in one place: the response headers.
Writes fire litespeed_save_conf with a batch of option ids, LiteSpeed's own save hook, so its validation runs and any .htaccess directives the change implies are regenerated exactly as a save from its settings screen would. If nothing is listening on that hook, GoBuildWP refuses the write rather than falling back to raw option updates.
Shared key → LiteSpeed Cache setting
page_cache.enabled → cachepage_cache.ttl → cache-ttl_pubpage_cache.mobile_separate → cache-mobilepage_cache.cache_logged_in → cache-privpage_cache.exclusions → cache-excbrowser_cache.enabled → cache-browserbrowser_cache.ttl → cache-ttl_browserobject_cache.enabled → objectcss.minify → optm-css_mincss.combine → optm-css_combcss.critical → optm-css_asynccss.unused_css_removal → optm-ucssjs.minify → optm-js_minjs.combine → optm-js_combjs.defer → optm-js_deferimages.lazyload → media-lazyimages.lazyload_iframes → media-iframe_lazyimages.dimensions → media-add_missing_sizesimages.next_gen → img_optm-webpfonts.display_swap → optm-css_font_displaycdn.enabled → cdnpreload.enabled → crawler
Option rows
litespeed.conf.cachelitespeed.conf.cache-ttl_publitespeed.conf.cache-mobilelitespeed.conf.cache-privlitespeed.conf.cache-exclitespeed.conf.cache-browserlitespeed.conf.cache-ttl_browserlitespeed.conf.objectlitespeed.conf.optm-css_minlitespeed.conf.optm-css_comblitespeed.conf.optm-css_asynclitespeed.conf.optm-ucsslitespeed.conf.optm-js_minlitespeed.conf.optm-js_comblitespeed.conf.optm-js_deferlitespeed.conf.media-lazylitespeed.conf.media-iframe_lazylitespeed.conf.media-add_missing_sizeslitespeed.conf.img_optm-webplitespeed.conf.optm-css_font_displaylitespeed.conf.cdnlitespeed.conf.crawler
Other plugins
Layers that sit beside LiteSpeed
- Autoptimize in front of LiteSpeed is a normal stack. cache-purge empties both in one call and reports each layer separately.
- Docket Cache's documentation asks for LiteSpeed's own object cache to be turned off when Docket supplies one; object_cache.enabled is the shared key that does it here.
- WP Rocket lists LiteSpeed Cache as incompatible, and Super Page Cache for Cloudflare works with LiteSpeed only when LiteSpeed's page cache is off.
Limits
What stays out of reach on LiteSpeed
- GoBuildWP never writes .htaccess itself; LiteSpeed does when its save hook runs. On OpenLiteSpeed, LiteSpeed's FAQ says changes that touch .htaccess need a server restart.
- No shared key covers JavaScript delay, CDN mapping rows, LCP preload, image exclusions or database clean-up. They stay in native keys or the plugin screen. fonts.host_locally reports unsupported as well: Localize Resources (optm-localize) only copies listed JavaScript files, Twitter and Facebook scripts by default, and LiteSpeed has no switch that serves Google Fonts from the site.
- A QUIC.cloud or Cloudflare edge in front of WordPress is not purged by cache-purge; check-setup lists it under edge layers and it needs its own purge.
- Settings writes are undoable; purges, warming and crawls change no stored state and are not.
Questions
LiteSpeed Cache questions
Does the LiteSpeed page cache work if my host runs Apache or Nginx?
LiteSpeed page caching needs a LiteSpeed server or eligible QUIC.cloud caching; asset and image optimisation can run on other servers. On Apache or Nginx without that cache layer, writing settings alone cannot create a LiteSpeed hit. Check the origin and edge topology and inspect the response headers before identifying which layer served a request.
Why can't the agent switch on LiteSpeed's JavaScript delay by name?
LiteSpeed stores delay as an include list folded into the defer selector, so mapping it onto the shared delay key would misreport defer. Read it with include_native and write it with cache-set-native, then check the page in a browser.
The agent reports the setting as applied but PageSpeed has not moved. Why?
Most often the page was not purged and warmed, an edge cache is still serving the old copy, or an OpenLiteSpeed vhost is ignoring .htaccess. cache-verify-in-browser names the last case under blocked_by_environment with steps for whoever runs the server.
Where these facts come from
GoBuildWP behaviour is taken from the plugin source and the ability reference; third-party details from the vendor documentation below, checked by the GoBuildWP team.
LiteSpeed Cache is a separate product; no partnership or endorsement is implied.