5 Reasons Why Your WordPress Website Is Too Slow

You’ve just launched your fancy new WordPress website only to find out that it takes longer to load than it would for you to mail people a printed out version of your new website? This is the downside of having a Content Management System that is open source and extended profusely by third party developers – the more you add to it, the slower it can become if you’re not careful.

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 that is 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 be processed every time a user requests a page. In normal situations that may not account for much latency (or lag), but if you’ve got lots of concurrent users the machine powering your site has to constantly process code. Apache, because it doesn’t understand PHP, has to communicate with PHP via an Apache module that is included in every standard shared hosting package. This Apache module is the go between 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 and then Apache finally displays the page!

Page caching runs the PHP codes only once every so often and stores the resulting HTML on the hard disk. Then when Apache sends the request to PHP it says “Oh hey, i already did that and its over there!.” Apache then immediately serves the 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 LyntonCare 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 be 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 rather than generating that object repeatedly,especially if the nature of that object is not very dynamic.

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 calls behind that process grab data from multiple points on the database and then build an object and return it. Rather than doing that, why not store the result of that operation into the database as an object so that all you have to do is make one call and the object is returned ready to use and without having to be rebuilt!

WordPress comes with a great tool call Transients that let developers store data into 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 – and 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 and as they complete tasks they have three or four more added to their plate. Sure, you might have hired a really awesome development team that communicates flawlessly – but the chances of having code be repeated, control structures becoming obtuse and gnarly and loops getting out of control is pretty high! When we developers first plot out our websites, everything is controlled and looks nice and easy to follow, but as more and 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, kind of like looking at a plate of spaghetti and trying to follow one noodle.

The trick to this is to refactor code all the time. Every month you should dedicate a small portion of your budget towards optimizing the code base. You’ll shave time off of your page loads and your developers will love you for the opportunity to make it easier on them to extend the site when you need new features!

WordPress makes it somewhat easy to stray from the MVC framework for building code – sometimes all the code that powers one page can reside in one file. LyntonWeb developers are bound by honor to deliver all code at the MVC standard, with each part of the code broken into logical sections. We live and die by the CRUD (Create, Read, Update, Delete)!

You’re Using Way Too Many Plugins

It’s OK, 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. Pretty much anything to do with adding jQuery to your website or installing your Google analytics tracking code are really unnecessary. A developer can add that functionality to your website with less than 10 lines of code.

Always remember that every plugin you install has to be loaded with every page load. A lot of them are cached efficiently and don’t impact performance, but just as many are coded horribly and are 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 utilizing HubSpot and possibly 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 so your guests are kept from reading the content they clicked on while you’re searching for other things for them to look at.
• 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 Shared Hosting

Sorry to tell you this but your 9.95 Hatchling Plan at Hostgator isn’t suitable for millions of visits a month! I bet you probably have a couple websites running on that same plan, too! Shared hosting means you SHARE hosting. That means that there are likely a half dozen or more other users on the same machine your site is on. 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, right?

Here’s what you can do when you break out of the mold of utilizing common shared hosting plans:

• Scale your server as you need it! Most dedicated or virtual hosting plans allow you to easily upgrade your processor, ram and disk space.
• Utilize 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 LyntonCare WordPress hosting packages. There are multiple LyntonCare tiers available, but every one of them uses 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.