Subscribe2 is free and excellent plugin for email subscriptions about new entries on the website. Plugin is created by Matthew Robinson and to get more info about it visit the plugin website: Subscribe2 Plugin.

Previous benchmarks I did for this plugin showed that it used too much memory and that all the code was in one PHP file. For benchmark done in January 2012 I was testing Subscribe 7.0.1 released in November 2011. And based on those tests, I gave the plugin lowest grade for the optimization. My grading was not based only on memory usage or SQL queries, most important factor was based on the code review and the potential for optimizing it. There are instances where plugin uses a lot of memory and I still gave it good grade because of the way plugin loads and works. So, benchmarks included both measured data and optimization analysis.

Subscribe2 author Matt joined the discussion and he was defensive of the plugin and its performance. But, the great thing that come from the discussion is that Matt decided to give optimization a try, to see if my instructions on that really work and how he can improve his plugin. And it really did work, and Matt did a great job on optimizing Subscribe2 plugin. Over the last 2-3 months Matt and I talked about the optimization and I did more benchmarks, testing his optimization process that ended up with the release of 8.0 version of the plugin. Matt also provided me with a short text, where he describes his work on optimization.

Matt:
About two months ago as I type a user of my plugin drew my attention to a benchmarking assessment done at Dev4Press.com that had assessed and benchmarked a substantial number of WordPress plugins. This site noted that Subscribe2 had “Bad optimization results, must be improved”. Now I visited the site and noted that Subscribe2, in comparison to other more highly rated plugins, loaded pretty quickly, did not use much resource and used minimal SQL queries. I started to question the author of the review article, Milan Petrovic, about exactly how he had arrived at his conclusion that Subscribe2 was badly optimized in light of these comparatively good optimizations.

If you want to read the full discussion we had back in January through comments, you can revisit original plugins benchmark article here: Measuring impact of plugins on WordPress loading.

Matt:
It became apparent that Milan was not only taking into account the raw data gleaned from his analysis of the execution of the plugin code but also reviewing how the code was written and thus optimized. He recommended that I break Subscribe2 down from essentially a single file into several classes and subfiles. Now, I have to say the prospect of doing this did not fill me with excitement. I am not a coder or programmer in my day job, I see Subscribe2 as a hobby. It’s code I use on my sites and I make it available to the wider WordPress community as it seems that a few of you find it useful too. Since I have no real formal education in coding I’ve learned everything I know from simple trial and error and through reading lots of documentation about PHP and WordPress functions. I find it much easier to have all the code in one place – one file.

Great thing about WordPress is that making a plugin is very easy. And you can always start from simple examples, from documentation and you don’t need to know too much about PHP. In my experience, starting with simple plugin you can put all the code in one file. Start adding more code, and that file grows. And if you end up with the file that has 200KB of code, PHP will need a lot of memory to load file and to interpret it into operation code that is than executed. That code can take a lot more memory in the end.

Matt:
That said I thought I would test out Milan’s assertion that breaking the code up would make a difference. I’m a scientist really and I love to challenge theories, in this case I was skeptical at the start. So, I set about breaking Subscribe2 into 5 files, a loader, a core class and then 3 extender classes for the front end, the admin side and a special case for multisite installs. Once I’d finished this I emailed the code to Milan and he happily tested it for me. I was very surprised to see that the RAM usage and loading time on the front end had been halved by the changes. The admin side was pretty much unchanged.

Milan then made one last suggestion; he recommended that I break my code for the 4 administration side screens that Subscribe2 makes available into separate files too and load these only when the page was visited. So, again I set about making these changes and emailed the code to Milan once completed. Again, to my surprise the administration side RAM usage had dropped to less than half what it had been before, even on the largest of the Subscribes pages. Additional changes also saw RAM usage drop to about a quarter of what it had been previously.

Matt did great job in splitting plugin into smaller files and making good folders structure to organize files based on their use and context. And main plugin file dropped in size from 200 KB to less than 3 KB. This loader file was than used to load only other plugin files based on the need for them.

Matt:
So, in summary, the review by Milan and the recommendations he made have left me with a faster and less resource intensive plugin. That can only be a good thing. On the downside it has caused me to split my plugin into lots of smaller files which I will find harder to manage and will therefore slow development down – but I consider that Subscribe2 is pretty feature complete now and I try to avoid adding new features unless they are adding value to the plugin to as large a number of users as possible, so perhaps that isn’t too bad a thing either!

Now to the numbers. How much memory is saved with the optimization Matt did? Table below shows test results for old 7.0.1 and latest one 8.2.0 versions.

As you can see, on the admin side plugin uses 70% less memory and on front end side 77% less memory after optimization. That is a huge gain. On the admin side, depending on the plugin admin page loaded this memory usage varies, but it doesn’t go over 0.6MB, on all other pages it is 0.4MB. As for the loading time, this is measured on my test server. Depending on the server speed, plugin can load faster. This number here shows a slight gain in loading time also. In that regards, there is not much space to improve that further, considering that even the smallest plugin on my test server needs about 0.008 seconds to load. Subscribe2 is great in this area also.

From my experience, having more files for a plugin can help you down the road when you get to adding more features. You can make better and more logical code organization, and you can start thinking about how new code will affect loading and how you can help to decrease memory footprint. In the end, end users of your plugin will be glad to have better optimized plugin and that they don’t need to switch to more powerful server every time new WordPress is released.

Imagine now if every WordPress developer did the same thing as Matt did with Subscribe2? I don’t think that each plugin can see such gains in performance, but most optimizations can save 30-70% of memory. If you used 20 plugins that were not optimized, you can end up needing 70-90MB of PHP memory, and most shared hosting would have problems with that. If you have 20 optimized plugins, this number can drop to 45-55MB and that is another story, your server can handle more requests and will be faster.

I know of many developers that have used my optimization suggestions to make their plugins better, and in this case I am grateful that Matt decided to try optimization despite his skepticism of the process. And not only try, but get great results after. If you want to see if you can do better with your plugin performance, here is my tutorial on the subject: How to optimize plugin loading.

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.

Notice: This tutorial is primarily for plugin developers, but it can be useful reading for anyone working with WordPress to better understand how plugins load and what can be done to improve it.

Intro

Before we go on, I recommend you to take a look at the article with test results. I know that many readers were surprised by the results, considering how some high-profile plugins scored very low and ended up in the bad optimized plugins category. Optimization will take these plugins one step further, showing that author cares about used resources (most WordPress websites are on shared hosting, and resources can be very limited), and that author understands that optimization is as important as adding features and making plugin look pretty.

So, what plugin authors can do to make their plugins better, how to optimize their loading, resource usage and with that speed? Before I list recommendations for this, here is a small analysis of how plugins are loaded.

Plugins Loading

One of the early steps in the WordPress loading is to load plugins. WordPress will get the list of all active plugins and it simply use PHP include function to load main plugin file. That main plugin file can contain the plugin (for smaller plugins or widgets), or it can be used as plugin loader to initialize plugin, or it can be the mix of the two. WordPress will do this for every single page, it will always include active plugins.

Even if the plugin is small, this can be an issue. For instance, my GD Unit Converter plugin was used in the benchmark article. This plugin adds a widget on the admin dashboard, and that’s it. But, if you look at test results it was using 0.5MB on admin side and 0.4MB on the front end side. And it was doing nothing on front end side! So, I changed the main plugin file to act as a loader only. It will check if we are on admin side, and it will load another file that actually contains plugin. If we are on front end side, it will do nothing. After this optimization, on front end side plugin uses now 20KB, that is 95% memory saved. That is amazing gain, but you can’t expect such results for every plugin.

If you look at the test results again, even smallest plugins will use 0.4MB to 0.5MB. Imagine that you have 20 such plugins, and if all 20 of them save just 0.2MB, that will lower memory usage by 4MB, and will improve speed a bit. That might not look like a lot, but trust me, it will make a difference, especially for shared hosting websites.

Most plugins have a specific usage, and that requires plugin to be loaded only on some pages. In some cases you will need parts of the plugin functionalities loaded on every page. It can be very complicated to decide the need for plugin on each admin or front end page. But, you need to recognize what parts of the plugin are always needed, and what parts will be specific to some of the pages. That basic analysis will help you to decide what pieces of code go into separate files. If your plugin is only for the administration, it doesn’t need to be loaded on the front end. It is very simple to check this in the loader file and to prevent loading of the rest of the plugin.

If your plugin ads administration side pages or forms, you will need to load CSS styles or JavaScript files. Too many plugins these days are making a very big mistake of loading these files on every administration page without checking if the page belongs to the plugin. That will most likely break other plugins or change the styling for other plugins, or even WordPress. This is one of the things that must be optimized and done properly.

Files and folders organization

One of the most important things with any plugin, is organization of files and folders with code, CSS, images, JavaScript. When you make right structure for files and folders, you will make it easier to make future changes and perform maintenance.

1. Code should be split into files according to functionalities. Many plugins don’t have that strict code separation, and they end up with large files with functions and classes thrown in. This makes later changes and maintenance harder, because code has no logical structure or order. Also, big files will use more memory, even if most of its functionality will not be used at all.
   

   Code Folders

2. HTML forms should be separated from files with code. These forms will be loaded only on some pages, and they will contain mostly HTML markup code (they can contain PHP code, and usually do, but only used to fill HTML elements with data), and they should be kept outside of the main plugin code.
3. Create few folders for different files types for your plugin. Main plugin code should go in one folder, files with HTML forms should go into another folder, CSS styles and JavaScript should go in own folder and images should go in own folders. On the image on the right you can see a folder structure for one of my plugins. I like adding extra sub folders for ‘code’ and ‘forms’ depending on how many forms there are or how much code. In ‘code’ folder it is recommended to have another level of folders if you have a lot of files.
4. If you have a lot of JavaScript or CSS files, it is good to have source versions for them as well as minified versions. This way they will be lighter on load, and you will have source versions for debugging and development.

Preparing for Optimization

To make the most of the loading process, you need to know what page are you on. Based on that you can perform different operation and load different files. Make sure you set a variable with the page file name or some other identification. On admin side, WordPress pages are identified by the file name loaded. Your own plugin pages can be identified by the ‘page’ variable from the URL request . To get the name of the file, name of the page and more, you can use this code:

$_current_file = end(explode("/", $_SERVER["PHP_SELF"]));
$_current_page = isset($_GET["page"]) ?  $_GET["page"] : "";
$_doing_ajax = defined("DOING_AJAX") && DOING_AJAX;
$_doing_cron = defined("DOING_CRON") && DOING_CRON;

Based on this values you can pretty much know exactly which page is loaded, and what you need from your plugin to load. This can be executed in the main/loader plugin file. I have added two more variables to determine if the page is loaded for AJAX handling or while doing Cron job.

Optimization Recommendations

Here are some of the important recommendations you should follow:

1. Analyze your plugin code, and decide what you need loaded on admin side, what on front end, and what on both. When you do that, you can go further and decide what you need loaded on all admin pages, and what on some of them (your plugin panels). Based on that, you will end up with many smaller files. Make some convenient naming scheme so that you can easily find files and use them in loader.
2. Always use main plugin file as loader. Even for simple plugins, this is best solution because you will have easier time later to expand the plugin. Don’t keep any code that is used by the plugin there, only decide what parts of the plugin you need to load.
3. Try to use classes as much as you can. Also, try to have only one class in a file, or at least put classes that depend on each other in one file. Use some logical naming convention for files, so that name gives you quick association to the class inside. PHP can help you with auto loading of files based on the required class, and you can find more info on that at the end of this tutorial.
4. Separate all AJAX handling code into own file. When your plugin on the server-side needs to handle AJAX requests, don’t add all that into file that is always loaded. It is easy to decide if the WordPress is loading to handle AJAX request, and only then load AJAX handling file. This goes only if the AJAX is handled by the WordPress admin-ajax.php file.
5. Always handle all AJAX calls through WordPress admin-ajax.php. This will save you a lot of headaches, and it can be used for both front end and admin side. Making your own handler file for AJAX is never good idea. If you need help with using admin-ajax.php, here is a good post in the WordPress.org Codex on using AJAX in plugins.
6. Separate all Cron jobs handling code into own file. Similar to AJAX handling, Cron jobs executions are run in own page/thread call, and you can always determine if that is the case. If you have cron jobs in your plugin, move all its handling functions and classes into files that will be loaded only when Cron job is executed.
7. Any other code elements that are needed for some panels only, or in some specific cases, keep in own file(s) and load them only when needed. This can be code that handles individual panels, AJAX handling, CRON handling, saving data… The better you identify what you need and make smaller files to load when needed, you will get better optimized files.
8. Handle all plugin settings through WordPress options database table through get_option/update_option functions (or get_site_option/update_site_option for multisite network wide settings). Never save individual settings as separate options, this can create a mess and will be hard to update and maintain. Put all your settings in one or more array’s (depending on the scope of settings you have). These settings are all loaded with a single SQL query when WordPress loads, and you have them ready when your plugin loads.

PHP Auto Loading

PHP has several methods to trigger automatic loading of files, based on the required code. If you split your code into classes, you can set up autoload functions that will do loading of files based on the class name. This can be very good solution for a plugin that has many classes used as modules, or used only in some cases. It is recommended to have one class in one file. More info about this you can find here: Autoloading Classes on PHP.net. Comments on that page have some really great examples on how the auto loading works.

GD Press Tools Pro Debugger: Snapshots

Measuring the optimization

My GD Press Tools Pro plugin can be used to debug and track WordPress loading. Tracker in this plugin has functions you can use to create snapshots that will contain used memory, hooks, SQL queries and time. You can use these functions in your code to measure how much resources some are used during different stages in the loading process. Plugin has a lot of other things to help you debug the code, find errors, track loading, track WordPress query, enqueued scripts and styles and much more.

There are some other plugins you can use to debug WordPress, but no other plugin allows tracking of the loading and the level of detail as GD Press Tools has.

Conclusion

There are many things you can do to optimize your plugin to use less memory and to load faster, and to have less impact on overall loading of WordPress. This article doesn’t cover everything and you will not be able to use all the recommendations for every plugin. But, good analysis, good code splitting and loading and tracking your optimization progress will always give you good results. Better optimized plugin is later easier to support and expand.

bbPress 2.0 Embeding: Advanced Controls

This new version continues with more optimization for plugin loading, and now we have another 10%-15% less memory used on admin side. Some minor optimization is done on the front-end to load plugin parts more selectively.  As for the bugs this version includes reported bugs fixed: saving and switching between full and simple edit modes for default post types and taxonomies, minor problems with hiding taxonomies meta boxes, minor styling issues with plugin editors and some issues with import and export of plugin settings.

For bbPress 2.0 plugin integration, you can specify the location in the forms where yo embed the selected metabox. Also, plugin can include CSS and JS for advanced controls for bbPress integration: color picker, date picker and number. Subforums can now inherit meta boxes set by parent forums. Integration works with the edit forms also, so all saved meta values can be edited.

Notice: Please, test all the changes and all the existing features to make sure that optimization done in this version didn’t broke anything. I have tested this version for couple of days, but with so many changes you never know what might be broken.

As announced before, next major 3.6 version will include several important new features, and work on it will begin in late January.

GD Custom Posts And Taxonomies Tools Pro Overview:
http://www.dev4press.com/gd-custom-posts-and-taxonomies-tools/
GD Custom Posts And Taxonomies Tools Pro Home Page:
http://www.dev4press.com/plugins/gd-taxonomies-tools/

Plugin now supports 16 different units, and more will come. But, in this version, plugin is only gone through optimization based on the plugin impact on WordPress benchmark I did last week. So, now plugin is only loading on admin side.

You can download plugin for free from Dev4Press website, or from WordPress.org plugins repository.

Dev4Press Home: http://www.dev4press.com/plugins/gd-unit-converter/
WordPress.org: http://wordpress.org/extend/plugins/gd-unit-converter/

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.

Pro version Database tools are updated and expanded. Now, for each table you have optimize and repair options. Also, cleanup tools is split into two: one for optimization of database only, and other for repair. Sending email after backup is fixed, with few minor typos and errors displaying list of backups.

Most important new addition here is use of mysqldump program to create backups of the database. For this to work, plugin needs access to mysql program and also some PHP functions. New mySQL panel on Database panel is there to set and check all prerequisites. For manual and schedule backup jobs you can choose which backup method to use. If the mysqldump can’t be run, classic method will be used. Also, GZIP mysqldump method can’t be used on Windows servers.

Also, both versions are now fully compatible with latest build of WordPress 3.0.

After this, next step is to add sending backup archives via email and to add restore options for archived database files.

And, the solution is found in VPS.NET cloud hosting. They offer scalable VPS servers with adjustable number of nodes to increase CPU speed, bandwith and available memory. To test the new hosting system, our website TVScape.NET has been transferred to new server yesterday. And the tests showed that TVScape is now 3 times faster (on average), then on old server. Response time is cut in half, and typical page with over 80 images fully loads in less then 15 seconds, while on old server same page needed 40 to 100 seconds. Also, new server is VPS and that allows fine tunning of cache settings, expiry of resources allowing much better optimization.

Dev4Press is moving to new server most likely next friday, so that the support and other normal functions of the website are not interrupted. In any case, there will be a notice announcing the exact period when the transfer is in progress. Major problem during the transfer will be DNS change that with some DNS servers can take up to 24 hours for new server IP to propagate. So, for a day website will work on both servers and depending on your location, you might get old or new website.