Concepts, settings, and screens — explained.

WordPress loads every active plugin on every request, regardless of whether that plugin has anything to do on the page being requested. Accelerator changes that. It looks at what the request is — a public page view, an admin page, a REST call, a cron run — and only loads the plugins that actually need to be there.

It is not a cache plugin. Caches store responses and serve them again. Accelerator changes how the work itself is done, so the work is cheaper. The two compose well: most sites benefit from running a cache plugin alongside it.

Beyond plugin loading, the premium tier batches database writes, removes duplicate reads inside a single request, and moves WordPress's scheduled task runner off the visitor's page-load path. The full feature list is on the homepage; everything else on this page is the "how do I read what I see" reference.

The first wizard step asks how detailed you want the rest of the wizard to be. The choice you make affects two things:

• How much explanation each step carries. The simpler paths are leaner; the developer path includes raw controls.
• Which optional steps appear. The Developer path adds an extra step for hand-crafting per-page rules during setup.

You can change this any time by re-running the wizard from the License page or the Welcome screen. None of your earlier answers are lost — they are reused as the starting point.

The fastest way through. The wizard skips optional steps and accepts the recommended default at every choice. Best for site owners who do not want to think about plugin internals — you trust the rule library to make sensible choices and you just want the result.

You still see the final summary before anything is saved. You can always re-run the wizard later and pick a more detailed path if you want to look under the hood.

Recommended for most users. Each step shows the same recommendation as the simple path, plus a plain-language explanation of why the wizard is suggesting it and what it will change. The number of clicks is roughly the same — you just see what is being decided.

Pick this if you want to know what the plugin is doing without reading source code or documentation between every click.

Unlocks an additional optional step in the wizard for hand-crafting per-page URL rules during initial setup, and exposes raw match-mode controls on the Per-Page Rules admin screen — exact-match, anchor-style URL syntax, and individual admin-ajax action filtering instead of whole-plugin offloads.

These are sharp tools. The default wizard rules cover the cases most sites need; reach for the developer path only when you have a specific scenario the simple rules cannot express.

An optional checkbox at the end of the welcome step. If you tick it, once a day the plugin sends the names and versions of the plugins active on this site to the rule library, plus the WordPress version, locale, and the site type you picked.

Never sent: page URLs, post content, user accounts, email addresses, IP addresses, license key, or anything visitor-facing.

Why it helps: when many sites running the same plugin all benefit from the same rule, that rule moves into the public rule library so future sites get it automatically. The setting is off by default and you can turn it off any time on the Telemetry page.

The Summary card at the top of the Telemetry page is a snapshot of every request the plugin recorded inside the chosen time window. It counts requests and reports how long they took at three percentiles — typical (p50), slow (p95), and worst-case (p99) — plus the average and the largest amount of memory any single request used.

Read it together with the Window selector above it: the same numbers will look very different on a 1-hour window during a quiet morning vs. a 7-day window that includes a weekend traffic spike.

Total number of requests recorded in the chosen window. This includes everything WordPress runs through: frontend page views, REST API calls, admin pages, admin-ajax, and background cron jobs.

Use the Breakdown by request type section further down the page to see how this total splits across those kinds. Most sites are dominated by a single category — usually frontend page views or admin-ajax — and the optimisation strategy follows whichever is biggest.

The median request time. Half of all requests in the window finished faster than this; half took longer. It is the single best number for the question "what does a typical visitor experience?".

Watch how p50 moves over time more than its absolute value. A p50 that drops 30% after a wizard run is a real win. A p50 that quietly creeps up over weeks usually points to a plugin that has started doing more work — the next thing worth investigating.

The 95th percentile. 95% of requests finished faster than this number; 5% took longer. p95 catches slow outliers that p50 hides — these are the requests where users feel the site is sluggish, even though most page-loads were fine.

A healthy site usually keeps p95 within roughly 3–5× of p50. A p95 that is 10× or 20× of p50 means a long slow tail — often caused by uncached database queries, a single oversized post, or an admin-ajax endpoint that runs heavy logic on the public side.

The worst 1% of requests. Often dominated by cron sweeps, large WP_Query operations, or rare cache misses. A high p99 with a low p50 tells you most visitors are happy but the unlucky few have a bad time.

If p99 is wildly higher than p95, scroll down to Recent requests and sort by total time — the offenders are usually a small handful of URLs or a specific cron job, and once you spot them the fix is targeted rather than site-wide.

The arithmetic average across every request in the window. Useful for total compute and capacity planning, but easily skewed by outliers — a single 30-second cron run can lift the mean for the whole window even if every other request was fast.

For "typical visitor experience", prefer p50. For "does the slow tail matter?", prefer p95 and p99. Mean is the supporting actor in this section, not the lead.

The largest amount of PHP memory any single request consumed inside the window. A flat line is healthy. A persistent rise over weeks usually means a plugin is loading more on every request — a backup plugin scheduling more, an analytics SDK growing, an autoloader pulling in classes that used to be lazy.

Spikes you see once and never again are usually the WordPress updater or a one-shot import — safe to ignore. Sustained growth is the signal worth chasing down.

Picks the time range every other section on the Telemetry page reads from. A short window (1 hour) reflects what is happening right now and is sensitive to anomalies. Longer windows (24 hours, 7 days, 30 days) smooth out spikes and give a stable picture you can use to make decisions.

For day-to-day monitoring 24 hours is usually right. For tracking a change you just made, switch to 1 hour to see it land. For trends, 7 or 30 days.

Restricts the Summary, Breakdown, and Recent requests sections to URLs whose path matches a glob — for example /shop/* shows only requests under your shop, /wp-json/* shows only REST calls.

The Impact, Shadow Soak, and Shadow Counters sections deliberately stay site-wide regardless of the filter — those are global health signals and slicing them by URL would mislead.

Splits the total request count by the kind of work each request was: frontend page view, REST call, admin page, admin-ajax, cron run, and a few special variants. Three columns: how many of each, what share of the total, and the average time spent.

Most sites are dominated by one or two categories. If admin-ajax is 40%+ of your traffic and slow, the easiest performance win is usually targeted rules on those endpoints rather than chasing frontend gains.

The most recently measured requests, newest first. Each row shows the timestamp, request type, URL path, total time, peak memory, and which plugins were kept out of that specific request by your rules.

The Offloaded column is the spot-check for "is the rule actually firing?". If a rule should be skipping a plugin on a given URL but the column shows it is still loaded, something upstream is overriding the rule — usually a dependency safety vetoing the skip.

Every admin-ajax action seen inside the window, grouped and counted. Two columns matter: the number of times that action ran, and how many times any rule kept it from running.

Use this to find the chatty endpoints worth a rule. WordPress's built-in heartbeat and editor autosave are usually fine. Plugin-specific actions that fire dozens of times per page view are the ones to investigate — they often run on every admin screen for no good reason.

The Impact card is the answer to the question "is this plugin actually doing anything?". It compares the latest window of traffic against the same length of traffic immediately before it, and shows the percentage change at p50, p95, and p99.

A negative delta is a speedup — "p50 down 23%" means the median request is 23% faster than it was before. The card needs roughly 100 requests in each window to give a number worth trusting; until then it shows a "not enough data yet" message instead of guessing.

The card has two tabs (frontend visitors vs. admin & ajax). Read them separately — they have different performance profiles and combining them hides which side is improving.

The default tab. It scopes the comparison to real visitor page-loads only. Admin pages, REST polls, admin-ajax calls, and background cron jobs are excluded so a one-off spike in those lanes does not skew the visitor-facing number.

This is the tab to share when someone asks "by how much did the site speed up?". It answers that question honestly.

The other side of the story. Scopes the comparison to admin pages and admin-ajax calls, so you can see how the admin experience for editors, store managers, or you yourself is changing — independently of frontend.

Admin work is often where the biggest gains hide on heavy installs. A 50-plugin admin dashboard that drops 600 ms is a daily quality-of-life upgrade for every editor.

Some modules can run in "shadow" first: they measure exactly what they would have done, without changing anything yet. Shadow Soak is the observation period before flipping that module live. The Telemetry page's Shadow Soak section shows when each module has seen enough data to be turned live with confidence.

Why the wait? It catches a bad rule before production traffic feels it. If a wizard-generated rule would have skipped a plugin that a real page actually needed, you see that in the shadow numbers and can fix it before going live.

A per-module tally of the actions a shadow module would have taken. Three counters worth knowing:

• Sidecar shadow writes — rows the meta sidecar would have mirrored
• Sidecar shadow reads — meta queries the rewriter would have redirected to the sidecar table
• Skipper shadow would-be skips — plugin loads the skipper would have avoided

A non-zero number on a shadow module means it is observing real traffic. Zero usually means either no rule is configured for that module yet, or the traffic in the chosen window did not exercise it. Pair this with the Soak section to decide when to flip live.

Your license key is what proves to the licensing API that this site is allowed to run premium modules. The License page shows it masked — only the last four characters are visible, the rest is dots. The full key is stored on this server's filesystem; nothing else has a copy.

If you need the full key (to move the license to another site, for example), you can find it on your account page on for-wordpress.org. The plugin never displays the full key once it has been activated.

The date and time this site first activated against the licensing API. Re-activating after a deactivation updates this date — the plugin treats each activation as fresh.

Useful as a quick sanity check: if this date is older than you expect, someone activated the license here a while ago and the plugin has been quietly working since. If it is more recent than expected, you may have re-activated without remembering.

Once a day, the plugin asks the licensing API a single question: "is this license still valid?". The dashboard shows the most recent successful answer. This is the heartbeat.

Heartbeats never run on the visitor request path — your visitors never wait on a licensing call. If a heartbeat fails (network blip, API downtime), the plugin retries with a backoff for a grace period before downgrading to the free tier. A short outage will not break your site.

If "Last check-in" is more than a day or two old, scroll down to the "Check-in errors" section if it appears — it tells you what went wrong.

The date the license stops renewing. Premium modules continue running until this date even if heartbeats fail in the meantime — the licensing API tells the plugin its expiry up-front so a network problem cannot cause an unexpected downgrade.

After the expiry date passes, the next heartbeat downgrades the site to the free tier. Your rules and settings are kept; premium modules stop, but everything you saved is intact and waiting for renewal.

Removes the license key from this site and frees up one activation slot, so you can use the same key on a different site. Your saved rules, wizard answers, telemetry history, and module settings are all preserved.

After removal, premium modules stop on the next page load. To re-activate, paste the key into the License page activation field — your saved settings light back up automatically.

The Modules page lists every optimisation Accelerator can perform. Each one runs as an independent module — you can toggle any single one without affecting the others, and a module that is failing for any reason simply switches itself off rather than taking the whole plugin down with it.

Modules are grouped into three buckets:

• Always active — required for the plugin to function. Cannot be disabled.
• Free — included on every license; toggleable. Most are designed to be invisibly safe at default settings.
• Premium — locked unless a Premium license is active on this site. Each premium module solves a specific kind of slowness; you do not need all of them.

The toggles save in a single batch when you click the Save button at the bottom of the page. Changes take effect on the next request after that.

Some modules support a shadow mode in addition to live. In shadow, the module measures exactly what it would have done on each request without actually doing it — useful for proving the change is safe before flipping it on.

When a module supports shadow, the toggle on the Modules page exposes three states (off, shadow, live) instead of just two. The Telemetry page's Shadow Counters section shows how many would-be actions the module has measured so far.

The Telemetry module records how long each WordPress request takes and how much memory it uses. It writes to a small local store and never leaves your server.

Every chart, percentile, and Impact comparison on the Telemetry admin page is driven by this module. With it off, the plugin would still work but you would have no way to see whether it was helping. It runs on every request type — frontend, admin, REST, admin-ajax, cron — and is required for the plugin to function correctly.

WordPress loads a list of "autoloaded" options on every single request. Plugins sometimes store large blobs in those options — page-builder caches, form submissions, analytics buffers — which then bloats every page load whether or not that data is needed.

Options Guard watches for autoloaded entries that are unusually large and demotes them so they only load when something actually asks for them. The data itself is not deleted; only the "load on every request" flag is removed. Worst case is no change in behaviour. Best case is tens of milliseconds back on every page load.

WordPress option groups that are not flagged for autoload still get fetched the moment any code calls get_option() on them. Options Lazy Load batches related lookups and delays them until the first real use — cutting the number of database round-trips on the initial part of a page load.

Safe to leave on. Sites with many small options (multilingual content, complex theme settings, ecommerce extras) see the biggest improvement.

WordPress ships translations as compiled binary files. Without help, it parses them again on every request — even if nothing has changed. The Translation Precompiler module replaces that with a pre-parsed cached form on disk, so subsequent requests skip the binary parse entirely.

Most useful on multilingual sites or sites running plugins with very large translation files. Activates automatically once cached; first request after a translation update takes a small extra moment to refresh.

Plugins enqueue CSS and JavaScript files across the whole site even when those files have nothing to do on the page being viewed — the WooCommerce cart stylesheet appearing on a contact form page is a classic example. Asset Dequeuer removes those files when the rule library knows they are unnecessary on the request type at hand.

Driven by a curated set of safe rules. Plugins not yet covered by a rule are left untouched, so the worst-case behaviour is "does nothing on that plugin".

The headline module. Stops a plugin from loading at all on a request that does not need it. The cost of that plugin — its hooks, its queries, its files, its memory — is removed entirely from that request rather than minimised.

Driven by the rules your Setup Wizard generated and any per-page rules you added. The free tier enforces site-wide skip rules; the premium tier adds URL-level keep/skip rules. A built-in dependency safety net refuses any skip that would unload a plugin another active plugin still needs.

Plugin Skipper is the module most responsible for the headline TTFB improvements you read about on the homepage.

WordPress maintains a global table of action and filter hooks. On a frontend page load, hooks that only matter for admin screens are still registered — they consume memory and CPU even though they will never fire. Hook Pruner removes hooks that cannot run for the request type at hand, before plugins get the chance to attach more.

The list of safe-to-prune hooks is curated. Anything outside the curated list is left untouched, so the worst case is "does nothing extra".

Premium. When a chatty admin-ajax action is taking time you do not need to spend — heartbeat polling, analytics tracking pings, autosave noise — Ajax Action Filter silences just that action without unloading the plugin that owns it.

Useful when you want to keep most of a plugin running but mute one specific endpoint. For full plugin offloads on admin-ajax, the regular Plugin Skipper rule is the right tool instead.

Premium. The opposite trade-off of the filter: lets a single admin-ajax action run, but strips every non-essential plugin from that one request. The action's owning plugin stays loaded; everything else is gone.

Right for custom admin endpoints that ought to be fast but get dragged down by 25 unrelated plugins booting alongside them. Use with caution — security plugins are removed from the request along with everything else, unless you explicitly keep them via the rule's Keep plugins field.

Premium. WordPress URL matching tries every rewrite rule in turn until one matches. On sites with many custom post types, taxonomies, or custom rewrite rules, this becomes a noticeable cost on every request. Router Trie compiles all rules into a search tree at module activation, reducing URL matching to a single fast traversal.

Visible win on heavy installs. On simple sites with the default rewrite rules, the gain is too small to measure.

Premium. Caches identical database read queries inside a single PHP request. If two plugins both call get_user_meta()for the same user during one page load, the second call returns the first call's result instead of querying the database again.

Safe by design — the cache is discarded the moment the request ends. There is no way for stale data from one request to leak into another. Writes invalidate the affected cache entries immediately.

Premium. WordPress's update_option() call writes to the database immediately. When several plugins call it inside the same request — common during checkout, login, or admin saves — each write opens its own transaction. Write Coalescer batches them and commits a single round-trip at the end of the request.

Reduces lock contention on the options table. Especially valuable on high-traffic WooCommerce sites and membership sites where login writes pile up.

Premium. Post meta queries are one of the most common bottlenecks in WordPress. Meta Sidecar mirrors the post meta you read most often into a narrower indexed lookup table — not a copy of the whole table, just the keys that matter for your site.

Requires a manifest declaring which meta keys to mirror. Once warm, meta reads against those keys run several times faster. Pair with Meta Rewriter, which automatically routes compatible meta queries to the sidecar table.

Premium. Sees a WP_Query with a meta_query clause and quietly rewrites it to read from the Meta Sidecar table when the keys involved are mirrored there. Compatible with standard meta queries; unusual or custom shapes fall back transparently to the original WordPress path.

Has no effect without Meta Sidecar — they work as a pair. Together they are the largest single source of speedup on sites that lean heavily on post meta.

Premium. By default WordPress runs scheduled tasks by checking on every page load whether anything is due. That means a cron sweep can land on top of a real visitor request and slow it down. Cron Decoupler disables that behaviour and hands scheduled tasks to your host's system cron instead.

Result: zero cron overhead on visitor requests, and tasks run on a reliable external schedule rather than "whenever someone shows up". Requires your hosting to support external cron jobs — most managed WordPress hosts do; a few shared hosts do not. The Modules page shows the live cron status so you can see immediately if it stops firing.

Per-Page Rules let you target a single URL or a pattern of URLs and either force a plugin to load (Keep) or stay unloaded (Skip) just for that scope. They sit on top of the site-wide rules from your Setup Wizard — wider rule wins by default; per-page rules carve exceptions out of it.

On the Free tier, rules are saved and visible but not enforced at runtime — the plugin shows you a notice when this is the case. The Premium tier enforces them on every matching request.

The URL or pattern this rule applies to. Wildcards are allowed: /campaign/* matches the campaign folder and everything below it; /shop with prefix matching catches /shop plus /shop/cart. An empty pattern combined with the "Home page only" checkbox targets the site's root URL specifically.

Multilingual sites can mark a pattern "language-aware" so it fires on /tr/..., /en/... variants of the same path without writing each one out.

Which plugin this rule controls. Pick from the dropdown rather than typing the main file path by hand — the dropdown lists exactly what WordPress sees, which prevents typos that would silently make the rule do nothing.

If a plugin you expect to see is missing from the dropdown, run the Setup Wizard once to refresh the scanner's cached list of installed plugins.

Two values: Keep forces the plugin to load on matching URLs even when a wider site-wide rule would skip it; Skip prevents the plugin loading on matching URLs.

Skip is the most common — it is how you reclaim time on pages where a plugin has nothing to do. Keep is for carve-outs: "skip WooCommerce on the blog overall, but keep it on this one landing page that uses a shortcode".

Which kind of request the rule fires on. The simplest pattern is "Frontend, all visitors" — the rule applies to every public page-load. Sub-scopes let you say "only logged-out visitors" or "only REST API calls" without affecting the others.

Most rules need only one scope. If you find yourself needing several scopes for the same plugin and pattern, it is usually clearer to write one rule per scope so you can see the behaviour at a glance later.

An optional reminder you wrote when the rule was added — "CF7 not needed on product pages", "leftover from the launch campaign", that kind of thing. Future you will thank present you.

The note is shown only in the rules table; it has no effect on the runtime behaviour of the rule.

The URL the rule targets. Type a path like /shop/* to cover everything under the shop, or /contact for a single page. The leading slash matters; the domain name does not (the rule applies wherever this site is hosted).

For language-aware sites, tick the "Match all language variants" option below the field so one rule covers /tr/contact, /en/contact, etc.

How the URL pattern is compared against incoming requests. Prefix is the sensible default — /shop matches /shop, /shop/cart, and anything else starting with /shop. Exact matches only the literal path. Home page onlyignores the pattern field entirely and fires on the site's root URL.

Developer Mode exposes additional anchor syntax for users who want regex-like end-of-path matching. Most rules do not need it.

Two options on every rule. Keep forces the plugin to load on matching URLs — useful when you have a wide skip rule and want one URL to be an exception. Skip prevents the plugin from loading.

Free tier saves both forms but enforces neither at runtime. Premium enforces both. The dependency safety net runs regardless of tier and prevents skips that would break another plugin.

Defines the kinds of traffic the rule applies to. Choose Frontend (page views) for visitor-facing rules, or pick a sub-scope like "Guests only" to apply just to logged-out visitors. REST API and admin-ajax are separate scopes so a rule for a frontend skip does not accidentally affect background API calls.

Combinations are allowed. Most rules use one scope and stay clear; multi-scope rules are powerful but harder to debug a year later.

Premium + Developer Mode only. Targets specific admin-ajax actions instead of unloading a whole plugin. Comma-separated list, with * as a trailing wildcard — for example wc_ajax_* matches every WooCommerce ajax action.

When set, only the named action hooks are processed under the chosen Ajax mode (Kill or Isolate). The rest of the plugin stays fully loaded for other ajax calls.

Premium + Developer Mode only. Two strategies for an admin-ajax rule. Kill short-circuits the matched action and returns nothing; the plugin stays loaded but that one action never runs. Right for chatty endpoints like heartbeat or tracking pings.

Isolate lets the action run, but strips every non-essential plugin from the request. Right for fast, narrow endpoints (a custom admin search box, a price-calculator API) that should not pay the cost of 25 unrelated plugins booting alongside them.

Premium + Developer Mode only. List of plugin file paths to keep alongside the action's owner during Isolate mode. The action owner is always kept automatically; this field is for plugins you also want to be present in the isolated request.

The most common case: keeping a security or rate-limiting plugin (Wordfence, etc.) active so isolate-mode requests do not bypass your protections. Comma-separated, one entry per plugin.

On a multilingual site, the same logical URL exists under several language prefixes — /contact, /tr/contact, /en/contact, etc. Tick the "Match all language variants" checkbox on a rule and it fires on every language version automatically, without you writing each one out.

Works with WPML, Polylang, and TranslatePress. If your multilingual setup uses translated slugs (the URL itself changes per language), use the "+ Add another URL" button to list each translated variant instead.

The first step where the wizard does any actual work. Pick the closest match to your site's shape — WooCommerce store, membership site, blog, news site, learning platform, forum, custom. The wizard then weighs its rule recommendations toward plugins typical of that kind of site.

Custom is the catch-all. Pick it when nothing else fits or when the site is built bespoke; the wizard switches to a more conservative mode and asks more questions to compensate.

Measures the current TTFB (time-to-first-byte) of a handful of representative pages on your site — usually the home page, a blog post, a category archive, plus anything specific to the site type you picked. Takes about two minutes; keep the wizard tab open until it finishes.

These numbers become the "before" baseline that the Telemetry page's Impact card later compares against. Without this step, the Impact card would have nothing to compare current traffic to.

Lists every plugin currently active on the site. The wizard cross-references each one against its rule library — plugins it already knows get safe default skip recommendations; plugins it has not seen before are flagged so you can decide whether to include them.

You can mark any plugin as "keep loaded everywhere" here if you know it must run on every request — the wizard will respect that and not propose any skip rule for it.

Shows the proposed skip rules grouped by request type — frontend page views, REST calls, admin pages, admin-ajax, cron. Each group has its own list. Accept the defaults unless you have a specific reason not to; the rule library is curated for safety, not aggression.

You can untick any individual rule here. Doing so leaves the corresponding plugin loaded on that request type, which is always safer than skipping it.

Optional. Only appears if you picked the Developer path on the welcome step. Lets you hand-craft URL-pattern rules during initial setup without leaving the wizard.

Skippable on first install — you can always add per-page rules later from the Per-Page Rules admin screen. Shown here mostly for users who already know the URL patterns they want to target.

The final step. Saves your rules and starts a measurement-only soak window — the rules run in shadow mode and record what they would have done, without actually changing anything yet. The soak length depends on the wizard path you chose: shorter on the simple path, a full day on the developer path.

At the end of the soak window the rules flip to live automatically. You can also flip early at any time from the Welcome page or by re-opening the Setup Wizard.

Safe Mode is the emergency off switch. One click pauses every Accelerator performance module — Plugin Skipper, Hook Pruner, Asset Dequeuer, all of it. Your site reverts to behaving exactly as if Accelerator were not installed.

It does not touch your saved configuration. Wizard rules, per-page overrides, license, shadow settings, telemetry history — everything is preserved exactly as it was. When you click Resume, the same configuration is back in effect on the next request.

While Safe Mode is on, a sticky notice appears at the top of every admin page so you don't forget the site is paused.

The cases where Safe Mode is the right tool:

• A page stops working after running the Setup Wizard. Pause first, then come back and identify which rule was responsible.
• A plugin suddenly misbehaves. Rule out Accelerator as the cause in five seconds. If the plugin still misbehaves with Accelerator paused, the issue is somewhere else.
• A/B comparison. Use external tools to measure your site with Accelerator off, then resume and measure again. The honest before/after.
• Theme or plugin debugging. Need a known-clean baseline while you chase down a conflict between two third-party plugins.

Day-to-day "something feels slow" is usually nota Safe Mode case — the Telemetry page's Impact card is the right tool for that. Safe Mode is for "something is broken" or "I need a clean comparison."

Resuming is a single click. The exact configuration you had before pausing — wizard rules, per-page overrides, license, shadow toggles, kill-switch states — comes back into effect on the next request. Nothing is reconstructed or guessed; the saved state was never deleted, only ignored while paused.

If a specific rule was the cause of whatever made you pause, open the relevant admin screen (usually Per-Page Rules or Modules) before resuming and disable that one rule. Then resume — everything else continues working as before.

Off by default. When on, the Per-Page Rules screen exposes raw match-mode controls — exact-match URLs, anchor-style syntax for end-of-path matching, and an action-name field that targets individual admin-ajax actions instead of taking a whole plugin offline.

The plugin tries to do the right thing without these controls. The Setup Wizard generates rules from a curated library, Per-Page Rules has a simple "Home page only" checkbox, and most users never need anything beyond that. Developer Mode is for the cases where the simple controls cannot express what you want — and in those cases the extra power is worth the extra reading.

Toggle is on the License page, just below "Remove license". Save flips the visibility on Per-Page Rules immediately; no other setting is affected.