Measurement Process

For this article I have tested 35 plugins. This includes both free and commercial plugins, big and small plugins and all of them are tested on the admin side and on the website frontend. All tests are done with a single installation, and WordPress 3.3 RC1 was used. Tests are done on the local server with PHP 5.3.8.

Testing exact impact of plugins on WordPress is not easy, since there are two things that happen during the loading process. First part is WordPress loading the plugin (using PHP include function). Second part is done through actions and filters added by plugin to WordPress during loading stage. First part is not to complicated to measure and that is what you have in the table below. Second part is very complicated to measure because it would need tracking of each action or filter executed. This second part is even more complex if you take into account that different actions and filters are executed only on some of the pages or panels.

All measurements are done using GD Press Tools Pro 4.3.1 plugin. Plugin has a tracker class that can be loaded from wp-config.php file to accurately capture snapshots of different loading stages (among other things). To allow capturing plugins snapshots, I made small change to WordPress core files: added snapshot call into loop that loads plugins.

Measurement Results

35 tested plugins are listed in the table below. You can see how much memory each plugin needs during loading, how many SQL queries are run and how many hooks attached to WordPress, as well as the total time needed for this loading stage. All this is done on the admin side (dashboard) and on the frontend (home page).

This data can change depending on the page used to do the testing since plugins can loading different things based on the page. But, these numbers are good reference point to see how the loading of plugins affect the WordPress. Also, you can see on average (and total) how much each plugin adds to the WordPress loading. What each row color means:

I have mentioned the second part of loading that happens after all plugins are loaded, and WordPress runs actions and filters after that. Table below shows the difference between the WordPress with 35 plugins and WordPress with no plugins. Before plugins loader results are same for clean WordPress and WordPress with plugins.

Interesting thing is that you can have all 35 plugins active, and I had some WordPress setups with more than 70 active plugins. But, be ready for the WordPress using much more resources. The more plugins you have active, the more server power is needed. Plugins will have negative impact on website speed. To fix that you must use a caching plugin (W3 Total Cache for caching pages and minify the JS and CSS files) and some sort of server based optimization (eAccelerate or similar extension for PHP).

Clean WordPress will work with 32MB set for PHP to use. You can have less, but some internal operations might need a bit more, so 32MB is safe minimal value. If you have a couple of plugins, 32MB should be enough. If you have more than 10 plugins, at least 64MB is needed. As you can see from this test, for 35 plugins I had here, you need more, and 96MB or 128MB is safe value. Some shared hosting companies will not let you have more than 64MB or 80MB, so you might have issues with many plugins if you are on some restrictive hosting companies. Consult hosting support to make sure you will get enough resources. You can use average values above to get some orientation value for memory needed.

Optimization Analysis

As you can see in the plugins table on the top, some plugins results are in different colors. Green colors are for plugins with good optimization, red colors are for plugins with bad optimization. Badly optimized plugins are always loading everything on front-end and on admin side and they take a lot of memory. Smaller plugins with less than 0.8MB of memory used are not a big problem and they usually can’t be much optimized considering number of plugin files.

Since most plugins are behaving different on admin side and front-end, they should be taking care of what will be loaded in both cases. Only files that are actually needed should be loaded. This is not always possible, but with little extra work, code can be separated to allow for better loading optimization. Considering how much memory some of the plugins use, it is essential to try and lower required resources. Most WordPress users are on shared hosting servers, and they need plugins that are optimized.

The Bad

Plugins with worst loading stats and worst optimization from this test are: bbPress, GD Star Rating, Subscribe2, The Google+ Plugin, WooCommerce and YOURLS WordPress to Twitter. bbPress should be loading parts of the plugin only when needed, considering that forum is usually separated from normal WP pages. You can have some core parts always loaded, but most things are not needed on every page. My own GD Star Rating is old plugin, and I made some optimizations in some versions, but I need to do more, and GD Star Rating 2.0 will be highly optimized to use resources. The Google+ Plugin loads many libraries that are not needed for the most part, and for a simple plugin that this should be, it uses a lot of memory. I can’t judge quality of WooCommerce plugin, but I couldn’t believe how bad loading for this plugin is, and its main file loads 32 other files always. I have noticed some other things done bad in this plugin only from first few files, but loading is really bad.

Few plugins are a bit better than this, and they have lighter red color: BackupWP, Events Manager, gdHeadSpace4, GD Products Center Pro, GD Unit Converter, GravityForms. BackupWP doesn’t need anything on front end but it still loads things always. Events Manager has some loading optimizations, but I see potential to make it much better. I have modded plugin into gdHeadSpace4 and I didn’t make changes in loading. This plugin doesn’t have big memory footprint, but some changes can be done. My GD Products Center Pro is still in beta, and I plan to finish loading optimization before releasing 1.0 version. Another of my plugin GD Unit Converter is 100% admin side plugin, yet some things are loaded always, and I will improve this soon. GravityForms requires a lot of things on both admin and front end side, but there are some things that can be optimized much better that they are now.

The Good

Contact Form 7 and WP e-Commerce could benefit from some minor changes, but they are good as far as optimization goes. Light green and good optimization is done with: Antispam Bee and BackupBuddy. BackupBuddy would benefit greatly with better main loader file that is now too big. With fragmentation of this file, will help with optimization further.

Best optimized plugins, considering plugin size and features are: GD Affiliate Center Pro, GD Press Tools Pro, GD Custom Posts And Taxonomies Tools Pro, W3 Total Cache, WordPress Download Monitor, WordPress SEO. My 3 Pro plugins all have advanced loaders and modular structure to load things need for admin side or front end. Even the code used for Ajax or saving data is separated and loaded only when needed. W3TC does a great job in loading of different plugin modules and same goes for WordPress SEO by Yoast has loader that loads different files on both sides, minimizing the impact on WordPress.

My GD Press Tools Pro and GD Custom Posts And Taxonomies Tools Pro can replace great many other plugins, and that alone can save you a lot of resources. If you can have 10 plugins and if each one uses 1.3MB on average, that is 13MB, you can replace with GD Press Tools Pro only (and it can replace much more than just 10, maybe 60 or more plugins), that will use only 2.9MB.

Loading used in my plugins

Process of loading for my GD Press Tools Pro plugin is controlled by main plugin file. First, it loads parts of gdr2 shared library (used by all my plugins). Public functions and classes are loaded next (they are used on both admin and front end side). Some parts of internal code are loaded next. Main plugin class is loaded after that, and this class is used to initialize the plugin and load plugin settings. Than, loader checks if its loaded on admin side. If it is, admin core class is loaded as well as some extra functions. And if the plugin is loaded to save settings or through AJAX call, it loads separate settings saving or AJAX classes. This all improves loading on front end side by some 30%. This loading method is changed over time, and I think that it works great right now.

Two plugins I ALWAYS use

I can’t imagine running WordPress website without my GD Press Tools Pro. It is truly ultimate administration plugin, and it does so many things that you simply need on any website: backup, sitemaps, SEO, optimization and integration… Second plugin is W3 Total Cache. Page caching, external files minify and support for CDN are something each website should use to improve website speed.

Cached Pages

If you use W3 Total Cache or some other similar caching plugin, and you have page cache enabled, it is important to know that when cached page is served to a visitor, WordPress (and plugins) are not loaded at all. All these tests are made when there is no page caching active.

Conclusion

As you can see, plugins can have big impact on WordPress. While you can have as many plugins as you like, there are things to consider:

• Compatibility: the more plugins you have, there is more chance to have some of them causing problems. Always test plugins when adding new plugin, it is rare, but it can happen. I always have local copies of all my websites, and when new things are added, I always test locally before moving to live server.
• Resources: the more plugins you have, the more server resources will be used. If you are on the shared hosting, I recommend that you review if you really need all plugins you might have already. Test different plugins you can use, because with too many of them active, you can easily hit the limits imposed by your hosting company. My GD Press Tools Pro can do many things, one of them is to measure data like this, and you can see exact impact of a new plugin added on memory, mySQL server or WordPress.
• Loading Speed: more plugins == less speed. It is very important to use cache plugins to optimize front end loading, to minify external files and use CDN to load external resources.

I hope that other plugin developers will consider the results from this article, and my recommendations to improve loading for own plugins to optimize them so that end users get faster plugins that are not needing too much resources. Lets make plugins even better.