Plan was to have more, but this first monthly measurement will have 30 instead of 50 plugins. But, this list will change over time, and new plugins will be added to the mix, and some of previously tested will be removed. But, from next month I will have publicly available table with all historical data for all tested versions.

All the data displayed here may vary depending on server configuration and other factors. Data here doesn’t say anything about quality of the plugins or their usability, it is only a test of resource usage. Also, some of the plugin can use different amount of resources depending on the plugin configuration, and all tests here are done with default plugin configurations. There is no way to test complex implication of different settings or method of work for a test like this.

Measurement Process

For this first monthly test I have tested 30 plugins. All tests are done with a single installation, and WordPress 3.3 was used. Tests are done on the local server with PHP 5.3.8. All measurements are done using GD Press Tools Pro 4.3.2 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.

To get as accurate resource usage I spent some time testing each plugin individually to measure used memory during loading and after all plugins are loaded. Some plugins load most of its files hooked to WordPress action, and not during loading of the plugin. Again, this number is not 100% accurate, but it is very close. As these tests are improved over the next few months, the numbers can vary a bit.

Plugin Grading

Each plugin is graded on a scale from 1 (worst loading optimization) to 5 (best loading optimization). This grade is not only connected to used resources, but to actual method of loading plugin uses. Plugins that got grade 1 have no loading optimization and they always load everything (or almost everything) and that uses precious server resources always, even if the plugin doesn’t need all things loaded. There is no perfect loading method, because it would be very complicated to do. But grade 5 goes to plugins that use loading optimization, that care about what WordPress is executing, and how much resources are used actually. Change column for this first test is empty (well it is set to =), and it will change with next test depending on the progress plugin developers do with their plugins.

To give plugin a grade, I have analyzed plugin loading process and I have taken into account how much resources plugin takes due to loading method it uses. Best loading optimized plugin I know is my own GD Press Tools Pro. If this plugin is to load all its parts always it would use twice as much memory and it would need much more time to load. Even with all that, I always work on further changing how the plugin loads trying to make it better. Plugins close or better to the level of optimization in GD Press Tools Pro will be graded 5 also. If the plugin uses different amount of memory on front and back end it doesn’t mean that the grade will be higher because of that.

Before we go on to the testing, read the original article from last month regarding the plugin loading process that will give the reasons for such testing and why it is important to make sure that plugin loads parts it needs only for admin side and front end: Measuring impact of plugins on WordPress loading.

Tested plugins basic information

30 tested plugins are listed in the table below. Beside basic data in first 5 columns, you can see if plugin adds own JavaScript, how many AJAX handlers uses, how many cron jobs can be registered by this plugin (it doesn’t mean that all will be registered always) and how many widgets plugin can add.

All tested plugins, but one, used the internal WordPress AJAX handling. Contact Form 7 uses own handler and that is not something I can recommend. Using WP handler is best solution considering that it is already written with security concerns in mind and it is very easy to use, making plugin fit better with WP development concepts.

Resource Usage Test Results

Here is the list of all plugins in this test, and the results.

So, let’s start with the good. My GD Press Tools Pro is very fine tuned to load different plugin parts when needed, and it is always evolving and improving. GD Unit Converter on the original test was badly graded, but with latest version I have changed it all, and it graded 5.  W3 Total Cache has very good optimization of resource usage, and loads a lot of things when needed only. Loader maybe a too complicated for my taste, but it is effective. WordPress SEO by Yoast is a great example of well written and optimized plugin.

Plugins with potential to be better are many, and all grade 3 and 4 plugins fit into this group. NextGEN Gallery is almost there, and with a bit more work, it can go to grade 5. I plan to improve my own plugins further, and work on that is in progress for some of them, so I expect them to be improved in the next tests.

Grade 2 plugins have only some elements of optimization, but they are close to grade 1. Adminimize plugin shouldn’t even load on the front end except for some elements, and that needs to be optimized. Gravity Forms is a great plugin, that needs a long way to go but at least has some sort of loading control.

As for the grade 1 plugins, the results may be surprising considering how popular some of this plugins are. WooCommerce started from JigoShop, but almost nothing is done to change awful loader JigoShop has, so they are both graded 1. Mike Jolley from WooThemes told me that they are working on improving WooCommerce so, I am looking forward to that. bbPress also has no optimization at all, and even from latest sources for 2.1 I don’t see any improvements there, and that is not a good sign.

Why is this all important?

WordPress loads plugins on both admin side and front end. But, most plugins don’t need to behave same way in both cases. Many plugins are needed only on one side. So, a plugin can be used on admin side only, and has no use on the admin side. If the plugin is not optimize to load files only when needed, it will take same resources on front end also, even so it is not needed or used, and that is a waste of server memory and time to load. Most plugins have two parts, one to be used on admin side to set the plugin, and other that works on the front end. No need to load everything on both sides, load only what the plugin needs, and it will use least amount of memory and it will work faster.

Should you care? No. And yes. If you run few plugins, than amount of memory used is not that relevant. If you run your website on VPS or dedicated server, you have much more memory available, but if you are on the shared hosting, every MB can be critical (especially if the hosting company limits it). This test is not about plugin quality. If you prefer using All In One SEO, don’t let the lower grade be a big concern because WordPress SEO plugin got higher grade. This tests show how the plugin handle resources nothing more.

Improving results

I am sure that many developers will say that these results are not important, but considering that most of the WordPress users are on shared hosting with limited memory and resources available to them, this is most important thing to have plugins they need and still have server running fine. Same thing goes for themes also. Dev4Press website uses 20-21 plugins for the last year, but with theme (my xScape Theme Framework based) and my plugins optimizations, I managed to lower memory usage from 60M last January to 40M today.

I recommend to all plugin developers to read my tutorial: How to optimize plugin loading. Most of the things from it can be applied to all plugins, and all users will benefit from developers investing extra time to optimize own plugins.

Edit 2012.01.05. – Updated grade information.
Edit 2012.01.06. – Added few more explanations and link to original loading impact article.

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.