Investigating and Fixing a Slow Website

Recently a client reached out to us whom we hadn’t heard from in a while: their website had become very slow. It wasn’t just impacting site visitors, the admin was very slow as well, making it difficult for them to update.

Once we were able to track down the source of the problem the fix was pretty straightforward. Getting there though took a few hours of head pounding, and a couple of fistfuls of experienc.

One afternoon this past June we received an email from a client whose site we had built about 2 years ago, but hadn’t heard from in a long time. We like to stay in touch with clients after a site launches, but it doesn’t always happen.  In this case the client was a fairly large organization, and after launch they’d been maintaining the site on their own.

The site is Wordpress built with Divi, as most of our client sites are (we specialized in Divi), had multiple languages, and quite a few plugins to support the various features & functionality in use on the site.

They’d been operating under the assumption that the problem was with Divi.  They couldn’t get the editor to load, and had been reaching out to Elegant Themes (makers of Divi) for support, but ET weren’t able to help them.

It wasn’t until about 6 pm that we heard from them – but if there is one thing that bothers me it is a site that isn’t performing, so I logged in to have a look.

I couldn’t believe how slow the back end was.

Forget page editing; just moving between menu items was brutal – like clicking on Pages, Settings, or Plugins.   I tried to load the page editor and gave up waiting for it.

On checking the Site Health screen I found it reporting a “Severely outdated SQL server“. I googled the version they were running and found that it had reached its end of life in 2013 – almost 10 years ago! That wasn’t necessarily the issue, but it certainly wasn’t helping.  Needless to say, we didn’t host this website (before, we do now).

After trying to look around a bit more for the source of the issue I decided to take a backup copy of the site instead.  Rather than troubleshooting at molasses speed, I wanted to bring a copy of the site up on one of our hosting servers – one we knew didn’t have any underlying issues.

12 hours later the backup still hadn’t finished.

Assuming it had hung up somehow I cancelled the backup, set up a different backup process, and crossed my fingers. This time it finished in about an hour and a half, and generated a 20GB backup file. This was a bit surprising – I knew they had a lot of images, but this was much larger than I expected.

I restored the backup on one of our development servers, logged into the back end, and right away it was much faster. I could easily move from section to section, and proceeded to look at page editing.

Divi still wouldn’t load though.  I updated Divi and still no luck.  While it is possible that there is a problem with Divi – I didn’t think it likely.  We look after a number of clients sites and none had similiar issues.

Suspecting it was some sort of plugin conflict I had a look at the plugins that were installed. There were all the ones we’d installed when we launched the site, and then a number of others that had been installed since. One plugin jumped out at me as being one that could possible cause the issue – and sure enough, I disabled that plugin and Divi loaded.

After moving the site and applying this one change I asked the client to test out the site.  Their feedback was “Uber fast by comparison [… to their own site]”

There was still more to do, though at this point it came down mostly to standard website maintenance, some user training, and some bad code added by one of their in-house developers.

• “the front end editing display doesn’t display like it used to”: at some point they’d flipped the front end editing mode into wireframe mode – there is a setting for it on the page – I changed it back
• even once the mode was set correctly, the editing display was still somewhat broken. The site could be edited in the front end, but the formatting was off.
  This took a bit longer to track down. At some point in adding an online learning system someone on their team had added some code to the sites functions.php file. I commented it all out and the front end display was back to the way it should be. Then it was just a matter of debugging that code a bit.
• That plugin that was breaking divi just needed an update – and a number of other plugins were updated as well
• We added the caching plugin we typically use (WP Rocket)  – actually I think re-added.  I’m pretty sure it would have been there when we launched the site.  We also did some other site optimization to get it moving even faster.
• and other random bits and bobs

At the end of the day, the source of months of pain came down to just a couple of things:

• a poorly performing server with out of date software
• custom code added to the site that was breaking editing functions
• some out of date plugins
• and a little bit of a user training issue.