How to (really) choose WordPress Hosting

I am the creator and maintainer of Wordfence, an anti-virus and security plugin for WordPress. We are still a young plugin, but already are about to pass 50,000 downloads.

Often when our customers have a problem with Wordfence, they create a temporary admin account for me and I sign in to their (usually) hosted WordPress site to diagnose it. So I’ve experienced a large number of WordPress hosts over the last few months.

Wordfence is a fairly complex plugin. It has an admin interface that provides real-time traffic views and these contact our API servers in real-time to do things like resolve the geolocation of IP addresses. Admin’s can also kick off a scan and watch it run and of course scheduled scans run in the background on a regular basis.

The background scans have provided a fair amount of insight into which hosts have issues and which don’t: For example when a WordPress cron job or a Wordfence scan starts a scheduled event, it needs the server to be able to connect back to itself. A surprisingly large number of servers are unable to do this because they don’t know their own hostname or have some other problem.

I’ve also seen a number of servers that have trouble making connections to external servers like our API server. Some have intermittent issues and some don’t make the connection at all.

Perhaps the most frequent problem I’ve seen is too little memory for WordPress. This manifests in several ways:

  • The most common is that the php.ini memory_limit variable is set too low. 30 Megs is a common setting which is too low for a WordPress site running many plugins or one or two complex plugins or themes.
  • The next most common is the Apache RLimitMem setting is set too low and so Apache will prevent PHP from allocating more memory even if memory_limit is set to a high value. I’ve frequently seen RLimitMem settings that are low with a high php.ini memory_limit value – an obvious misconfiguration.
  • The most difficult to diagnose problem is where the host has configured PHP and Apache with high memory values, but there is a killer daemon running on the host that simply kills any process that grows beyond a certain size. This is rare, but it exists.
To give you some perspective on how serious too little memory is, here is how it usually manifests itself: A customer installs plugins until they are right at the threshold of the maximum memory their host has provided. They then install one more plugin and it causes WordPress to “white screen” meaning that your WordPress site simply doesn’t load. This usually means the plugin needs to be uninstalled via FTP because the WordPress admin interface is no longer available.
I’ve run across several hosts who limit the maximum running time of an Apache process to as little as 15 seconds. This is not enough for longer running WordPress cron jobs. We have coded a workaround in Wordfence for hosts like these, but this will still affect WordPress’s own scheduled jobs if they run longer than 15 seconds.

Another problem I ran across 2 months ago is a very (very) large WordPress host who’s deployment system was corrupting WordPress core files. This means every new WordPress install started off as corrupt. We spotted this because Wordfence alerted that core files on a fresh install were different from the originals. We thought this was a bug, but it turns out their deployment system was corrupting a core file in a way that created subtle bugs in the editing interface of WordPress. They have undertaken to fix the issue and I haven’t confirmed if they have.

And finally there’s performance. When I sign in to various hosts to diagnose issues I’ll sometimes experience a snappy interface and occasionally it’s just dog slow. The WordPress admin interface, which tends to consume more memory and CPU than a non-authenticated site visitor, just screams that the host is overselling their virtual servers because it takes a while to load.

When we first created Wordfence we bought space on the top WordPress hosting providers and made sure our software ran on all of them. It’s now several months later and I’ve had the experience of working with many customer installations across many more hosts.

When choosing a host, find out the following:

  • What is the real memory limit? [In php.ini, apache2.conf and any other limits]
  • What is the longest time a process can run before they kill it?
  • Install Wordfence on the new machine and verify core files are intact.
  • Make sure the interface is snappy and stays that way.
  • Make sure the host has been in business for a while and will be for theĀ foreseeableĀ future.

The one host that in my experience stands out head and shoulders above others is Bluehost. They are one of the larger hosts and I’ve never had a problem with performance, memory, scheduled jobs or anything else on one of their WordPress installs. Starting today I’m recommending our clients head over there to get rock solid WordPress hosting.

8 thoughts on “How to (really) choose WordPress Hosting

  1. This was an interesting article – I wish you talked about more hosts though, and gave some benchmarks.

Comments are closed.