How to Disable WordPress Plugins From Loading on Specific Pages and Posts

Updated on September 29, 2017

When it comes to WordPress performance we have a lot to say about plugins. Each plugin adds PHP code that has to be executed, can include scripts and styles, and some may execute additional queries against the database. This means that unnecessary plugins can affect page speed and may have a negative impact on user experience and page ranking. As an example, consider a plugin that builds and displays custom forms in front pages, like Contact Form 7. You typically only need a form on a single page. Do you really want to run the plugin code and include scripts and styles on every page of your website?

In this post, I will demonstrate that you can install as many plugins as you need (don’t go crazy of course), and nevertheless make WordPress pages load fast. We’re going to disable WordPress plugins (that are unnecessary from loading on specific posts and pages. This will involve a four four-step process:

  • Choose the most popular plugins that fit your needs, and compare their features and effects on page speed.
  • Filter and deactivate unnecessary plugins before page loads.
  • Optimize CSS and JS files.
  • Track the site performance.

Let’s dive deep.

Three General Rules to Follow When Choosing a Plugin

The following general rules can be helpful when choosing a plugin:

  • Install only well-coded plugins from trusted developers: consider active installs, user rating, client support, update frequency, and any useful piece of information coming from WordPress community.
  • Prefer scalable plugins: compare similar plugins in terms of performance, making use of browser dev tools and/or online services like Google Pagespeed InsightsPingdom, and GTmetrix to evaluate the impact of each plugin on page load time.
  • Do not install unnecessary plugins: it could be obvious, but it’s worth mentioning that you should never install a plugin you don’t really need for security and performance reasons.
wordpress repository reputation

WordPress Plugin Directory provides relevant information we should always take into account when choosing a plugin

Once we’ve chosen the most efficient and popular plugin out there, we can move forward to speed-up our website and force WordPress to load a plugin just in those pages where it is really needed.

A concrete example

Contact Form 7 is a great plugin that builds and displays forms in WordPress. It provides a perfect example for our purposes, because it includes the following .js files on every page, even if the page doesn’t contain a form:

  • jquery.form.min.js
  • scripts.js
Chrome DevTools Network panel

Chrome DevTools Network panel provides detailed information about network requests made when a page is loaded

A plugin can determine a general loose of efficiency, but we can force WordPress to selectively deactivate plugins depending on the requested URL. If you’re a developer, read over the next section, in which I explain how to build a mu-plugin that filters unnecessary plugins. If you are not a developer, feel free to jump to the section dedicated to plugins that allow to filter and organize plugins.

How to Build a Must-use Plugin to Programmatically Deactivate Plugins

Our goal is to disable WordPress plugins (deactivate) on a per-page basis by filtering the list of active plugins. To achieve this goal, we are going to build a Must use plugin, which is a plugin that resides in a specific /wp-content sub-folder, and runs before any regular plugin. So, let’s create a new .php file (i.e. my-plugin.php) in /wp-content/mu-plugins.

Our first task is to verify the request URI. Since mu-plugins run before any is_ variable has been defined, we are not allowed to use conditional tags. Consequently, we have to parse the request URI and check the corresponding URL path:

$request_uri = parse_url( $_SERVER['REQUEST_URI'], PHP_URL_PATH );

$is_admin = strpos( $request_uri, '/wp-admin/' );

// add filter in front pages only
if( false === $is_admin ){
	add_filter( 'option_active_plugins', 'kinsta_option_active_plugins' );
}

Let’s dive into this code:

  • parse_url returns the path of the requested URL
  • strpos finds the position of the first occurrence of ‘/wp-admin/’, and returns false if the string is not found. $is_admin variable stores the returned value
  • if the request URL does not contain ‘/wp-admin/’, then we add the option_active_plugins filter.

The condition prevents the filter to be run in the admin panel, so that we can safely access plugin settings pages. option_active_plugins belongs to the option_$option_name group of filters. These hooks allow to filter any option after it’s been retrieved from the database. Since all active plugins are stored in wp_options table where option_value field is active_plugins, the option_active_plugins filter provides a way to programmatically activate or deactivate plugins.
With that being said, lets define the callback function:

function kinsta_option_active_plugins( $plugins ){
	global $request_uri;
	$is_contact_page = strpos( $request_uri, '/contact/' );

	$unnecessary_plugins = array();

	// conditions
	// if this is not contact page
	// deactivate plugin
	if( false === $is_contact_page ){
		$unnecessary_plugins[] = 'contact-form-7/wp-contact-form-7.php';
	}

	foreach ( $unnecessary_plugins as $plugin ) {
		$k = array_search( $plugin, $plugins );
		if( false !== $k ){
			unset( $plugins[$k] );
		}
	}
	return $plugins;
}

Here is what’s going on:

  • First, we pass the function an array of active plugins.
  • The function checks whether the request URL path contains the string ‘/contact/’. If it doesn’t, strpos returns false, and we can check a new condition.
  • If the current request URL points to a page other than the contact page, then we add the Contact Form 7 plugin to an array of unnecessary plugins.
  • The foreach cycle iterates over the elements of the $unnecessary_plugins array. If the current plugin is an active plugin, then the unset function removes it from the $plugins array.
  • The function returns the updated $plugins array.

You can download the full code of this plugin from Gist.

Now you can upload the plugin to the mu-plugins folder and inspect any page of your website. You should find CF7 assets only in the contacts page. The mu-plugin can be highly customized adding more conditions and checking more URIs, but each condition has to be manually added to the code, and in the long run this simple mu-plugin could be difficult to maintain.

Plugins That Filter Plugins

As an alternative, we can look at a number of good plugins that allow us to add filters that can be managed from the WordPress admin panel.

Plugin Load Filter

Plugin Load Filter is a free option for WordPress users who need to filter plugins under several conditions.

Plugin Load Filter settings

Plugin Load Filter allows to filter plugins in admin panel as well as in site pages

Currently, it supports the following features:

  • Post formats
  • Custom Post Types
  • Jetpack modules
  • Embed Content
  • AMP keyword
  • URL filters

Once a filter has been activated, the admin user can specify where in the site it has to be applied, as shown in the image below.

Plugins Load Filter settings

Once the filter has been activated, the admin user can determine the type of page where it has to be applied

Plugin Organizer

Plugin Organizer is a more comprehensive plugin that allows site admins to:

  • selectively disable active plugins by post type and request URL
  • create groups of plugins
  • change the plugin loading order
Plugin Organizer Settings

Plugin Organizer Settings page

The Global Plugins options page provides a drag&drop facility that allows the admin user to globally disable plugins, preventing WordPress to run one or more plugins anywhere in the site, unless it’s differently specified for single posts or pages. The same feature is available for search page and post types.

Global plugins

CF7 has beed globally disabled

The plugin adds a metabox in the post editing screen so that the admin is allowed to override global and post type settings. This feature can be activated for post types as well, by checking the corresponding item in the General Settings screen. Other features relate to grouping and ordering plugins. More information can be found in online documentation.

perfmatters Plugin

A partially different approach comes from the perfmatters plugin. It’s a premium alternative that allows the site admin to selectively load theme and plugin assets depending on URL or custom post type. It is a great tool for both plugin and theme optimization. In fact, it’s developed by a team member from Kinsta!

Disable scripts manager

Disable scripts manager

This is very powerful and can drastically increase the speed on your WordPress sites (especially your homepage). A few examples of what this can be used for:

  • Social media sharing plugins should only be loaded on your posts. You can easily disable it everywhere and load only on post types, or even custom post types.
  • The popular Contact Form 7 plugin loads itself on every page and post. You can easily disable it everywhere with one click and enable only on your contact page.

You can see from this review of perfmatters, it decreased their total load times by 20.2%. On their homepage alone they were able to reduce the number of HTTP requests from 46 down to 30! The page size also shrunk from 506.3 KB to 451.6 KB.

Speed test with perfmatters

Speed test with perfmatters plugin

How to Track Performance: The Browser’s Dev Tools

A fundamental step on the highway to performance optimization is the load time measurement. We have a number of plugins and online tools we can use to track site performance, like Google Pagespeed Insights and Pingdom. But first and foremost, we can use the browser’s Dev Tools, which provide a lot of meaningful information.

Chrome Network panel

The image shows the Network panel of Chrome Developers Tools

Each browser inspector has a Network panel which displays a list of network requests and related information. Follow these links for detailed documentation:

Firefox performance analysis tool

Firefox Network Monitor provides an additional panel that allows to evaluate how long the browser takes to download the page assets

In a WordPress install with eighteen active plugins, we’ve repeatedly inspected a post page with Firefox Dev Tools. We’ve first measured page speed and listed requested resources before installing any filtering plugin. The following image shows the output of the performance analysis tool of Firefox Network monitor.

Firefox Network Monitor

The Network monitor provides the following results (empty cache):

  • size: 709.77 Kb
  • load time: 6.67 seconds
  • requests: 30

Following, we have installed Plugin Organizer to prevent WordPress from running the CF7 plugin. The pie chart changes a bit.

Firefox Network Monitor

Now the page loads faster (empty cache):

  • size: 665.85 Kb
  • load time: 5.08 seconds
  • requests: 27

Next, we’ve deactivated sixteen unnecessary plugins, and the next image shows how much we’ve improved the page performance.

Firefox Network Monitor

After disabling all unnecessary plugins, the empty browser cache of the Network monitor returns the following data:

  • size: 440.15 Kb
  • load time: 3.14 seconds
  • requests: 21

This test demonstrates how heavily plugins can affect page performance, and how much we can increase page speed with a plugin filter.

But we can further improve performance thanks to another optimization tool. Autoptimize is a free plugin that concatenates, minifies and compresses scripts and styles, moves styles to the page head and scripts to the footer (Read more about the plugin this post on How to Eliminate Render-Blocking JavaScript and CSS). Activate the plugin, then reload and inspect the page again.

Firefox Network Monitor

Thanks to Autoptimize, we’ve reached a high level of optimization (empty browser cache):

  • size: 474.56 Kb
  • load time: 1.99 seconds
  • requests: 13

Finally, we can compare the results of our tests. The resource size has been reduced of 235Kb, the load time was reduced from 6.67 seconds to 1.99 seconds, and the number of HTTP requests decreased from 30 to 13.

Wrapping up

Whether you build your own scripts or install third-party tools, organizing and filtering plugins is a good practice you should always consider when it comes to performance optimization. But learning how to disable WordPress plugins is just one among many other techniques aimed to increase site speed, and here is a list of guides and tutorials related to site performance that worth a reading:

This article was written by Carlo Daniele

Carlo is a freelance front-end designer and developer. When he writes articles and tutorials, Carlo mainly deals with web standards, but when he plays with websites his best workmate is WordPress.

Hand-picked related articles

  1. Gravatar for this comment's author
    Piet April 27, 2017 at 3:21 pm

    It simply is too bizarre for words that a plugin such as Contact Form 7, to this day still loads all files on each and every page load.

    1. Gravatar for this comment's author
      Brian Jackson April 27, 2017 at 3:23 pm

      I totally agree! But there are a ton of popular plugins that still do this. This ends up in the plugin developer responsible for harming performance on client’s sites who may not know how to fix it :(

    2. Gravatar for this comment's author
      Andrea Avesani September 19, 2017 at 7:38 am

      I feel like WordPress shoult implement a system to disable/enable single plugins from single pages. And a control in the Plugin area of the dashboard.

      1. Gravatar for this comment's author
        Brian Jackson October 2, 2017 at 9:59 pm

        That would definitely be nice :)

  2. Gravatar for this comment's author
    Makabe May 2, 2017 at 12:55 am

    Great article! :) Could you also provide an example of code for loading certain plugins only in posts (is_single)?

    1. Gravatar for this comment's author
      Carlo Daniele May 2, 2017 at 10:15 am

      Hi. The script should run before any regular plugin. This means that we need a must-use plugin. Unfortunately, mu-plugin load before any is_ variable has been defined, so we are not allowed to use conditional tags like is_single.
      But you could try another way. 1) build a regular plugin that filters plugins, 2) build a must-use plugin that force WordPress to load your filtering plugin before any other active plugin.
      You can read more about changin the plugin loading order here: https://wordpress.org/support/topic/how-to-change-plugins-load-order/

      1. Gravatar for this comment's author
        Makabe May 2, 2017 at 10:31 am

        Thanks, I’ll check it out.

  3. Gravatar for this comment's author
    John Betancourth May 5, 2017 at 8:03 pm

    Hey Kinsta Bloggers, you are awesome!

  4. Gravatar for this comment's author
    Atul Kumar Pandey July 31, 2017 at 3:18 pm

    That is really nice tutorial. Many plugins not needed on homepage and they just increase the size.

    1. Gravatar for this comment's author
      Brian Jackson July 31, 2017 at 3:32 pm

      Glad you liked it Atul! Definitely agree… the homepage is one of the most important pages for a site as it is the entry way for a lot of traffic. Even just applying some methods above on just the homepage can make a big difference.

Leave a Reply to Andrea Avesani Cancel reply

Use WordPress?

Join 20,000+ others who get our FREE weekly newsletter with WordPress tips on how to drive more traffic and revenue to your business!

You have Successfully Subscribed!

Send this to a friend