Perfmatters and WP Shifty are both answers to the same problem: your site loads assets it does not need. A contact form plugin queues its scripts on every page. A slider library loads on posts that contain no slider. WooCommerce ships its cart fragments to people reading your blog.
Both plugins let you switch those off selectively. Where they differ is how precisely you can describe the situation in which something should load — and what you are allowed to do once you have described it.
We installed both on the same WooCommerce site to see how far each one goes. We make WP Shifty, so the method is spelled out below and every capability we describe is either visible in the screenshots or documented by the vendor.
The two models
Perfmatters is a settings panel with a script manager attached. Its admin is organised as a list of tabs — General, JavaScript, CSS, Preloading, Lazy Loading, Fonts, CDN, Analytics, Code, Tools, Database — and most of what it does is site-wide switches: disable emojis, disable Dashicons, disable embeds, disable XML-RPC, remove the RSD link, remove jQuery Migrate. Its conditional layer is the Script Manager, which you open on a page to switch individual scripts and styles off for that page, post type, or a URL pattern.
WP Shifty is a rule engine with a live editor attached. There is no long list of global toggles. You create a scenario: a set of conditions, and a set of actions that fire when those conditions match. The editor is a split screen — a live preview of the page on the left, the rules on the right — so you watch the page change as you switch things off.
Notice what the editor refuses to do in that screenshot: it says “Add a condition first.” That is the whole philosophy in one message. Rules do not exist in the abstract; they exist for a described situation.
Conditions: how precisely can you describe the situation?
This is the heart of the comparison. Anyone can turn a script off on a page. The question is what counts as “a page”.
Perfmatters targets the obvious axes: the current post or page, the post type, a URL pattern with regex, plus device type and whether the visitor is logged in. For the majority of tidying-up work, that is enough.
WP Shifty exposes 22 condition types, and they can be combined inside a single scenario:
| Kind | Conditions |
|---|---|
| Content | Page, Post type, Archive, Author, Search, 404, Frontpage |
| Request | URL (exact / partial / regex), Query string, HTTP header, Cookie, POST data (regex), User agent |
| Context | Frontend, Admin pages (including query arguments), AJAX action, Cronjob, WP-CLI, Everywhere |
| Visitor | User role (including Not logged in), Device (desktop, phone, tablet, Android, iOS, bots) |
| Commerce | Shop pages (WooCommerce core pages) |
The bolded ones are the interesting half, because they describe situations a page-based tool cannot see:
- Cookie — strip the review widget for visitors who already dismissed it. Load the abandoned-cart script only for sessions that actually have a cart.
- HTTP header — behave differently behind a specific proxy or CDN, or for requests carrying a particular header.
- AJAX action — this is the one that surprises people. Half of a slow WordPress admin is plugins loading their entire runtime during someone else’s AJAX call. Matching the action name lets you cut that.
- Cronjob and WP-CLI — stop page-builder and analytics plugins from booting during cron runs and CLI commands, where they do nothing but cost time.
- POST data — match on the payload, with regex, which is how you special-case one form handler without touching the rest.
- Bots — serve crawlers a leaner page than the one you serve people.
We did not find equivalents for these in the Perfmatters build we installed. That is not a criticism of Perfmatters so much as a description of what it is for: it optimises pages, and these conditions are about requests.
Actions: what can you do once the condition matches?
Both plugins can disable a script or a stylesheet. WP Shifty’s rule set goes further in four ways.
Disabling a plugin means it does not run
When a scenario disables a plugin, the plugin does not execute at all — it is not merely dequeued after the fact. Its PHP never runs, its queries never fire, its hooks never register. Dequeuing a script saves a request; not loading the plugin saves the server work too. You can see the plugin list with its toggles in the editor screenshot above.
Overwriting a resource instead of just removing it
This one has no counterpart in Perfmatters as far as we could find. WP Shifty can clone a CSS or JS file to a safe copy and let you edit that copy, leaving the original untouched. If the source is minified you can beautify it, edit it, and re-minify through the WP Shifty API — and restore the original with one click if you regret it.
The practical case: a plugin’s stylesheet is 90 KB and you need 3 KB of it, but you cannot simply remove it because the page falls apart. Removal is a blunt instrument. Editing a copy is a scalpel — and because the original file is never modified, the plugin’s next update does not silently undo your work or get blocked by it.
Injecting HTML at precise hooks
A scenario can inject markup at the beginning of <head>, after the styles, at the end of <head>, or at the beginning or end of the footer. Critical CSS above the fold on one template, a vendor tag only on checkout, an inline script only for logged-out visitors on mobile — conditionally, without a functions.php edit.
Load behaviour and preloading
Beyond on and off, a resource can be set to lazyload — loaded after the first interaction, meaning scroll, mousemove, touch, click or keypress — or, for scripts, async or defer. Preloading is available for critical assets like the LCP image and above-the-fold CSS. Perfmatters also does deferral, delay and preloading; the difference is that here each of those is a per-scenario decision rather than a global setting with an exclusion list.
Live Preview: the part that makes this usable
Selective disabling is dangerous work. Turn off the wrong script and the menu stops opening — for everyone, immediately, on the live site.
WP Shifty’s editor is built around a live preview so that experimenting is not the same as deploying. You get the rendered page beside your rules, a device selector and viewport size, an auto-refresh you can switch off while making a batch of changes, and — this is the part that matters for conditional rules — emulation of the conditions themselves: devices, user roles, custom HTTP headers, cookies and POST data. You can preview what a logged-out visitor on iOS with a particular cookie would receive, without becoming that person.
There is also an admin toolbar menu that shows which scenarios matched the request you are looking at, and lets you add a rule for the current page, post type or URL without going back to the dashboard.
Where Perfmatters is genuinely the better tool
- Global cleanup out of the box. Emojis, Dashicons, embeds, XML-RPC, RSD, jQuery Migrate, heartbeat control — a row of switches that fixes the standard WordPress bloat in about ninety seconds. WP Shifty has no equivalent list, because everything in it is a rule you write.
- It is a broader performance plugin. Lazy loading, font handling, a CDN tab, local analytics hosting and database cleanup are all included. Shifty is deliberately narrow: it controls what loads and when, and it is not a cache.
- Simplicity. If your need is “stop loading the contact form script everywhere”, Perfmatters gets you there with less to learn. A rule engine is more power than that job requires.
- Maturity and community. A large user base and a lot of published recipes for common plugins.
Which one should you use?
Choose Perfmatters if you want a broad performance plugin with sensible global defaults, your conditional needs are page-shaped, and you would rather flip switches than write rules.
Choose WP Shifty if you have hit the ceiling of page-based targeting — if you need to act on a cookie, a header, an AJAX action, a cron run or a bot; if you want to edit a plugin’s stylesheet rather than delete it; if you want to inject something at a precise hook under precise conditions; or if you want to test all of that against an emulated visitor before it reaches a real one.
They are also not mutually exclusive. WP Shifty is not a cache and does not try to be a general performance suite; it is the conditional layer. Plenty of sites will run it alongside a caching plugin, and some alongside Perfmatters’ global cleanup.
Frequently asked questions
Is WP Shifty a good Perfmatters alternative?
For conditional asset and plugin loading, yes — it targets far more conditions, including cookies, HTTP headers, AJAX actions, cron and WP-CLI, and it can overwrite and inject resources rather than only removing them. For global WordPress cleanup switches and a broader performance toolkit, Perfmatters covers more ground.
Does disabling a plugin per page actually speed up the server?
It depends on what “disable” means. Dequeuing a script removes a browser request but the plugin’s PHP still ran. WP Shifty prevents the plugin from executing at all on matching requests, so its queries and hooks never happen either.
Is WP Shifty a caching plugin?
No. It controls what loads and under which conditions, and is designed to run alongside a cache rather than replace one.
Can I test rules before they go live?
Yes — that is what Live Preview is for. It renders the page with your rules applied and can emulate devices, user roles, HTTP headers, cookies and POST data, so you can check a rule against the exact situation it targets before saving it.
The verdict
Perfmatters is a good plugin and its global switches do more for the average site in ninety seconds than most optimisation work does in an afternoon. If that is the job, it is the right tool and it is cheaper to learn.
But its conditional layer describes pages, and a slow site is rarely slow in page-shaped ways. It is slow because a plugin boots during every cron run, because a script loads for bots, because a widget ships to visitors who dismissed it three weeks ago, because a 90 KB stylesheet exists for 3 KB of rules you actually use. Those are request-shaped problems, and you need request-shaped conditions to fix them.
WP Shifty gives you 22 of them, lets you combine them, lets you overwrite and inject rather than only delete, and lets you watch the result in a live preview with the condition emulated before anything reaches a visitor. That is a different class of tool, and on a site with any real complexity it is the one that keeps paying.
Tested 17 August 2026 on showcase.swte.ltd: WordPress 7.0.4, PHP 8.3, WooCommerce 11.0, Perfmatters 2.6.7 and WP Shifty 1.1.4, both installed and activated on the same site. Perfmatters’ capabilities are described from its own admin screens; WP Shifty’s condition and rule inventory is taken from its official documentation and its scenario editor. We did not benchmark page load times for this comparison — it is about what each plugin can express, not how fast it renders.
