One of the best things about WordPress are plugins. With plugins you can expand WordPress and make it into anything you need it to be. But, each plugin requires time for loading and processing and it takes up additional resources. How much exactly one plugin need?
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).
| Administration | Frontend | |||||||
|---|---|---|---|---|---|---|---|---|
| Plugin | Mem. | SQL | Time | Hooks | Mem. | SQL | Time | Hooks |
| After The Deadline | 0.1M | 0 | 0.004 | 10 | 0.1M | 0 | 0.005 | 10 |
| Akismet | 0.2M | 2 | 0.006 | 19 | 0.1M | 1 | 0.004 | 7 |
| All In One SEO Pack | 0.7M | 1 | 0.010 | 12 | 0.7M | 1 | 0.012 | 12 |
| Antispam Bee | 0.3M | 1 | 0.004 | 2 | 0.2M | 0 | 0.005 | 6 |
| BackupBuddy | 1.0M | 1 | 0.099 | 30 | 0.6M | 0 | 0.009 | 9 |
| BackupWP | 0.5M | 0 | 0.007 | 9 | 0.5M | 0 | 0.008 | 9 |
| bbPress | 4.0M | 0 | 0.047 | 216 | 3.8M | 0 | 0.061 | 205 |
| Better WordPress Google XML Sitemaps |
0.6M | 2 | 0.010 | 12 | 0.7M | 2 | 0.013 | 12 |
| Contact Form 7 | 0.5M | 0 | 0.007 | 16 | 0.4M | 0 | 0.008 | 16 |
| Dev4Press Updater | 0.3M | 2 | 0.007 | 5 | 0.3M | 2 | 0.010 | 5 |
| Events Manager | 4.2M | 1 | 0.051 | 60 | 3.0M | 1 | 0.042 | 54 |
| gdHeadSpace 4 | 0.7M | 1 | 0.013 | 20 | 0.7M | 1 | 0.013 | 8 |
| GD Affiliate Center Pro | 1.1M | 0 | 0.017 | 16 | 0.7M | 0 | 0.013 | 9 |
| GD bbPress Attachments | 0.2M | 0 | 0.003 | 1 | 0.2M | 0 | 0.004 | 1 |
| GD Pages Navigator | 0.5M | 0 | 0.008 | 3 | 0.5M | 0 | 0.009 | 3 |
| GD Press Tools Pro | 2.9M | 0 | 0.032 | 78 | 2M | 0 | 0.027 | 38 |
| GD Products Center Pro | 2.4M | 0 | 0.029 | 28 | 2.2M | 0 | 0.032 | 17 |
| GD Star Rating | 3.8M | 0 | 0.043 | 12 | 3.8M | 0 | 0.047 | 14 |
| GD Custom Posts And Taxonomies Tools Pro |
2.8M | 0 | 0.039 | 61 | 1.7M | 0 | 0.027 | 23 |
| GD Unit Converter | 0.5M | 0 | 0.007 | 4 | 0.4M | 0 | 0.010 | 4 |
| GravityForms | 2.9M | 0 | 0.025 | 4 | 2.8M | 0 | 0.030 | 4 |
| JetPack | 0.7M | 0 | 0.008 | 5 | 0.7M | 0 | 0.009 | 5 |
| Lightbox Plus | 0.7M | 0 | 0.011 | 8 | 0.7M | 0 | 0.013 | 7 |
| Regenerate Thumbnails | 0.1M | 0 | 0.002 | 1 | 0.1M | 0 | 0.002 | 1 |
| Subscribe2 | 1.4M | 0 | 0.013 | 5 | 1.4M | 0 | 0.016 | 5 |
| Subscribe to Comments Reloaded | 0.3M | 2 | 0.005 | 17 | 0.3M | 2 | 0.006 | 3 |
| SyntaxHighlighter Evolved | 0.3M | 0 | 0.004 | 1 | 0.3M | 0 | 0.005 | 1 |
| The Google+ plugin | 1.6M | 1 | 0.032 | 10 | 1.6M | 1 | 0.032 | 6 |
| TinyMCE Advanced | 0.1M | 0 | 0.002 | 13 | 0.1M | 0 | 0.002 | 13 |
| W3 Total Cache | 1.4M | 0 | 0.019 | 46 | 0.2M | 0 | 0.008 | 19 |
| WooCommerce | 3.9M | 0 | 0.056 | 164 | 3.7M | 0 | 0.059 | 148 |
| WordPress Download Monitor | 1.5M | 1 | 0.036 | 7 | 1M | 1 | 0.033 | 7 |
| WordPress SEO by Yoast | 1.2M | 4 | 0.018 | 21 | 0.7M | 4 | 0.014 | 16 |
| WP e-Commerce | 0.8M | 1 | 0.012 | 5 | 0.9M | 1 | 0.011 | 5 |
| YOURLS WordPress to Twitter | 1.7M | 0 | 0.022 | 60 | 1.5M | 0 | 0.025 | 53 |
| Average | 1.3M | 0.57 | 0.020 | 28 | 1.1M | 0.49 | 0.018 | 22 |
| Total | 45.9M | 20 | 0.708 | 981 | 38.6 | 17 | 0.624 | 755 |
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:
| Colors: | Average optimization results |
|---|---|
| Bad optimization results, must be improved | |
| Not good, should be improved | |
| Good optimization, some space for improvement | |
| Excellent optimization results |
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.
| Administration | Frontend | |||||||
|---|---|---|---|---|---|---|---|---|
| Test | Mem. | SQL | Time | Hooks | Mem. | SQL | Time | Hooks |
| Clean WP: Before plugins loader | 13.2M | 1 | 0.146 | 344 | 13.1M | 1 | 0.172 | 307 |
| Clean WP: After plugins loader | 4.7M | 32 | 0.236 | 137 | 1.0M | 20 | 0.121 | 43 |
| Clean WP: Total loading results | 17.9M | 32 | 0.381 | 481 | 14.1M | 21 | 0.121 | 350 |
| WP with plugins: After plugins loader | 23.0M | 235 | 1.206 | 893 | 9.7M | 183 | 0.575 | 305 |
| WP with plugins: Total loading results | 81.3M | 255 | 2.055 | 2221 | 60.2M | 200 | 1.354 | 1364 |
| Total 35 Plugins Impact | 63.4M | 223 | 1.674 | 1740 | 46.1M | 179 | 1.233 | 1014 |
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.
wow, I would have never guessed that bbPress and woocommerce were that bad esp considering the people being the projects.
I knew that bbPress is bad on resources usage, it was the same with early alpha and beta versions. It is better than it was back than, but it has a long way to go if they want to make it optimized. Since WooCommerce is forked from JigoShop they have same issues with loading, and both are using almost the same amount of memory, and add same number of hooks. It would need a day or two work on these plugins to make the loading much better and optimized, lets hope the authors read this post and decide to do it.
Great analysis! Is it possible to benchmark themes using this cool plugin? I curious if premium WP theme frameworks are optimized. Thanks
Thanks for the comment. Plan is to do a benchmark for themes also, and I hope to do it next month.
I will really look forward to that !
Great article, Dave
A good read, didn’t know about GD Press Tools either – looks really powerful.
I’d love to hear more of your thoughts/ideas on optimisation, for WooCommerce specifically. While we have taken steps to improve speed (using transients cache for example) we’re aware theres much room for improvement so any help/advice you can give would be appreciated. Hit me up via email or GitHub https://github.com/woothemes/woocommerce if you want to have chat 🙂
Thanks for the comment Mike. Glad to see a Woo developer stopping by. I will send you email next week with few suggestions on what to change. Good to know that you use transient cache, I do that also with most of my plugins and with my xScape Theme Framework.
I look forward to it – I’ve already made a tonne of progress in our development branch https://github.com/woothemes/woocommerce
Down about 1mb on my test install.
I am writing a long article/tutorial on optimization, and it will be ready soon, I want to include as much tips and advices as I can. I also plan to have monthly testing for plugins, and to see if the authors are working on optimization, and not only features. It should be released first week each month, and it will test last official release for tested plugins available in the week before the testing. Number of plugins will be expanded to include more (I got many suggestions about this), and number of tests will be expanded over time to include more performance details.
I am glad to hear that WooCommerce is on the right track and I am looking forward to testing it. Considering popularity of the plugin, it will be featured in future tests.
I have to say I’m very disappointed with bbPress. Your analysis simply confirm my reservations towards this plugin. When you go to home page of bbpress.org you read great promises which turn to be a typical sales pitch.
“bbPress is forum software with a twist from the creators of WordPress.” – I would expect more from creators of WordPress.
“Have you ever been frustrated with forum or bulletin board software that was slow, bloated and always got your server hacked? bbPress is focused on web standards, ease of use, ease of integration, and speed.” – promises, promises.
Thanks for the comment Frank, it is always appreciated. Right now bbPress is half way there. It is useful, easy to expand and it has good basic templates set. But, it is not optimized, it is not easy to integrate with every theme (one of the most important promotion points). It is lightweight in terms of size, but it is not lightweight on resources. GD Press Tools Pro is 3 times the size of bbPress, it has 20 times more features and functionalities (rough comparison), and yet it uses only 2MB on front end, where bbPress uses 3.8MB. All due to bad (or non existent) optimization. I hope that next major version of bbPress brings core improvements, and no new features. I fear that new things will make things worse, and right now it needs to optimized before it gets too far. And, I agree Frank, I too expected more from it based on who created plugin. Lets hope this benchmark helps improving performance of some plugins instead of adding new features.
It would be really awesome if you would consider writing up a few notes on optimizing bbPress. Having run some very large forums with vbulletin it has been a huge concern of mine switching over to bbPress.
JJ is an absolutely amazing and committed developer and without him there would be no bbPress, but I also know that he is totally overwhelmed with work. I’m sure we would all benefit from more contributions.
btw
Your not kidding about integrating with other themes. It took me a long time to get proficient at merging bbPress with custom themes. Once I got it all figured out though, it’s not all that bad.
Optimizing bbPress is no simple thing. I understand why some of the things are done with that plugin the way they are, and for the most part it mimics the WordPress loading. But, what works for WordPress can’t be used for plugins. I am preparing an article about plugins optimization, and many things from there can apply to bbPress also. All in all, it is not that bad, WordPress uses 20MB on front end, bbPress ands another 4-5MB. But, the problem is the you will add more plugins, most of them will not be optimized as well, and that memory usage will grow, and it will get slower. And I know that many developers will talk against such optimization as pointless considering today available servers and hardware. But, most users can’t afford (or don’t need) VPS or dedicated servers, they used shared hosting and every MB of memory counts there.
thankfully for me I run dedicated servers so don’t have the issues most people have. Still, it is nice to do everything possible to keep everything as optimized as possible. I look forward to reading your article about plugin optimization.
Really the biggest issue I have seen is when displaying the topics table on the homepage of the forums. The forum I am working on now only has 300k topics but still the load time on the homepage is horrible compared to all other pages.
I’m guessing as it’s a custom theme that I built, that the problem more likely lies in my query as it seems to count the entire db table in order to load the page links. (page 1 of 11k..)
I have made sure to follow JJ’s advice and not use any private/hidden forums as it absolutely kills performance. Beyond that I have not yet tried to take any optimization steps.
I think that many things in bbPress were not made with scalability in mind. Even WordPress is not at its best for large number of posts or data. Last year I have been working on a project that had over million posts with planned 100.000 to be added each month. WordPress (and bbPresstoo) query engines are neat and clean, but they are not that scalable. And I had to write my own query object to handle things differently. My query object was 5 times faster than WordPress for same set of results. bbPress works with a complex data structures, more complex than normal WP queries are made for, and it needs to handle things differently in every aspect. Again, caching is one way to go, but optimizations must be made at one point, or the whole thing will be getting slower and slower.
Right now bbPress is a very good plugin, and I will choose it over any other forum when WordPress is used. But, I think than next major version of bbPress must rethink many plugin areas to get optimized and fast. I had learn the hard way all this with my projects in the past, and I am sure than many developers had similar experiences. Optimization first, new features later.
Your right, bbPress is the only choice when it comes to a forum for WordPress. I wouldn’t even consider another plugin as bbPress is not only easy to work with, but JJ is the best. With a developer like JJ, I am sure that bbPress will only get better as time goes by.
I sure hope that we will see improvements down the road. I would like to help with bbPress development, but that is impossible considering how many complex plugin I have already. I will continue making plugins for it, and add support for it in my plugins. The more people get involved around it, faster it will grow and get better.
Great article!
Have you ever tried Hyper Cache Extended? I use that and a modified “Better WordPress Minify” plugin for caching.
It doesn’t do the CDN but it’s faster than W3 Total Cache for me.
Cheers, Paul.
Thanks for the comment Paul. CDN is a must for any website with high traffic, minify and page caching is not enough. And running one plugin like W3TC is much better than running 3 plugins for same thing. They maybe individually faster, but combined will not be.
You should put Nextgen Gallery on that list. A popular plugin that takes away so many resources.
Thanks for suggesting. I plan to have regular testing of plugins every month. That way we can see if plugins have improved over time, and to add more plugins to the mix. Every first Wednesday in every month, new list will be published, and we can keep track of the plugins and their resources usage.
You’re welcome. Looking forward to more tests. It would be cool to also see the number of extra server connections caused by the plugin in the frontend.
I am trying to devise more tests, including debugging of the AJAX calls. It will get expanded over time.
NextGen Gallery review would be nice indeed, especially it’s used on so many sites.
I can’t write full review, since I don’t use NextGen Gallery. But, its loading performance results are included in last week monthly testing.
Thank you that helped. A review for Custom Fields Template would be cool too!
Re “WP e-Commerce” in the list, is it getshopped or wpmudev’s plugin ?
Can you add these plugins for future benchmark
http://wordpress.org/extend/plugins/wordpress-ecommerce/
http://wordpress.org/extend/plugins/buddypress/
It is getShopped plugin here. I will add both plugins next time.
I read an article a few days ago(being honest i don’t remember where, but if i will i will post the link here) Where they said that bbPress has being optimized and they did some tests and the resource usage are a lot lower than before. They will make a few tests more and that they will change this version in march or something like that.
It would be great to see optimization for bbPress done, I am looking forward to next major release of it.
I have long thought it ‘odd’ and more than slightly ‘pregnant’, that although WordPress is expressly designed to use a simplified “core”, and then add additional/optional functionality using “plugins” … we can really only make extremely limited use of the full array of add-on possibilities.
“Step right up Ladies & Gentlemen, Ten-thousand Plugins, to perform hundreds of different classes of valuable functions! Pick any six! Adventurous folks – try 12!! (“35? aren’t ya getting a bit carried away there?”)”.
I assume that eventually one or more methods will exist to ‘compile’ one’s plugin inventory, so that outrageous overhead is obviated, and one can actually select from a wide range of interesting & valuable plugin-resources … and still have a WordPress installation that is not excessively bogged-down.
Check out TinyMCE in the Includes. It’s 143 files in 47 sub-directories, with a “plugins” directory containing 13 plugins sub-directories. This entire edifice is heavily invoked during normal WordPress operations, reasonably-transparently. User-installed plugin collections should be able to work at least this well … but they don’t, and not by a long-shot. (In fact, TinyMCE deals with demands to which user-plugins are (mostly) not subjected. System-managed plugins should be able to work more efficiently that will a UI editor like TinyMCE.)
Obviously, we’re not there yet, but the situation appears pregnant with opportunity.
Article on plugins optimization is now available:
http://www.dev4press.com/2011/tutorials/wordpress/practical/how-to-optimize-plugin-loading/
Thanks for doing this valuable study! I’m disappointed to see Gravity forms in your “needs improvement” category. I’ve seen this plugin recommended in several places and I use it on all of my sites. I like your idea to have regular testing so we can see improvement in the plugins over time.
I love Gravity Forms, and it is one of the best plugins ever made for WordPress, and I use it on this website also. But, in terms of loading there is a lot of room for improvement. This test is not about features or usability, it is only about resources usage and loading.
Glad to hear that you are a fan of Gravity Forms too. Hopefully they will listen to your recommendation and improve the loading time.
Interesting article.
I have seen other articles that refer to performance hits due to plugins.
However, it seems like all of them (including this one), have W3TC turned off for the testing.
This is frustrating to me. Since it seems like the point of these articles is to point out that high traffic sites will be adversely affected by lots of plugins. BUT, high traffic sites ARE going to have caching turned ON.
To be really useful, I think you should also report on the speed/memory hit of a plugin WITH cache turned on.
I do care about the non-cache version, especially on the admin side.
But most visitors are going to see the cache output.
Thanks for the comment. If you use page cache with W3TC or similar plugin, there is no point of making tests like this one. When W3TC caches the page, the whole page is rendered and rendered output saved into a file. When the cached version of the page needs to be displayed, this is done using .htaccess file that loads this HTML file and completely skips loading of WordPress. So, when page cache is used, WordPress and plugins are not loaded at all.
When using object or database cache in W3TC, results can also be different, but both these caching methods can cause massive problems (especially on admin side), and I don’t recommend using them.
I guess that is my point then.
Some people read a post like this and think “Oh crumb, my plugins are ruining my performance” even if they have a caching.
I’m glad you posted in your reply that plugins are not hurting performance on sites with page caching enabled.
I think that would be a nice thing to remind people of when posting performance analysis posts such as this.
Yes, that is correct, and I have included a notice in the article to point that out. Most users, however, have memory issues on admin side, since admin side can use up to twice as much memory front the front end with same plugins active. And many websites that rely on members visits, don’t have caching active for logged in users, so there plugin have measured impact.
Hi Millan, it might be an idea to include the plugin version that was tested in the table too?
Last week I started monthly testing, and there there is a version and more info about all tested plugins. On first Wednesday of each month, new test results will be published with updated and added plugins.
I see it now thanks 😉 Great work by the way!
Thanks! Good news is that some plugins are already improving, and new tests in February will show that. It would be great to see more such improvements in the future.
Dunno how much overhead this helps, but at least we can check for a bbpress page with is_bbpress and disable loading some stuff. I use the bbpress toolbar as well, so checking if its a bbpress page or not, I could at least stop 5 script from loading. http://vudu.me/2rc Is a little info on that on VoodooPress.
Thanks for the comment. Yes, there are ways to remove some things, but plugin should be optimized in the first place to take care of own code and files.
Oh absolutely! THis is just a band-aid type thing that comes in handy while hoping things get optimized!
Milan,
Really great article! Very useful information. The Woo Commerce thing was an eye-opener, given how excited people were when that came out.
I’m always amused by newbies who use 35 plugins, host on Godummy, and then are aghast to find out that their site will barely run, and crashes upon WP upgrade.
Say, off-topic… the paragraph text above is a little choppy in Chrome. I bumped it up very slightly to 1.1em, and that smoothed it right out!
Keep up the good work!
Thanks for the comment Dave. WooCommerce looks like a solid plugin overall, and I have reliable information that WooThemes developers will optimize it soon. Hopefully more developers will pay more attention to resource usage and we will get faster plugins.
Thanks for the great review, Milan.
I am looking forward to read your monthlies too. If I may make a suggestion, maybe you can include WPML into the mix in one of your upcoming test rounds?
Cheers,
Piet
ah man this is awesome. i always wondered that. I see a few plugins i use that got a “poor’ score on your test. good to see i dont use too many of those.
Great Post Milan, thanks for that – please allow me one question:
“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.”
I am pretty shure i saw a list of plugins that could potentially replaced by gd press tools (which i bought already) but i cant find it anymore. Can you point me out for it?
Thanks
Mike
I don’t have that list anymore. But, I am pretty sure that list would include over 100 or maybe more plugins.
It is exciting to see this project, Milan!
This is an investigation that has been sorely needed. That you describe the results (and limitations!) carefully, and provide a separate tutorial on the topic, is very generous.
Thank you!
Thank you Ted!
Thanks for such an interesting and useful article.
It is awesome to see that the WP e-Commerce Plugin does better then the other e-Commerce Plugins.
We too are interested in working with you to ensure that WPEC is as optimized as it can be for now and for future versions.
I’m also a little sad that bbPress isnt there just yet in terms of optimization. We use it and love it and we just hope that Automattic leave JJJ on the project so that it becomes all that it can be. We’ll never stop using it though… we’re WordPress guys 😛
Thanks for stopping by Dan. Many users wanted to see how currently best eCommerce solutions are doing in terms of optimization. In terms of usability it comes down to personal preference or some specific features, but it is good to know how much resources plugin will use. I will contact you via email next week, in connection to my current project, and we can discuss how can we work together.
bbPress will get there, even now it is not so bad considering that it is the best forum for WP I have tried, and optimization will come with next few versions. I have some ideas about it, and I am sure that JJJ and other developers will think of something to make it even better.
MillaN,
I am a little surprised you didn’t mention the the “P3 plugin from GoDaddy” in this context, because, of course, it too creates a profile of your WordPress site’s plugins’ performance by measuring their impact on your site’s load time.
You just click “Start Scan” to run an automated scan of your site. The scanner generates some traffic on your site and monitors your site’s performance on the server, then shows you the results.
How accurate are these results? The results have an inherent margin of error because of the nature of the tool and its multi-layered design, but the plugin changes the environment to measure it, and that makes it impossible to get completely accurate results.
It gets really close, though! The “margin of error” on the Advanced Metrics page displays the discrepancy between the measured results (the time for your site’s PHP code to completely run) and the expected results (sum of the plugins, core, theme, profile load times) to show you the plugin’s accuracy.
If you want more accurate results, you’ll need to resort to a different profiler like xdebug, but this will not break down results by plugin.
With this information, you can decide what action to take, but of course, the big question then is – if you’re not the developer, exactly what do I do with these results?
But I guess, at the very least, you could ask the authors to improve them, or if they won’t/can’t, stop using the worst plugins and try to find something better. I did that recently and studied the effect of various “Lightbox” type plugins and was very surprised to see just how much Fancybox for WP is so much better than all the rest (as far as share of site load-speed goes, that is).
Terence.
P3 plugin from GoDaddy is interesting plugin and I was excited to see it, but I was very disappointed when I tried it. This plugin tries to act as a profiler but it doesn’t work as profiler at all. Profiler is hooking into existing code and works from the inside, this P3 plugin is not doing that. I have run hundreds of tests with it, and on more than half of those plugin that had worst performance was: P3 plugin from GoDaddy. Results are completely unreliable, since I made a dummy plugin that is made to use large amount of memory and to take very long time to load, yet P3 in most tests didn’t even registered it. Also, during 6 hours I tried it, I had to restart my server 6 times because P3 crashed it. Right now P3 plugin from GoDaddy is a good idea, but for practical use I can’t see a way to get reliable results from it.
All these test information should be much more useful to developers. As I said many times, if you like a plugin you are using, it is important that it plays well with other plugin, and if it uses more memory is not that important, because you like it and it is working for what you need. I use bbPress despite it results here, it is a great plugin.
I disable plugins like backupbuddy and wp optimize when not using them. Will this help?
Interesting post.
Worth noting that you probably used Events Manager version 4, version 5 came out late December and has had some major performance improvements (and more on the way as we go).
Thanks for the comment Marcus. Yes, Events Manager 5.0.1 is tested in monthly testing in January, and while it uses a bit less memory, it is still not there. But, for the next test in February, I already started choosing new plugins and updating old ones, and EventsManager is getting better (I used 5.0.3). I am looking forward to this, and I was using the plugin for testing and bit more, and I like really like it.
Someone just showed me this, so I’ll be keeping up with your future posts from now on 🙂 It’s very useful to see, and great that you update the results regularly!
Out of curiosity, how many events do you test with?
Yes, well that is very important, to see how the plugins are doing over time. I understand that sometimes features for the plugin are more important, but when you get that right, you have more time to improve other things. So, good plugins evolve over time and these tests will hopefully show that. Few plugins in the next month tests will show improvements based on versions released after January tests and I am pleased that these tests are having an effect.
For the performance testing I use plugins set by default, but for plugins like this one I took time to make some test data, but it doesn’t show any measurable difference in this case.
whilst motivation to speed up was always here for me, it is a good motivator anyway. as you say atm we’re back onto adding features 🙂
the only fault I find with comparing EM to a few others on here is that you can have 1000s of events (I test with 1000s when possible) and that becomes a different ball-game.
Thanks for this article!
I’ve build a complex site that uses WooCommerce and Gravity Forms (among others). It feels somewhat slow (without cache, on an “empty” dev server). Seeing this memory usage chart confirms my gut feeling.
I’m really happy that my customer opted for a robust hosting platform. 🙂
Hopefully WooCommerce team sees this, and makes some optimizations.
Thanks for the comment. I know that WooCommerce team is on this and improvements can be expected. Either way, I too use bbPress and GravityForms, and these results don’t mean much if you like the plugins you are using, and you use cache and some quality hosting.
MillaN,
Please can you explain the results table above for me. In particular, how have you arrived at your colour rankings?
GravityForms 2.9M 0 0.025 4 2.8M 0 0.030 4
Subscribe2 1.4M 0 0.013 5 1.4M 0 0.016 5
WordPress Download Monitor 1.5M 1 0.036 7 1M 1 0.033 7
Picking out these 3 plugins (Subscribe2 is the one I write) as comparators. GravityForms uses more RAM, takes longer and uses 1 less hook and is ranked ‘should be improved’
WP Download Monitor uses about the same amount of RAM takes longer and uses more hooks and gets an ‘Excellent’ rating. Yet Subscribe2 which performs better in terms of speed than both of these, uses similar numbers of hooks, SQL queries and similar or less RAM gets a ‘must be optimized’ result.
The rating seems completely arbitrary to me. While I understand and accept all you say about optimizing code you seem to have taken no account of the complexity of what the plugin is actually deliver either. You cannot expect Microsoft Word to use the same RAM and resources as NotePad when it offers so much more.
If there is a legitimate reason for plugin to use the memory it uses all the time, that is OK. Problem is if the plugin loads things it doesn’t need all the time, and that’s why there is a difference in color or optimization grade. WP Download Monitor uses small main file that determines where the user is (admin or front) and loads different parts of the plugin, or attached different hooks.
Subscribe2 has huge 4000 lines long main file that includes almost every piece of code used by the plugin and loads it always, regardless of the need for it. It doesn’t matter how much memory is used, all it matters how much memory can be used if optimized properly, and Subscribe2 is not. This main file should be split into 3-4 smaller files that would be loaded if they are needed, and that will lower memory usage and make it load faster. Once Subscribe2 is optimized this way, I am sure it would use under 1M on both admin side and front.
WordPress SEO by Yoast is plugin with great loading optimization, and it is 3 times the size of Subscribe2 (amount of PHP code),and yet it uses 15% less on admin side and 50% less on front end than Subscribe2, but its code is split into many small files loaded only when actually needed or used.
Thanks for your honest response, you have confirmed what I thought.
You are basically saying that Subscribe2 uses too much RAM as it loads as a single class – despite the evidence you also present that indicates that this class only hooks where needed, makes few unnecessary SQL requests and does not massively add to page load times.
Maybe I’m being overly defensive but that seems a bit harsh to me. Personally, I find the code much easier to handle in one file containing all the functions rather than trying to split it out. You see a great number of the functions I have are needed on the front end and the admin area. Splitting into 3 or 4 files would just results in always including 2 or 3 of those files with the others being essentially empty.
I will however test your theory and see if splitting the files out does reduce RAM use. I still cannot understand how a plugin script of less that 200kilobytes in size needs 1.4megabytes of RAM to run though!
I expect that all PHP/WordPress developers should be informed about the way PHP works. If your file is 200KB in size, it doesn’t mean that it will take 200KB of PHP memory. When loaded, file is interpreted into the operation code that is actually executed, source code is not something PHP can run directly. How much memory this code requires depends on data structures and code size. So, the interpreted code would need from 3 to 10 times more memory than the size of the source files. WordPress has about 3MB of PHP source code, yet when loaded it needs from 15 to 20MB of memory to run.
If you have parts of code needed for both front and back end (as any plugin would need), you put that code in a file loaded on both sides. You need one file for admin only code and one for front end only code. And main file to load these 3 files based on the location. This is simplified way to make the code optimized, depending on plugin size and features it is usually fragmented further.
That’s maybe because you expect that PHP/WordPress developers have some level of training in coding and/or PHP.
I have none. This is a hobby for me and the last time I formally learned anything about computer languages was dBase3+. I spend enough time remaining up to date for my day job in healthcare as this pays my mortgage. As I said before, I need to keep it as simple as I can for me as from my perspective this is supposed to be something that’s fun and that I enjoy.
Well, I can understand that, but don’t blame the results because of that. Based on all reactions for the optimization articles, all the emails I got, a lot of WordPress users care how the plugins they use are working and they want them optimized. And that’s why I have written optimization tutorial also.
Matt, do not take this the wrong way, but while everyone appreciates the time it takes to develop plugins for free on one’s own time, I think you are missing hte point point here.. You are so busy being defensive about this being a hobby, about you not having training in coding an PHP that you are missing the fact that NONE of this matters.. The point of this article was to bring to the attention of those interested (site owners, site developers, and even plugin authors) that there is room for improvement in some plugins commonly used. This doesn’t appear to be intended as a slight against you (as you seem to have interpreted it as based on your two responses) it was simply meant to be helpful information.. Instead of taking it as information you could use (since by your OWN words, you are not a trained coder) you seem to be a tad offended by it.. **shrugs**
DivaVocals,
Of course I’m going to defend my plugin! I’m quite open to criticism if I believe it’s fair criticism.
The purpose of this article is about assessing the load time of plugins as assessed by RAM usage, SQL queries, hooks used and time taken. All of this was done using another plugin – so very objective. I feel that Subscribe2 scored comparatively well against other plugins.
BUT, it was given a rating of “Bad optimization results, must be improved” purely based on the fact that it is one file with one class.
No, forgive my defensive stance but that’s not very objective now is it? To define a series of tests, get your results and then essentially ignore them because subjectively you feel the plugin code could be arranged a little better.
Then, to top it all since I’ve started looking at splitting subscribe2 into several sub-files I have realised I would have to buy the benchmarking plugin to see if it makes any difference. If this really if for plugin developer benefit, how about giving free access to the benchmarking code?
Well, now you know! 🙂
I’m not a coder, and can only “script” in PHP (in my own opinion), but this stuff is something I had to learn. Heck, the basic info is in the Wikipedia article…
Opcode caches and such may require some knowledge of the underlying stuff, and those are often needed when the sites and CMS get bigger. Plugin optimization and code quality are an issue for a site builder like me.
Now let’s see how many of those plugins has PHP errors in it if we enable debugging in WordPress 🙂
Excellent idea! I will try to add PHP warnings and WP deprecated warnings next time.
I know for a fact that BuddyPress is horrible. If you enable php errors it will brake the whole website.