How to Reduce Your Server Response Time with WordPress

A fast server response time is one of the most important factors for site load speeds. It doesn’t matter how smushed your images are, how compressed your scripts, if the server takes seconds to respond.

To a certain extent, there’s only so much you can control with your server. I’ve attempted to list as many factors as I can that can help you speed up your server, which in turn helps your site load quickly and your PageSpeed ranking increase.

Reduce Plugins

Yes, I know. One of the primary selling points of WordPress is the ability to use plugins to dramatically expand functionality of the platform. If you’ve been using WordPress for long enough, you likely have a stable of plugins you can’t live without. Feature enhancements, security plugins, all sorts of customizations; they’re the creature comforts that make WordPress worth using.

Some plugins are entirely passive and only apply to certain actions your users never see. A plugin that you run once to audit your backlinks doesn’t affect server response time unless you’re actively running a scan, using server resources. A plugin that crunches down image file size at upload doesn’t come into play outside of an image upload.

Still, many plugins affect server speeds simply by existing. In general, it’s a good idea to reduce the number of plugins you use. For example, there are plugins for adding a Favicon to your site, but why do you need to have a plugin for that when you can simply add the code to your theme instead?

Some plugins you want to keep, of course. A good SEO plugin has too much value to ignore. A spam-filtering plugin like Akismet is essential if you keep comments enabled. A security plugin is more crucial than ever in these days of constant site breaches.

While you’re at it, update any plugins you can. For one thing, as plugins proceed in development, they tend to gain both features and optimizations. It’s possible that an older, clunkier version of a plugin can be updated to take up fewer server resources and speed up your site. You also want to keep plugins up to date so they don’t become security issues in the future.

Special note: be wary of any plugin that is known for slowing down your site. One way this happens is with premium, closed-source plugins with encrypted code. In order to decrypt these plugins so they can run, your server needs to call back to the plugin host’s server, which by definition adds time to every interaction. You might also want to double-check that you’re not using a plugin that makes constant database queries, like any of these.

Adopt a Speed Architecture

The Genesis framework for WordPress, offered by StudioPress, is a sort of alternate framework for WordPress. It takes all of the default architecture WordPress has put together and hacks it around, ruthlessly optimizing and culling slow bits until it’s focused entirely on speed.

The downside to using a framework like this is it limits you in terms of what other plugins or themes you can use. It’s sort of like using a different CMS entirely, just with all of the back-end functionality you expect from WordPress. Give it a look; it might be worth investigating, or it might rule out certain features you really can’t live without.

Implement Caching

With WordPress, when a user sends a request to fetch a page on your website, your server has to query your database back and forth. It needs to pull static resources like images and theme files from one area, and it needs to pull or generate dynamic content from outer sources. All of this requires repeated server calls.

This is fine for one user, but what happens when you have hundreds or thousands of people making requests for the same page? That’s a lot of redundant loading. Why not just create and render the page for one person, and then save that rendered version and serve it to all the others?

Obviously, this only works if the page doesn’t change from person to person, but how often does a site change like that? Minor elements change, like ads or related posts, but the text, the navigation, and the majority of the site never changes.

Caching allows your server to save these rendered versions of the site to serve to new visitors, minimizing a lot of server calls and reducing server loads. You can do caching in a bunch of different ways, typically with plugins. Theme Isle has a really good rundown on caching you can read here.

You can also implement caching on the server side, forcing caching through Apache or NGINX. That’s a bit more complex, though, so I’ll leave it to you to dig in if messing with server infrastructure is something you feel comfortable doing.

Use a Content Delivery Network

A huge portion of the load on your server is loading large files, and 99% of the time, the large files you’re loading are going to be images, videos, and other forms of media. Consider that the text for this entire article is around 10kb. Now consider that the logo for this site, up there in the corner, is 5kb. Any larger image is going to be 20kb, 50kb, or even more, and that’s smushed down. Videos, meanwhile, are measured in mb or even gb for long, HD video.

Media content is huge, and it takes time to load from a server. The further the server is away geographically from the user, the longer it takes. This is why content delivery networks were created.

A CDN can go a long way towards speeding up your site, by offload the onus of loading media from your server. Who do you think has more server resources to dedicate to loading your image, your web host, or Amazon?

Of course, you need to choose a good CDN, you need to configure it properly, and you need to offload your media to it. It’s not a trivial matter, but it’s a huge benefit when set up properly.

Minimize External Queries

Now, one thing about CDNs is that they make up for their external query by loading your media faster than your server can do it. That isn’t the case for every form of external query.

An external query is any time your server needs to call out to another site or another server to fetch information. Every one adds, at the absolute minimum, the time the server call takes plus the time the other server takes to prepare and send the data your server is asking for.

Think about your site; how many times does your server do this? It might be more than you think. Every bank of social media buttons, for example, needs to call out to each server to get updated social share counts. Most buttons cache these for a while, but it’s still an external call. The same goes for fetching RSS feeds, embedding content from social networks or YouTube, and any other form of embedded content.

Your site will load faster, with less strain on your server, when you have fewer external queries to process when a page is loaded.

Load Scripts Later

Scripts are another area where sites often take some time to load and function. The problem is not the scripts themselves; often a good script takes milliseconds to execute. The problem comes from script placement.

When you place a script at the top of your page, and you don’t have lazy loading in place, that script needs to execute before anything further down the page even starts to load. This is almost never necessary! You don’t want a script acting as a gatekeeper unless the results of that script are essential to the proper loading of the subsequent content.

Lazy loading your scripts is one option; by setting the scripts to load on a delay or concurrently with other content, they no longer become gatekeepers. If you don’t want to mess with lazy loading, you can also simply put the scripts at the bottom of your page. There’s often no functional difference – and the page appears loaded before it fully loads – but it means there’s less delay before content is up and visible for users.

Upgrade PHP, Apache, NGINX, Etc

I touched on upgrades up there talking about plugins, but it’s important for your server architecture itself as well. PHP, for example, put massive performance enhancements in their transition from PHP6 to PHP7. By upgrading to PHP7, you’ll be able to take advantage of those performance enhancements. PHP8 likely isn’t going to be released until 2021 or so, so you have a few years before you need to worry about updating again.

You always run a risk when you upgrade your server architecture itself. Some code you currently use might not be usable on an upgraded version of PHP, or of Apache, or what have you. For example, WordPress versions prior to 4.4 are not supported by PHP7. If you’re using an older version of WordPress, first of all, that’s a massive security risk. Secondly, trying to upgrade PHP will likely break your site until you upgrade WordPress as well.

Thankfully, a lot of web hosts make toggling PHP versions fairly easy; all you need to do is click a button in the back end server management. That said, you’ll need to do a site audit to make sure any CMSs, any scripts, and any custom code will function in an upgraded environment.

Examine Server Logs for Resource Leaks

If you have a mind to get more technical, you can start to dig into your server logs. You need to know what you’re looking at to make sense of things, but you can audit your logs looking for anything that seems to be making more calls or taking up more server resources than it should be.

Sometimes old, bad code gets caught in loops, fails to clear memory, or otherwise starts using more resources each time it is cycled. Memory leaks and excessive server load are signs of something Not Quite Working Right.

The way you enable and access server logs will vary from architecture to architecture, so it’s worth learning about how your site is set up and how you can make use of the information you have access to for future optimizations.

Clear Out Old Baggage

The older a site is, the more accumulated stuff you’re likely to have lying around. Of particular note are old e-commerce sites; databases tend to get full of old orders, products that have been discontinued, and so on. Other sites might have piles of old iterative backups, old disabled plugins or script files, themes you no longer use, or even old content you “deleted” by NoIndexing it.

Periodically, perhaps once a year, you should audit your site and clear out old bloat you don’t need. You can use database cleaners to remove bad records, though be VERY careful when removing records from databases; you can screw up query results or even accidentally remove an entire database. Other things, like disabled plugins or disused themes, can be removed with little potential repercussions.

On WordPress specifically, you can look into things like trackbacks and spam comments, which take up space in your databases even if you don’t have them visible. Delete or remove them to clear up space and make everything run just that much more smoothly.

Upgrade Servers

At the end of the day, sometimes your server is just not very good. A shared host with 2000 other sites on the same piece of hardware is going to have trouble. Your average shared host shares anywhere between 500 and 2,000 websites on the same server. Upgrading to a higher quality shared host, or even a high quality dedicated server, means you’ll have a larger share of resources to yourself and you’ll have a smoother, more functional server. It might be expensive, but it’s often worth the investment.