5 Reasons Why Your WordPress Website Is Too Damn Slow

Brad Decker

speed up wordpress websiteYou've just launched your fancy new WordPress website, only to find out it takes longer to load than snail mailing a printed copy of your webiste? This is one of the downsides of using an open source content management system. Because it is extended profusely by third-party developers, the more features you add, the longer it takes to load.

So what do you look for when it comes time to optimize your WordPress website? Where do you start amplifying your WordPress page performance? There are 5 simple reasons why your WordPress site is probably running slower than it should be.

You Aren't Page Caching

Have you ever looked at a WordPress page template file? They can be extremely complicated depending on how much you've customized your site. Most common hosting providers run their shared hosting on LAMP environments. LAMP stands for Linux - Apache - MySQL - PHP, which is a common stack of software that powers providers' servers. Apache is a web server - it's what actually serves files to viewers who browse your site. However, it doesn't understand PHP, a programming language that resides on the server and the language WordPress is built on.

Since Apache doesn't understand PHP, all those lines of code in your template files have to process every time a user requests a page. In normal situations that may not account for much lag, but the machine has to process that code for every concurrent user on your site. Because Apache doesn't understand PHP, it has to communicate with PHP via a module included in every web hosting package. This Apache module is the middleman between Apache and the PHP processor. This means that when visitor A comes to your website (and you're not page caching), Apache sends the request down through the PHP Module which sends it to PHP, which then generates a bunch of HTML and sends it back to the module...then Apache finally displays the page! 

Page caching runs the PHP code only once every so often and stores the resulting HTML on the hard disk. When Apache sends the request to PHP it says "Oh hey, i already did that and its over there!." Apache then immediately serves the cached HTML content! 

So how do you implement page caching? There are a lot of plugins available for WordPress and the amount of articles debating which one is the best are endless. We typically use W3 Total Cache for advanced clients and users, and wp super cache for more basic caching needs. W3 Total Cache has a ton of options, bells and whistles that make fine tuning your cache challenging (but rewarding) whereas super cache tries to take most of the control out of your hands in favor of tried and stable caching methods. We also have a custom caching system that is included with our Lynton Care hosting packages (more to come on that later)!

You Aren't Object Caching

So the page cache thing is great, but some PHP is still going to run on every WordPress page load. You can't cache things like function definitions or the core PHP logic of WordPress via the page cache. To help in that area you should consider object caching. Object caching is simply storing a PHP object (basically any variable value) that is in the database on the hard drive or better yet, in memcache! This can save lots of time, so the same object isn't generated repeatedly. 

For example, lets say every time someone views a page on your site you are loading the WordPress user object which contains their first name, last name, etc. The function behind that process grabs data from multiple points on the database, builds an object and returns it. Rather than doing that, why not store the result of that operation into the database as an object. Then all you have to do is make one call and the ojbect is returned--without needing to be rebuilt. 

WordPress comes with a great tool call Transients that lets developers store data in the WordPress database and access it later. You can store the HTML for an entire page in a transient if you like. It's more concise and practical to store object data used to build that HTML - then let page caching handle the rest!

Your Site Has Spaghetti Code!

It happens to everyone, so don't worry. Spaghetti code is what happens when you have too many developers working towards the same goal in a short period of time. As they complete tasks, they have three or four more added to their plate. Even if you have a talented, high-performing development team, there's a chance of some things getting out of control as the codebase grows. When us developers first plot out our websites or applications, everything is controlled and looks nice and easy to follow. As more features are added, the code starts to look a little messy. Eventually its damn near impossible to tell where one function starts and ends. Like looking at a plate of spaghetti and trying to follow one noodle.

The trick to this is to refactor (or clean) code all the time. Every month you should dedicate a small portion of your time or budget towards optimizing the code base. You'll keep your site loading fast, so your users (and Google) will be happy. (Google includes site speed as one of its ranking factors). Developers like refactoring their code because it helps them prepare for new features and continuously improve their product.

You're Using Way Too Many Plugins

I plan on starting WPPUA (WordPress Plugin Users Anonymous) for a support group. Anytime you install a plugin you need to ask yourself one simple question: "Is this plugin really necessary for my users?" There are great number of plugins that you really don't need. Many plugins are unnecessary because they accompish things a developer can do with less than 10 lines of code, and with far less overhead than a plugin. 

Always remember that every plugin you install has to load with every page. A lot of them are cached efficiently and don't impact performance, but just as many are built poorly, packed with features that aren't needed. Here are some examples of things to avoid:

  • Anything that tracks page performance like number of visitors etc. WordPress is a CMS, if you want to track performance metrics then you should really look into using HubSpot with WordPress and even a WordPress/HubSpot integration.
  • Related posts plugins - these things are ridiculous. What they do is they scan every post on your site for tags that match the current post. Do you really want to run additional database queries every time someone looks at a post? No. If it's really important to you, there are services out there that offload this operation to their servers, and they can offer more relevant suggestions. 
  • Lots of mailing plugins out there are written poorly and while they don't exactly impact user experience immediately, too many emails being sent out from your server can just add more load time all around.

You're Using Cheap/Shared Hosting

Sorry to break it to you, but your 9.95 Hatchling Plan at Hostgator probably isn't suitable for your WordPress webstie. Even worse is if you're running multiple websites running on the same plan! Shared hosting means you SHARE resources. That means that there are hundreds of sites like yours all fighting for resources on the same machine. Nothing against Hostgator, but a truly dedicated hacker who has gained access to one site on a shared machine can most likely gain access to all the sites on that machine. Those expensive hosting plans aren't looking so bad now, are they? 

Here's what you can do when you break away from a shared hosting plan: 

  • Scale your server as you need it! Most dedicated or virtual hosting plans allow you to easily upgrade your processor, ram and disk space. 
  • Use new server level software packages! LyntonWeb has opted to use Nginx server layered on top of Apache to deliver websites at SCREAMING fast speeds. We also use Varnish to make our caches even more effective
  • Take security into your own hands. WordPress plugins for security are a great start, but until you really start to look at security from the server level you aren't truly protected. 

LyntonWeb offers hosting and support services to our customers under the name Lynton Care. All of our hosted WordPress sites use Nginx server architecture on top of Apache for lightning fast speed and armored-truck level security. You could take the time to learn all the ins and outs of setting up Nginx with Apache and PHP, but why worry about that when you have a site to run? Our customers have noticed improvements in their page load times by as much as 30 seconds on large pages. Most pages will load under the 2 second mark when cached. 

Don't settle for a slow WordPress site. The visitor leaving because your page is taking a minute to load or doesn't load, could be your competitor's next customer. 

Case Study Website Redesign

 

Inbound Websites

Brad Decker

Posted By: Brad Decker

Brad is a Web Engineer whose passions include web development, gaming and writing. He enjoys a challenge and does not understand the meaning of the word "can't".