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 five 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 typical stack of software that powers providers’ servers. Apache is a web server – it’s what 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.
Because 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. And Apache doesn’t understand PHP, so 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 it’s 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 number 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.
You Aren’t Object Caching
So the page cache thing is excellent, 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 merely is 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, let’s 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 object is returned — without needing to be rebuilt.
WordPress comes with a helpful tool call Transients that lets developers store data in the WordPress database and access it later. You can save 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. 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, it’s nearly impossible to tell where one function begins 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
Anytime you install a plugin you need to ask yourself one simple question: “Is this plugin essential for my users?” There are a high number of plugins that you don’t need. Many plugins are unnecessary because they accomplish things a developer can do with less than ten 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. One of the things I tell a lot of prospects is “the best thing about WordPress is that it’s open source and has about 60,000 plugins, and the worst thing about WordPress is that it’s open source and has about 60,000 plugins.”
People can get in real trouble by using too many plugins which can cause performance issues, or worse, conflict with other plugins and crash your site. I can’t tell you how many websites I’ve seen where the owner comes to me asking about performance, and when I look into their WordPress Admin Panel, I see they have 40 plugins installed. If you do need to use a plugin, look for one that has positive reviews, has been regularly updated, and if possible has a long-running history. You don’t want a fly-by-night plugin that your site depends on where the developer decides to get another job and abandons the plugin altogether.
Here are some examples of things to avoid:
- Anything that tracks page performance like the number of visitors, for example. WordPress is a CMS; if you want to track performance metrics, then you should look into using HubSpot with WordPress and even a WordPress/HubSpot integration.
- Related posts plugins – these things are ridiculous. They scan every post on your site for tags that match the current post. Do you want to run additional database queries every time someone looks at a post? No. If it’s imperative 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 precisely impact user experience immediately, too many emails being sent out from your server can 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 website. Even worse, most of these smaller hosting plans are not built to support WordPress. They have to support other CMS (Joomla, Drupal, etc…) Nothing against Hostgator, Bluehost, or the other low cost hosting companies, but a host built for business sites is the way to go.
LyntonWeb offers hosting and support services to our WordPress customers. We’ve partnered with WP Engine to provide the very best WordPress business hosting solution. WP Engine has server level caching (no relying on caching plugins), automated daily snapshots with one-click restore, and top-notch security (they even have a list of banned plugins). The snapshots are extremely valuable. I can’t tell you how many customers who initially thought $99/mo for hosting was way too expensive for their business website, only to have it crash while on one of the cheap hosts.
These hosts didn’t have snapshots, and one-click restores, so in some cases, it took an entire day to restore their site. So to save less than $90 a month, they lost a full day of business and paid for 7 – 8 hours of development work. At the end of the day to save a couple of bucks a month, they wound up spending what hosting would have costs for an entire year and a half. To make matters worse, this doesn’t take into account the loss of business revenue.
The moral of the story, don’t skimp on your hosting; it almost always comes back to bite you.
You could go directly to WP Engine and set up an account, but when you host through us, we update your plugins monthly saving you valuable time.
To Sum It Up
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.