LMS-Advisor AI Powered Cache

LMS-Advisor AI Powered Cache stores a static HTML copy of each page so that repeat visitors are served straight from disk, skipping PHP and the database entirely.

What makes it different is that it does not ask you to guess at the numbers. It watches how your own site behaves — how often each URL is requested, how long each page takes to render, and how frequently its content changes — and uses that to work out how long each individual page should stay cached and which pages are worth warming first.

Working from the moment you activate it

Activation does the setup rather than asking you to. Page caching is switched on, the cache directories are created, the drop-in is installed if your wp-content allows it, the rewrite rules are written if your server supports them, and a preload run is queued so the first real visitor lands on a cached page. The safe optimizations — HTML minification, native lazy loading, LCP prioritisation, image dimension injection, font display-swap — are on as well.

The optimizations that can break a theme are not. CSS and JavaScript minification and combining, deferred JavaScript and delay-until-interaction all start switched off, and the setup wizard offers them one at a time with a plain description of what each one risks.

The wizard still opens after activation. It checks your server, tells you plainly what it found, and lets you change any of it — but if you close it and never come back, the plugin is already doing its job. There is also a Test cache delivery button on the Tools tab that requests your home page over HTTP and tells you whether cached pages are genuinely reaching visitors, rather than being written to disk and never used.

Changed your mind later? Every settings tab has a reset link that restores just that tab, and Tools has a full reset that returns everything to how it shipped. Both ask for confirmation first, and both tell you how many settings actually differ from the defaults before you commit.

Two kinds of intelligence, and an honest line between them

The optimizer runs entirely on your server. It needs no API key, no account, and makes no external request of any kind. It is a small set of well understood statistics — exponential moving averages, z-scores and logistic scoring — trained on counters stored in your own database. It records URL paths and counters only: no IP addresses, no cookie values, no visitor identifiers, and it transmits nothing anywhere. This is on by default and always will be.

The optional AI assistant does leave your server. It sends a technical profile of your site to an AI model and gets back a genuine diagnosis of what is slowing it down, with specific settings changes you can apply in one click.

That request goes through the AI Client built into WordPress 7.0, not through any integration of our own. The provider, the model and the credentials are whatever you configured once for your site; this plugin stores no API key, is tied to no particular vendor, and sends nothing to us. On WordPress versions without the AI Client this tab is simply inert — every caching and optimization feature works regardless.

The assistant is off until you switch it on, and will not run until you have separately confirmed consent. The settings screen shows you the exact payload — the complete text, not a summary — before anything is sent. See the Privacy section for what is and is not included.

Page caching

• Static HTML page cache with pre-compressed gzip copies
• Three delivery methods, auto-detected: Apache/LiteSpeed rewrite rules, Nginx rules, and a universal PHP drop-in
• Separate variants for mobile and HTTPS where your theme needs them
• Conditional request support, so returning browsers get a 304 instead of a full page
• Targeted invalidation: editing a post clears that post plus its archives, author page, date archives and adjacent posts — not your entire site

Adaptive optimization

• Per-URL cache lifetimes derived from measured traffic and measured rate of change
• Pages with a detectable rhythm of change expire just before they typically go stale
• Expensive pages are kept longer, because regenerating them costs the most
• Preload queue ordered by expected value, so high-traffic and slow-rendering pages are warm first
• A recommendations panel that explains what to change and shows the evidence behind each suggestion

Core Web Vitals, addressed directly

• LCP — the likely hero image is identified server-side at cache time, stripped of any lazy loading and given fetchpriority=”high”, so the browser starts fetching it while it is still parsing the HTML instead of after layout.
• CLS — local images missing width and height get their real dimensions measured on disk and written into the markup, so space is reserved and nothing jumps.
• INP — JavaScript can be delayed until the first real interaction, with an order-preserving sequential restore and a timeout so idle visitors still get full functionality. Or simply deferred, so parsing never stops for a download.
• Fonts — display=swap keeps text visible while webfonts load, and preconnect hints are contributed through WordPress’s own resource-hints API.
• Stale-while-revalidate — when a page has just expired, the expired copy is served instantly and the path is queued for a background rebuild, so a visitor arriving in the grace window gets an immediate response instead of waiting for a full render.

All of this analysis happens once, when the page is cached. Visitors are served the finished result.

Page builders are first-class citizens

Elementor, Divi, Beaver Builder, Oxygen, Bricks, Brizy, WPBakery, Visual Composer, Thrive, Cornerstone, Flatsome and SiteOrigin editing sessions are detected and never cached — the guard runs before any user setting, so no configuration can accidentally cache an editor screen. When a builder saves a layout or regenerates its CSS, the page cache is purged in step. Builder runtime scripts are shielded from JavaScript delay by default, so above-the-fold sliders and animations keep working.

Asset optimization

• HTML minification that leaves pre, textarea, script, style and SVG blocks untouched
• CSS minification and combining through the WordPress dependency API, with url() references rebased correctly
• Conservative JavaScript minification and combining that never merges a handle carrying inline code, localized data, a loading strategy or a conditional comment
• Native lazy loading for images and iframes, with no JavaScript added
• CDN URL rewriting, including srcset
• Browser caching headers for static assets
• Optional removal of the emoji script and version query strings

Preloading

Preloading runs through WP-Cron in small batches with a configurable pace, so it never blocks your admin session and never floods a shared host.

Automation

WP-CLI:

REST API (authenticated, requires the manage_options capability):

For developers

Filters: lmsa_cache_is_cacheable, lmsa_cache_ttl, lmsa_cache_variant_parts, lmsa_cache_related_urls, lmsa_cache_preload_urls, lmsa_cache_allowed_hosts, lmsa_cache_pre_optimize, lmsa_cache_post_optimize, lmsa_cache_recommendations

Actions: lmsa_cache_loaded, lmsa_cache_page_stored, lmsa_cache_purged_all, lmsa_cache_purged_post, lmsa_cache_model_trained, lmsa_cache_settings_saved

To skip caching for a request from your own code, define DONOTCACHEPAGE, return false from lmsa_cache_is_cacheable, or emit <!--lmsa-cache-skip--> anywhere in the page.

Privacy

Default behaviour: nothing leaves your server

With the AI assistant switched off — which is how the plugin ships — this plugin contacts no external service and transmits no data anywhere.

Optional AI analysis

The AI assistant is an opt-in feature that requires you to switch it on, tick a separate consent box, and have an AI provider configured for your site in WordPress. Until all three are true, no request is made.

Requests are made by the WordPress core AI Client, not by this plugin. Which company receives them, and under what terms, is determined entirely by the provider you configured in WordPress — this plugin has no provider of its own and no way to send your data anywhere else.

When you press Analyse, the following is handed to the AI Client:

• server software, PHP version, WordPress version, memory limit, and which optional PHP extensions are present
• the names and version numbers of your active plugins and theme
• this plugin’s own settings
• cache statistics this plugin collected locally: hit and miss counts, bypass reasons, and per-path request counts and average generation times
• for one page you nominate: its HTML size, and an inventory of its stylesheets, scripts and images described by path, file size and loading attributes
• the hostnames of any third-party resources that page references

The following is never sent: post or page content, user accounts, usernames, email addresses, comments, orders, form submissions, IP addresses, cookies or cookie values, and any data belonging to another plugin. The profiler collects a fixed list of named facts and does not read anything else.

You can display the complete payload for your own site, verbatim, on the AI Assistant tab before enabling anything.

How that data is then handled is governed by the terms and privacy policy of the AI provider you configured in WordPress.

Switching the assistant off stops all external communication immediately. Uninstalling the plugin deletes the stored report, the change log and the usage counters.

Data stored locally

When statistics collection is enabled (on by default, and switchable off under Tools), the plugin records the following in wp-content/cache/lmsa-cache/ai/statistics.json, which is protected from direct web access:

• URL paths that were requested
• Counts of cache hits, misses and bypasses per path
• Average page generation time and response size per path
• How often each path was invalidated

It does not record IP addresses, user agents, cookie values, usernames, user IDs, referrers, or any request or response body. Cookie names are compared against your exclusion list to decide whether a request may be cached; cookie values are never read.

Enabling the optional diagnostic log adds a plain-text log under wp-content/cache/lmsa-cache/logs/, also protected from direct web access. It records cache decisions and purge events only, and is off by default.

All of this data is deleted when the plugin is uninstalled.

Can I undo my settings?

Yes, at two levels. Each settings tab shows a reset link when at least one of its settings differs from the shipped default, and that link restores only that tab. Tools has a full reset that restores everything. Neither touches your collected statistics or the trained model — those have their own reset button.

After a full reset, page caching returns to being switched off, exactly as on a fresh install, so nothing continues to be served from a configuration you have just discarded.

Can I run the setup wizard again?

Yes, from AI Powered Cache → Tools. It starts from your current settings rather than from defaults, so walking through it changes nothing unless you actually change an answer.