How to Reduce Your Server Response Time with WordPress. Part 2.
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.
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.