LMS-Advisor AI Powered Cache

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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.