Most WordPress sites do not have a plugin problem, they have a plugin loading problem. A slider runs site-wide even though it is only used on the homepage. A form plugin loads on every page even though the form lives on one contact page.

That matters because every unnecessary plugin adds work to each request. More PHP runs, more assets load, and more things can conflict. WP Shifty gives you a practical way to disable plugins per page in WordPress, then test the result safely before you apply it.

Here is a hands-on setup we use for a very common audit.

The starting point: a small site with unnecessary weight

Imagine a brochure-style WordPress site with these ingredients:

  • a slider plugin used only on the homepage hero
  • a contact form plugin used only on the contact page
  • a few standard content pages that do not need either one

On paper, that does not sound dramatic. In practice, both plugins may still initialize everywhere, and both may enqueue CSS and JavaScript globally.

That was the situation in this audit. The tested page weight dropped from 897 KB to 432 KB once we stopped loading page-specific plugins where they were not needed.

The point is not that every site will cut its weight in half. The point is that many WordPress sites carry features everywhere, even when those features are only needed in one or two places.

What WP Shifty changes

WP Shifty works with scenarios, which are collections of rules that run only when your conditions match. In one scenario, you can disable plugins, adjust resources, or add more targeting logic.

For this recipe, the main feature is plugin disabling. When a scenario matches, the selected plugin does not execute at all. This is not just front-end cleanup after the fact.

One part of this feature we like is how safely you can work. WP Shifty includes Live Preview, so you can test the current request without affecting visitors. You can also emulate devices, user roles, cookies, headers, or POST data while you preview.

If you want the full interface details, see the WP Shifty product page or browse our docs.

Recommended setup for this audit

For a site like this, we recommend keeping the setup simple. Create a few focused scenarios instead of one giant rule set.

Scenario 1: disable the slider plugin everywhere except the homepage

Start with the plugin that is most obviously page-specific.

Create a scenario for all frontend requests except the front page, then disable the slider plugin in that scenario. The practical logic is:

  • match Frontend
  • exclude the Frontpage context from your targeting approach
  • disable the slider plugin

If you prefer path-based logic, you can also target by URL or page ID depending on how the homepage is set up. The goal is the same: let the slider plugin run on the homepage, and nowhere else.

This usually helps in two ways:

  • the plugin itself stops executing on inner pages
  • its CSS and JS no longer load where the slider does not exist

Scenario 2: disable the contact form plugin everywhere except the contact page

Next, do the same for the form plugin.

Create a scenario that matches normal frontend pages other than your contact page, then disable the contact form plugin there. Depending on the site, you can target the contact page with:

  • a specific Page ID
  • a URL path match
  • a broader Post type condition if your forms only belong to one content type

For most brochure sites, a page condition is enough. This is often one of the cleanest wins in a WordPress performance audit because form plugins tend to load more assets than site owners realize.

Scenario 3: add per-device conditions where they actually help

Sometimes a plugin is needed on desktop but not on phone, or vice versa. WP Shifty lets you add a Device condition for desktop, phone, tablet, Android, iOS, or bots.

A realistic example is a heavier homepage effect or supporting script that you want to keep for desktop layouts but avoid on phones. In that case, build a separate scenario for the homepage and phone traffic, then disable the related plugin only for that device group.

This is not something to force onto every site. But when a mobile experience needs to stay lean, device-based conditions can be a very practical second pass.

Add user-role conditions for admin-safe behavior

One concern with conditional optimization is editing. You do not want to accidentally hide functionality from yourself while reviewing or updating content.

This is where User conditions become useful. WP Shifty can target user roles, including not logged in visitors.

A common setup is:

  • apply aggressive plugin disabling to Not logged in users
  • keep the full plugin stack available for administrators or editors when needed

This is especially helpful on sites where logged-in users need extra tools, previews, or editing integrations that normal visitors never touch. For example, you might disable a front-end feature plugin for anonymous traffic but leave it alone for admins during content review.

In other words, you are not just deciding where a plugin loads. You are deciding for whom it loads.

Test everything in Live Preview before you apply it

This is the part that keeps the workflow practical.

Use Live Preview to test each scenario on the real request before you activate it broadly. Check the homepage, the contact page, and a few ordinary content pages. Then emulate:

  • phone and desktop devices
  • logged-in and not-logged-in users
  • any other condition relevant to your setup

You can also disable auto-refresh while making several changes, then review them together. If something looks off, adjust the conditions and test again.

We also recommend a quick comparison with the built-in ?noshifty=1 bypass. Add it to the URL to load the page without any WP Shifty scenarios for that request. It is a fast way to compare behavior and troubleshoot edge cases.

One important note: plugin disabling depends on WP Shifty being able to install its MU loader file. If the mu-plugins directory is not writable, plugin disabling will not work reliably. That is worth checking early.

What to watch out for during a page-by-page diet

This kind of cleanup works well, but it is not magic.

A few practical checks matter:

  • Make sure the plugin is truly unused on the targeted pages.
  • Test interactive features after disabling, not just the visual layout.
  • Be careful with plugins that support widgets, shortcodes, or shared templates in more places than you first expect.
  • If you later move a form or slider to a new page, update the scenario.

The real problem is not usually the condition system. It is assumptions. Site owners often forget where plugin functionality has spread over time.

That is why we prefer a small, scenario-by-scenario audit. It is easier to verify, easier to maintain, and less likely to create surprises.

Take-home message

If you want to disable plugins per page in WordPress, the fastest wins often come from obvious mismatches: homepage-only sliders, contact-page-only forms, and device-specific extras that do not need to run everywhere.

WP Shifty gives you a clean way to set those rules by page, URL, device, and user role, then verify the result in Live Preview before you make it live. Done properly, that means less bloat, fewer moving parts, and a lighter front end where it actually counts.

If you want to try this workflow on your own site, have a look at WP Shifty and keep our documentation open while you build your first scenarios.