Loadwright

Loadwright makes WordPress faster by doing something most speed plugins can’t: it stops the plugins you don’t need from loading at all on the pages where they aren’t used. Their PHP never runs, their database queries never fire, and their CSS/JS is never enqueued on those requests.

By default, WordPress loads every active plugin on every request — even a contact-form plugin on a blog post, a slider on the checkout, or a shop filter on your About page. That wasted work slows down your server response and bloats every page. This plugin lets you scope each plugin to exactly where it belongs, so the rest of your site stays lean.

Unlike asset optimizers that only minify or defer files, this works at the plugin level: the whole plugin is removed from the request. It works through a tiny must-use loader that you install with one click from the settings screen, so the decision happens before other plugins load — the only point at which a plugin can be kept out of a request entirely.

How it speeds up your site

Cutting unused plugins from a request reduces three things that page-speed tools measure directly:

• Server response time (TTFB) — less PHP executes and fewer database queries run, so the page is built faster.
• Page weight (CSS/JS) — plugins that would have enqueued scripts and styles no longer do, shrinking the HTML, CSS, and JavaScript the browser has to download and process.
• Main-thread work — less JavaScript means faster interactivity.

These are the same factors behind the scores you see in Google PageSpeed Insights, GTmetrix, and Lighthouse, and the page-speed metrics behind them: LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and TTFB (server response time). Trimming per-page plugin load is one of the most effective WordPress speed-optimization (WPO) techniques, and it pairs well with a caching plugin and a CDN for the best results. Actual improvement depends on your theme, hosting, and which plugins you scope — this plugin gives you the control; your rules decide the gain.

What you can target

• Specific pages, posts, or products (by ID)
• Whole post types (posts, pages, products, or any custom type)
• Categories and product categories
• The site front page

Two modes per rule

• Disable on matches — turn the plugin off where the conditions match.
• Enable only on matches — keep the plugin on there, off everywhere else.

Great for

• Speeding up blog posts by unloading WooCommerce/shop plugins they never use.
• Keeping form, slider, popup, gallery, and social plugins scoped to the few pages that need them.
• Lowering queries and payload on landing pages to lift PageSpeed and GTmetrix scores.
• Resolving plugin conflicts by limiting a plugin to where it belongs.

Good to know

• The controller plugin never disables itself.
• If a request can’t be resolved to a single published object, no rules are applied (it fails open — nothing is disabled when in doubt).
• It does not minify, combine, or lazy-load assets; it is plugin-level load control that complements those tools rather than replacing them.
• The must-use loader is only added when you click to install it, and is removed on Remove loader, deactivation, or uninstall — restoring normal loading immediately.