As you might know, I have written about WordPress plugins optimization many times already. And, it is a great thing to know that some developers have taken the time to improve their own plugins based on my recommendations. Here is the story about one great optimization.
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.
| Administration | Frontend | |||
|---|---|---|---|---|
| Version | Memory | Time | Memory | Time |
| Old, 7.0.1 | 1.3 MB | 0.014 sec | 1.3 MB | 0.013 sec |
| Optimized, 8.2.0 | 0.4 MB | 0.011 sec | 0.3 MB | 0.012 sec |
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.
