Title: LMS-Advisor AI Powered Cache
Author: wpvishavjeet
Published: <strong>August 18, 2026</strong>
Last modified: August 18, 2026

---

Search plugins

![](https://ps.w.org/lmsadvisor-ai-powered-cache/assets/banner-772x250.png?rev=3652222)

![](https://ps.w.org/lmsadvisor-ai-powered-cache/assets/icon-256x256.png?rev=3652222)

# LMS-Advisor AI Powered Cache

 By [wpvishavjeet](https://profiles.wordpress.org/wpvishavjeet/)

[Download](https://downloads.wordpress.org/plugin/lmsadvisor-ai-powered-cache.1.0.1.zip)

 * [Details](https://wordpress.org/plugins/lmsadvisor-ai-powered-cache/#description)
 * [Reviews](https://wordpress.org/plugins/lmsadvisor-ai-powered-cache/#reviews)
 *  [Installation](https://wordpress.org/plugins/lmsadvisor-ai-powered-cache/#installation)
 * [Development](https://wordpress.org/plugins/lmsadvisor-ai-powered-cache/#developers)

 [Support](https://wordpress.org/support/plugin/lmsadvisor-ai-powered-cache/)

## Description

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:

    ```
    wp lmsa-cache clear
    wp lmsa-cache clear --url=https://example.com/hello-world/
    wp lmsa-cache clear --post=42
    wp lmsa-cache preload
    wp lmsa-cache status --format=json
    ```

REST API (authenticated, requires the manage_options capability):

    ```
    POST /wp-json/lmsa-cache/v1/purge
    GET  /wp-json/lmsa-cache/v1/status
    ```

#### 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.

## Screenshots

[[

[[

[[

[[

[[

## Installation

 1. Upload the `lmsadvisor-ai-powered-cache` folder to `/wp-content/plugins/`, or install
    it through the Plugins screen.
 2. Activate the plugin. Caching is switched on and configured for your server automatically,
    and the setup wizard opens so you can review what was done.
 3. If rewrite rules could not be used, add `define( 'WP_CACHE', true );` to `wp-config.
    php`, just below the opening `<?php` tag. WordPress will not load any caching drop-
    in without it, and this plugin does not edit that file for you. The admin screen
    tells you when this is needed and shows the exact line.
 4. Open **AI Powered Cache  Tools** and press **Test cache delivery**. It requests
    your home page twice and reports whether the cache is actually being served. Do
    this before measuring anything with PageSpeed Insights or GTmetrix.
 5. You can re-run the wizard at any time from **AI Powered Cache  Tools**, and every
    settings tab has a reset link.

Do not run two page caching plugins at once. Deactivate WP Rocket, W3 Total Cache,
WP Super Cache, LiteSpeed Cache, WP Fastest Cache or any similar plugin before enabling
this one.

## FAQ

### Does this send my data anywhere?

Not unless you deliberately turn on the AI assistant. Everything else — page caching,
adaptive lifetimes, preloading, all the Core Web Vitals work — runs entirely on 
your own server and makes no external request.

If you do enable the assistant, pressing Analyse sends a technical profile of your
site to whichever AI provider you configured in WordPress, through the WordPress
AI Client. You can read the exact payload on screen before consenting. Nothing is
sent on a schedule, in the background, or without a click.

### What exactly does the assistant send?

Server and PHP capabilities, your active plugin and theme names and versions, this
plugin’s own settings, the cache statistics it collected locally, and an inventory
of the CSS, JS and images on one page you choose — described by path, size and loading
attributes.

It does not send post content, pages, users, comments, orders, form submissions,
email addresses, IP addresses, or any data belonging to another plugin. The profiler
is an allow-list of named facts, not a scrape.

### Do I need an API key to use this plugin?

No, and this plugin never asks you for one. Every caching and optimization feature
works without any AI at all. The assistant is an optional extra that reuses the 
AI provider you have already set up for your site in WordPress.

### What does “AI” mean in this plugin?

Two distinct things, and the plugin is careful not to blur them.

The built-in optimizer is applied statistics running locally: moving averages to
track how fast each page changes, z-scores to find unusually popular pages, logistic
scoring to rank preload priority. A real model trained on your traffic — but not
a language model, and it does not pretend to be one.

The assistant is a large language model, reached through the WordPress AI Client
using the provider configured for your site. It reads the profile of your site and
reasons about it the way an experienced performance engineer would.

### Can the AI change my settings without asking?

No. It returns recommendations; each one shows exactly which setting would change,
from what value to what value, with an Apply button you press. Only settings on 
an internal allow-list can be applied at all, and a proposed value is re-validated
against the same schema that guards the settings form before it is written.

Some settings are deliberately excluded from that list — caching for logged-in visitors,
the server delivery method, and every exclusion rule — because getting them wrong
breaks a site in ways an automated suggestion should not risk. Every applied change
is logged with its previous value and can be undone in one click.

### Where is my API key stored?

Nowhere in this plugin. Credentials for AI providers are handled by WordPress itself
through the core AI Client, so there is no key for this plugin to store, encrypt,
leak or export. You configure a provider once for the whole site and every plugin
that uses the AI Client shares it.

### Do I have to edit wp-config.php?

Only if you choose the PHP drop-in delivery method, and only to add one line. WordPress
will not load any caching drop-in unless `WP_CACHE` is defined, and this plugin 
does not edit wp-config.php for you — it is your configuration file, it is read-
only on many hosts, and a plugin rewriting it is a good way to break a site. The
Caching tab shows the exact line and tells you whether the constant is already set.
The Apache and Nginx delivery methods do not need it.

### I installed it and my PageSpeed score did not change. Why?

Work through these in order.

First, press **Test cache delivery** on the Tools tab. It tells you whether cached
pages are reaching visitors at all. The most common cause of “no change” is that
pages are being cached correctly and nothing is serving them — usually because `
WP_CACHE` is missing from `wp-config.php` and rewrite rules were not available.

Second, remember what a page cache does. It removes PHP and database work from the
response, which improves your server response time and, through it, part of LCP.
It does not change how large your images are, how much CSS blocks rendering, or 
how much JavaScript runs on the main thread — and those are what dominate a Lighthouse
score. A cache is necessary for a fast site; on its own it is rarely worth thirty
points.

Third, make sure the URL you are testing is warm. A cold URL is measured on the 
slow path, where the plugin is doing extra work rather than saving it. Preloading
is on by default for this reason; give it a few minutes after activation, or run
it manually from the Preload tab.

Finally, look at the Dashboard’s recommendations panel. It names the specific things
your site is doing that cost you points, with the evidence, and several of them 
are settings this plugin ships switched off on purpose.

### GTmetrix gives me an F on “Add Expires headers” or “Compress components with gzip”.

Those two are the plugin’s job and it should fix them, so if they are still failing,
check in this order.

Open **AI Powered Cache  Tools** and look at **Server capabilities**. Expires headers
need `mod_expires` and compression needs `mod_deflate` or `mod_brotli`. If a module
is not loaded, no plugin can supply it — only your host can enable it. On a default
XAMPP install `mod_expires` and `mod_headers` are frequently commented out in `httpd.
conf`.

If the modules are present, confirm the rules were written. The plugin writes them
on activation and whenever you save settings, but only when `.htaccess` is writable.
The Caching tab reports whether it is, and offers a Write rules button. On Nginx
nothing can be written automatically — the Caching tab shows the block to paste 
into your server configuration.

### GTmetrix gives me an F on “Use cookie-free domains” or a low grade on “Reduce DNS lookups”. Can the plugin fix those?

Not on its own, and it would be dishonest to imply otherwise.

**Cookie-free domains** means serving static files from a hostname that your cookies
are not scoped to. That requires a second hostname, which means a CDN or a subdomain
you control — there is nothing a plugin can do from inside one domain. Configure
the CDN tab with a CDN hostname and this grade resolves itself.

**Reduce DNS lookups** counts the distinct domains a page contacts. Every one comes
from your theme, your other plugins, or an embed — Google Fonts, an analytics script,
a chat widget, an embedded video. The plugin already removes one (the emoji script’s`
s.w.org` lookup) and adds preconnect hints so the remaining lookups start earlier,
but the only real fix is to use fewer third-party services or self-host the ones
you keep.

Both of these are YSlow rules from an era of HTTP/1.1 and domain sharding. They 
are worth knowing about, but a modern Lighthouse or Core Web Vitals score — which
is what search ranking actually uses — weighs neither of them.

### Why is my hit rate low?

Check the “Why requests bypassed the cache” panel on the Dashboard. The most common
causes are logged-in traffic, query strings on inbound links, and exclusion rules
that are broader than intended. The Dashboard names the exact reason and how many
times it occurred.

### Can I cache pages for logged-in users?

Yes, but leave it off unless every logged-in visitor sees identical markup. On a
membership site, a shop, or anything with a personalised header, enabling it will
show one member’s page to another.

### Which delivery method should I use?

Leave it on automatic. Rewrite rules are fastest because the web server answers 
without loading PHP at all; the PHP drop-in is the universal fallback and still 
skips your theme and plugins.

### Does it work with Elementor and Divi?

Yes, by design. Editing sessions for all major builders are detected by their URL
signatures and never cached — this guard runs before every user setting, so it cannot
be misconfigured away. Saving a layout or regenerating builder CSS purges the affected
pages automatically. If you enable JavaScript delay, the builders’ front-end runtime
scripts are protected by default so sliders, animations and responsive behaviour
work immediately, before any interaction.

### Will this actually improve my Core Web Vitals?

The features map one-to-one onto the field metrics: hero-image preloading and lazy-
load correction target LCP, dimension injection targets CLS, and JavaScript delay
targets INP and blocking time. What you gain depends on what your site currently
does wrong — a theme that lazy-loads its hero image will see a large LCP gain from
the fix; a site that already does everything right will see less. The Dashboard’s
recommendations panel tells you which of these apply to your site, with the evidence.

### Does it work with WooCommerce?

Cart, checkout and account pages are excluded by default through their cookies, 
and product pages are invalidated automatically when stock or stock status changes.

### Does it work on multisite?

Yes. Settings, statistics and cache entries are per-site, and network activation
initialises each site.

### What happens if I deactivate it?

The rewrite rules and the drop-in are removed and generated files are deleted, so
the site keeps working normally. A `WP_CACHE` line you added to wp-config.php is
left alone — the plugin never writes to that file — and it is harmless once there
is no drop-in for it to load. Your settings and statistics are kept in case you 
reactivate. Deleting the plugin removes everything.

## Reviews

There are no reviews for this plugin.

## Contributors & Developers

“LMS-Advisor AI Powered Cache” is open source software. The following people have
contributed to this plugin.

Contributors

 *   [ wpvishavjeet ](https://profiles.wordpress.org/wpvishavjeet/)

[Translate “LMS-Advisor AI Powered Cache” into your language.](https://translate.wordpress.org/projects/wp-plugins/lmsadvisor-ai-powered-cache)

### Interested in development?

[Browse the code](https://plugins.trac.wordpress.org/browser/lmsadvisor-ai-powered-cache/),
check out the [SVN repository](https://plugins.svn.wordpress.org/lmsadvisor-ai-powered-cache/),
or subscribe to the [development log](https://plugins.trac.wordpress.org/log/lmsadvisor-ai-powered-cache/)
by [RSS](https://plugins.trac.wordpress.org/log/lmsadvisor-ai-powered-cache/?limit=100&mode=stop_on_copy&format=rss).

## Changelog

#### 1.0.1

Delivery and defaults. The plugin now configures itself on activation instead of
installing inert, and several bugs that stopped cached pages ever reaching visitors
are fixed.

 * Caching, HTML/CSS/JS minification, CSS combining, native lazy loading and preloading
   are enabled by default. Activation installs the drop-in, writes the server rules
   and queues a preload run.
 * The setup wizard opens on every activation, and a **Test cache delivery** button
   on the Tools tab proves whether cached pages are genuinely being served.
 * Fixed: rewrite rules used the WordPress home path where the document root was
   required, so the cache was never served on any site installed in a subdirectory.
 * Fixed: rules matched `%{HTTP_HOST}`, which retains the port, against cache directories
   named after the bare hostname — a permanent miss on any non-default port.
 * Fixed: the HTTPS variant suffix was applied unconditionally, so plain-HTTP sites
   looked for a file that was never written.
 * Fixed: the query-string guard used a no-op rewrite flag, so cached pages could
   be served to URLs carrying a query string.
 * Fixed: HTTPS detection combined `[OR]` conditions with later `AND` conditions,
   which could fire a rewrite without confirming the cache file existed.
 * Fixed: browser caching and compression rules were only written when page caching
   was active, so a site could report no Expires header while the setting read as
   enabled. They are now written on any Apache-family server, independently of page
   caching, alongside Brotli support and a wider set of media types.
 * Fixed: request URIs were run through a sanitizer that strips percent-encoded 
   characters, breaking every non-ASCII URL. Path segments that cannot be represented
   literally now carry a digest, so two different non-Latin slugs can no longer 
   collide onto one cache file.
 * Fixed: any page containing a `_wpnonce` field was refused, which silently disabled
   caching on sites with a contact or search form. Only forms posting to login and
   administrative endpoints are excluded now.
 * Fixed: JavaScript minification skipped every handle enqueued in the footer, which
   is nearly all of it.
 * Fixed: LCP prioritisation, image dimension injection, font display-swap and lazy
   loading only ran on cacheable requests, so they did nothing on pages that could
   not be cached.
 * Fixed: expired entries could never be removed on a fully cached site, because
   the cleanup task depends on WP-Cron and no request reached PHP to trigger it.
 * Bypasses now record the specific rule that caused them instead of an empty reason.
 * Renamed to LMS-Advisor AI Powered Cache.

#### 1.0.0

 * Initial release.

## Meta

 *  Version **1.0.1**
 *  Last updated **13 hours ago**
 *  Active installations **Fewer than 10**
 *  WordPress version ** 6.0 or higher **
 *  Tested up to **7.0.4**
 *  PHP version ** 7.4 or higher **
 * Tags
 * [cache](https://wordpress.org/plugins/tags/cache/)[core web vitals](https://wordpress.org/plugins/tags/core-web-vitals/)
   [optimization](https://wordpress.org/plugins/tags/optimization/)[page cache](https://wordpress.org/plugins/tags/page-cache/)
   [performance](https://wordpress.org/plugins/tags/performance/)
 *  [Advanced View](https://wordpress.org/plugins/lmsadvisor-ai-powered-cache/advanced/)

## Ratings

No reviews have been submitted yet.

[Your review](https://wordpress.org/support/plugin/lmsadvisor-ai-powered-cache/reviews/#new-post)

[See all reviews](https://wordpress.org/support/plugin/lmsadvisor-ai-powered-cache/reviews/)

## Contributors

 *   [ wpvishavjeet ](https://profiles.wordpress.org/wpvishavjeet/)

## Support

Got something to say? Need help?

 [View support forum](https://wordpress.org/support/plugin/lmsadvisor-ai-powered-cache/)