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.

Older WordPress versions (before 2.9) could work with 16M of PHP memory. Even later 3.x versions can work with so little memory if you don’t use any plugins. But, using plugins increases memory requirements, and using only 32M is at most times not enough. For latest WordPress with average of 20 plugins you will need 48M to 64M. Most hosting companies keep this value at 32M, so when you upgrade WordPress, upgrade plugin or add new plugins, you will run out of memory and you will see variation of this error (on screen or in log, depending on server settings):

Fatal error: Allowed memory size of 33554432 bytes exhausted (tried to allocate 345234 bytes) in /path/to/public_html/wp-content/plugins/plugin.php on line 56.

To increase memory, you can uses different methods. Examples bellow are for 64MB of memory. You can set it lower and experiment with higher values. Setting this to 128M or 256M is fine also, PHP will really use as needed, this value is limit. Use only one of these methods, don’t use all of them in the same time!

Method 1: Change PHP.ini

On some shared hosting servers and on VPS or other dedicated hostings, you will have access to php.ini file with all main PHP settings. This file should have memory directive, so you need to find it and change it, if it is not there, you need to add it. Here is the directive you need to find/add and set different value for memory size:

memory_limit = 64M

Method 2: Use .htaccess

If you don’t have access to php.ini, same thing can be done using .htaccess file. This file is in the root folder of your website, if it’s not there you can add it, but in most cases it is added by WordPress. This file is only available on Apache servers. Again, search for this in that file, if it is not there add it, and set memory value you need:

php_value memory_limit 64M

Method 3: Use WordPress wp-config.php

WordPress way to do this is using almighty wp-config.php file. If this define is in the file, change it to memory value you want, if it’s not there add it before “That’s all, stop editing!” comment in that file. Here is the code to find and change or add if not there.

define('WP_MEMORY_LIMIT', '64M');

Method 4:  Contact your hosting company

If you don’t want to do it on your own, you can always contact your hosting company support. Some hosting companies can impose limit to this value, so no method you can try can change it, and only hosting support can change it for you.

GD Press Tools: PHP Status

Check current memory limit and memory usage

Simplest way is to use our GD Press Tools plugin (you can see this with both Lite or Pro version). On GD Press Tools main page you can see the PHP Status block, and there you can find Memory Limit item and value for it. How much memory is used, plugin can add into the footer, and image bellow shows you used memory during the page creation, footer value is most important, that is total memory used for the whole page.

GD Press Tools: Memory usage

Admin side uses about twice as much memory then front end side.

From now on, WordPress requires PHP 5.2.4 and MySQL 5.0.15. All respectable hosting companies are already up to date with PHP and mySQL (some even running latest PHP 5.3), but you better check to make sure that your hosting company is upgraded, or you will be surprised when after upgrade you end up with broken website. All modern browsers will do fine, and from what I have seen IE7 will work for the most part with some minor problems, IE8 is also fine.

Image below shows the new WordPress admin dashboard. New interface uses space on the page a bit better and widgets and other elements are looking more compact and cleaner. For the most part I like the new look, with exception of the top header section, I think old one was better. On the image here you can see pretty much standard dashboard content with addition of GD Press Tools Pro widget and execution stats in the footer.

WordPress 3.2: Dashboard

Interface changes also include improvements to post editor that now supports new full screen Just Write mode. Editor expands to the full browser window with toolbar on top. Once you start writing, all controls will be gone leaving only empty space with no distraction. I am not going to use it much, but I am sure that many users will welcome this clean and simple approach.

WordPress 3.2: Just Write Editor

New theme replaces TwentyTen, and its called TwentyEleven. Theme is HTML5/CSS3 based, and its faster than earlier one, but I don’t like it very much to be honest. I think that it would be better to improve on TwentyTen than go with new theme, but here it is.

Admin bar is improved with more options and menus added. It would be nice to have some extra control over what is in the admin bar, but plugins will take care of that. Next GD Press Tools Pro will have more options for admin bar control. Other changes are many minor visual improvements: login form changes, new links in the footer and more. jQuery is updated to 1.6.1 with jQueryUI to 1.8.2.

But, the most important change in this version is performance improvement. WP 3.2 is faster than previous versions (especially 3.1), and you will feel this difference as soon you upgrade. Better JavaScript code make loading of pages faster, and this is most noticeable if you use fast browsers like Opera or Chrome. All upgrades will be faster (especially if you use FTP for uploading upgrades, that was very slow before). Other optimizations include improved functions, partial cleanup of PHP4 specific code and more. During next week you can expect 2 posts with benchmarks of WordPress 3.0.4, 3.1.4 and 3.2 for both admin and front end side.

WordPress 3.2: Post Editor in blue

But, as with any new WordPress there are some downsides. Many of the updates will for sure break many plugins and themes that use jQuery due to changes in jQuery 1.6. I hope that plugin and theme developers are going to check everything and fix potential problems. I have tested my plugins and they are all OK, with some Lite versions coming next week to make sure everything is OK. Some users I talked to recently expressed their disapproval of new interface, but that is expected with any interface change. For me, I like the new WP look (for most part).

What’s next for WordPress? Now that requirements are sorted out, and interface improved, there are still several areas where WordPress is lacking. Most important problem is content management. I have said it before 2.9 and 3.0 and 3.1, and I am saying again, WordPress is not equipped to work with large amount of content. If you have few hundred posts and 20 categories, it’s not bad, but for large websites that use custom post types and custom taxonomies, this is a real problem. Changing taxonomies for large number of posts in the same time is slow using current batch approach, and still impractical. We need better, and easier to use drag and drop interface for handling posts and taxonomies with AJAX filters and pagination. I really hope that this will be one of the things we can expect in 3.3, and I will try to push the suggestions once the WP 3.3 gets in development.

For now, WP 3.2 is great upgrade to the platform, and I strongly recommend that you switch to it as soon it is released. Speed of the new WP alone is reason enough. Add better interface and other minor changes and WP 3.2 is the version to use. All core developers and contributors deserve big thanks from the growing WordPress community for all the work to make this new version.

When you first install WordPress, you can do it manually or you can use some sort of install script that is usually offered by the shared hosting companies. In my experience, those scripts usually do a good job in setting at least initial file permissions to all files and folders. But, on the other hand that may not always be the case, and you can end up in problems.

Main issue is to allow WordPress to access files and folders it needs to be able to work properly, and in the same time not to set permissions too loose so that it can be exploited. To change the file permissions, Linux uses CHMOD command. Permissions for files and folders are represented by three values controlling access for file owner, for owner group and for everyone else (world). And each of these controls 3 rights: read, write and execute. There are different ways to display file permissions, and most common is to use 3 numbers: first for owner, second for group and third for world. File system and file permissions can be very complex, and more info on how all that is working can be found on URL’s at the bottom of this articles.

Since we are talking about file system on your server, referring to users and groups has nothing to do with WordPress. User or owner is your account on the server not in WordPress.

Recommended permissions

Before you check and set CHMOD for files and folders, it’s recommended that owner for all files and folder is your user account on the server. If, when you copy new files or add new files, this is not the case, and if server is setting someone else as an owner, then, there is something wrong with your server settings. In my experience, this usually happens if you are installing and setting server on your own (VPS hosting) and you missed configuring file system ownership, that depending on OS you use, can be set to Apache process or something else. Make sure that all files and folders in your WP installation are owned by your user. All other recommendations are based on this one, so make sure it’s set as it should be.

FTP View of Permissions

For all folder in the WordPress installation, recommended permission is 755. This means that owner (first number, 7) can read, write folder and execute content in it. Group and world can’t write. This makes folders safe from anyone beside your main user adding new files, or deleting existing files. Files should be set to 644, the same as 755, but with no execute set. For folders you need owner, group and world to be able to at least read from the folders, or your website will not be publicly accessible, so that’s why 5 is set for group and world.

If you are using FTP or command line tools, you will usually see permissions displayed like on the image on the right with string with 10 characters. First is telling if it’s file or folder, and 9 are flags for all 3 groups, 3 rights each. Here you can also see owner and group. While they are named, here are codes representing the names on your server.

Specific files permissions

For some files and folders you can use different permissions to make sure that they are extra secure. So, for wp-config.php, recommended permissions is 640 or even 600. Same goes for .htaccess files. In shared environments, you can also have PHP files present (php.ini and/or php.cgi). For these files you can set even more restrictive permissions: 100, and only owner can execute these files, nothing else.

File Permissions in GD Press Tools Pro

GD Press Tools Pro

To do all this, you can use command line on your server, FTP access or file manager you have in the control panel for your hosting account. But, you can do it from WordPress also. GD Press Tools Pro on the Security panel shows most important files and folders in your WP installation, their files permissions and options to change those that are not restrictive as recommended values are.

Also, on the Security panel, tab General you can set default CHMOD values WordPress can use to set on newly created files and folders (uploads mostly).

Conclusion

Permissions described in this article will be enough to make all critical areas of your website secure. But, you can take this further and experiment with more restrictive rules for some folders, or some more files.

Resources

• Changing File Permissions: http://codex.wordpress.org/Changing_File_Permissions
• CHMOD on Wikipedia: http://en.wikipedia.org/wiki/Chmod

Hosting companies are offering UNIX/Linux-based servers or Windows-based servers. Due to pricing of Windows licenses, they are not commonly used to host websites based on WordPress or other PHP based systems. Most servers will run on different distributions of Linux, and they commonly use Apache as web server. I will not write about Windows-based servers, since they are much different to set up and use, and also they are very rare for WordPress website, and not really relevant for this article.

Shared Hosting

Most websites, especially smaller websites are hosted on the shared hosting servers because they are cheap and they are powerful enough to run. Shared hosting means that a single server is used for many different users accounts. Server is not yours to use and modify as you need, you are limited by the shared environment settings that hosting company set for all accounts on a server. There are some things you can change and use.

If you decide to choose shared hosting company, make sure that they are using latest (or at least current) software: Apache server (or something similar), PHP (version 5 is a must, with 5.2 or 5.3 being preferable) and MySQL (version 5 is most commonly used). They need to allow you to use HTaccess files (there are still many hosting companies that don’t) and preferably allow you to use own copy of PHP.INI file for some settings that can be changed for each account. Good support is always important, especially until you set everything and make sure that server is working right. Always require access to some sort of control panel: CPanel, ISPManager or Plesk (there are others, these are the best).

Shared hosting is limited in what you can do with the server (again, it all depends on the hosting company), and you will not be able to install additional software: Firewall, PHP extensions, MemCache… Most shared hosting companies have decent security related setup, but again, make sure to check what are you getting into.

Sharing server by default means that all accounts and all domains on it will share single IP address. So, if that IP gets blacklisted for some reason because of some other user, you will be affected also. Most shared hosting companies offer purchase of separate IP for your account only.

Virtual Private Servers Hosting

Or VPS for short is becoming very popular in the recent years, mostly due to much better performance you get and much affordable prices caused by many more emerging companies offering this kind of service. VPS is basically a whole server only for one user, this server is not actual physical machine, but a virtual machine-made through process of virtualization and sharing of hardware resources. There are many different methods for this used today with nodes distribution and clouds getting more in popularity. You are only user of your VPS, and you can have full control over installing the server and setting it up. VPS can be unmanaged (you need to do everything by yourself), or is managed where hosting company is still in control of installing the server and helping you run it.

If you decide on VPS hosting, be prepared to work more on the server setup and maintenance (depends on managed or unmanaged VPS configuration). If you need to use mail server on your VPS (and in most cases you will need that), make sure to set mail server properly: reverse DNS (usually you need to ask for this from the hosting company), set up limits, SPF records… Be sure to run latest version of OS you have decided on, updated kernel, updated web server, PHP and mySQL. Also, I strongly recommend installing some firewall software (LFD is really good one with a lot of options to set). Make sure to use strong passwords for everything and to change them often. If you run personal server (no outside users), there is a less chance of intrusion because you will be only one that has access to it.

PHP also can be improved and expanded to include Suhosin security extension. Some Linux distribution (like Ubuntu 10.04), will install PHP with built-in Suhosin. To be honest, I don’t like it and I don’t use it. I find it hard to set up, and it was always causing more problems than I was prepared to deal with. But, if you have patience and time to test it, I recommend trying it. As for the mySQL, usually server is set to allow only local access to it, so no one can access it from outside your server.

VPS is the best solution for hosting: not very expensive, full control over the server, great potential for setting it up exactly as you need and in most cases very easy to expand to use more hardware resources when your website(s) starts to grow and to get more visitors.

Dedicated Hosting

What I said about VPS can be said for dedicated hosting. But, in this case you actually have use of full physical machine. This is usually very expensive solution, but most powerful one. If you don’t care about spending more money, this is the best solution and the most complex from maintenance standpoint and work you need to invest also..

Useful Resources

Here are some online tools and resources that can help you with the server and hosting environment.

• UCEProtect: http://www.uceprotect.net/en/rblcheck.php
• MXToolbox: http://www.mxtoolbox.com/SuperTool.aspx
• CFS / LFD: http://www.configserver.com/cp/csf.html
• PHP Security: http://phpsec.org/projects/guide/

If you check official requirement page, you will see that you need PHP 4.3 and mySQL 4.1.2 at a very least. You need mod_rewrite installed on Apache if you want to use pretty permalinks (or some equivalent for Windows or other servers). But, it’s not that simple as they make it look like.

PHP

Hidden truth is that some WordPress features even now require PHP5 (timezone and oEmbed are most important). So, claiming that WordPress will work on PHP4 is false, because you will not be able to use everything WordPress has to offer. To make things worse, many plugins require PHP5 to work, and that include many popular plugins.

So even if you use PHP4 for your bare WordPress installation, as soon as you start adding plugins you are likely to get at least few that will not work with PHP4. Let’s face it PHP4 is dead for over two years now, not supported by PHP anymore (support ended on february 5 2008) and all major CMS platforms are either dropped support for it or will do in the near future. Except for WordPress. And as it looks right now, even next WordPress 3.1 will maintain the illusion that WordPress will work fine on PHP4.

Only the fact that some features are not working on PHP4 is enough to finally admit that supporting PHP4 still, is pointless. Main reason behind the idea is that some 10% of websites using WordPress run on PHP4. I don’t have access to that statistical data, and I imagine that is old at least a year because we got same number from Matt when WP 2.8 was released. Situation now is different, because I tried for the past week to find reputable hosting company that only offer PHP4 with no PHP5. And I couldn’t find any.

Several hosting companies are running both versions of PHP to support some old software and websites but users can switch using control panel option or simple command in HTACCESS. All this is for shared hosting, because on VPS or dedicated servers users install latest software anyway. Newer server versions like Ubuntu 8.04 or newer can’t even install PHP4 anymore (I tried on my VPS.NET server) and I don’t see anyone manually compiling it from source on new server. WordPress recommends several hosting companies and even they offer only PHP5. So, where are those 10% PHP4 WordPress websites hosted?

I had several clients that had problems with WordPress  running on PHP4.4 and in only one instance I managed to fix things to make WordPress works. Problem with PHP4 settings, security issues and many other things can prove impossible to solve in many cases. One of the clients used PHP4 because he had some old server he didn’t want to reinstall or update and he was under the impression that everything was OK, and he had a hard time understanding why WordPress is claiming something that simply can’t be achieved in practical usage. And the user experience and practical side of using any system is what should count in the end, and that is clearly against PHP4.

Even if you in the end manage to install WordPress on PHP4, you will be able to run it only without plugins (or with only few plugins).

mySQL

With WordPress 2.9 support for old and bad mySQL 3 is finally dropped, and for the most part there are no major (or even minor) differences in SQL specification used in mySQL4 and mySQL5. I didn’t noticed any problems with using mySQL 4 (one client has it, and it runs fine).

(Actual) System Requirements

So, here they are:

PHP version 5.0 or greater
mySQL 4.1.2 or greater

I personally would recommend this:

PHP version 5.2 or greater
mySQL 5.0 or greater

Only some hosting companies I investigated had PHP 5.1, most maintain installations with PHP 5.2.x branch, with only some offering PHP 5.3. mySQL 5 is also used much more than mySQL 4. With growing competition among hosting companies, they all try to have more current software installed, and in the future we will see mySQL 4 gone also.

Conclusion

OK, I didn’t planed to write so much, but there you have it. WordPress needs to drop PHP4 with WP 3.1 coming later this year, and that needs to start right now with announcements to users with information on the upgrade and anything else that will push the remaining few percents of WP users on PHP4 to switch to PHP5.

I recommend you check out also:

WordPress 3.0 and PHP 4 – What’s the deal?
WordPress and PHP 5: Be the Change You Want to See