Installing a WordPress performance plugin is not always enough. Like a detective, sometimes you need to dig into the root of things and identify areas of improvement.
A Message in Staging Site Updates
Recently, I was routinely updating a client’s website and had to update the already created staging site, which would overwrite the staging site with a copy of the original site, allowing me to update with the current situation of the live site. We’re talking about a site that has a lot of active users on it with a lot of important data. Think of a heavy database. I used a plugin to manage staging site in this case.
Before starting the process, I had already excluded heavy tables that had unnecessary data, like logs. My criteria for judging that a table was heavy was simply by looking at its size. If a table was in the gigabytes, and I didn’t really need it to be updated on the staging site, I would exclude it.
While waiting for the staging site to update, I noticed that it became extremely slow at a certain point. Specifically during database copying. The plugin showed progress by the percentage (0-100%) and it stayed for a long time at 88% without increasing. While this isn’t exactly rocket-science, it is a crucial step that a lot of WordPress users and developers tend to miss sometimes. A couple of unrelated problems had happened with the copying process and I had to restart it a few times, only to get stuck at 88% much longer than was needed. I opened the logs to look at where it was stuck and noticed that a table that seemed particularly small in size (less than 300MB) . That table was causing the holdup.
Database Table Miscalculation
Now, why didn’t I exclude this table? I didn’t because my criteria was the size. I overlooked the fact that there could be a database table of a small size but a lot of rows. I’ve seen a table as large as 1.4GB with about 140,000 rows. This table was less than 300MB and has about 4 million rows. The plugin I used processed a table by the rows, which is something I easily overlooked.
My point is that even though I did overlook what was important and used the criteria that wasn’t as important, I found the bottleneck. A bottleneck in WordPress performance optimisation is a point where your website can’t do things as fast because of limited resources. In my process of updating the staging site, processing this database table was the bottleneck. It was such a large table and the plugin I used couldn’t handle it fast enough, and it slowed down. Ideally, I could use a more powerful tool like system tools, but performance optimisation is sometimes about optimising what you have without necessarily adding more resources, like using a better tool. In my case, I could do without the large database table so I excluded it, and the next attempt at updating the staging site was fast and easy.
WordPress Performance Plugin vs Hands-On Work
If you’re dealing with a slow site, it can be tempting to find a WordPress optimisation plugin to try to speed up your website. You may find some success with that, along with some backtracking due to potentially breaking things when minifying and combining files. Sometimes though, you need to really look at why your site is slow first. Could it be that you are using a lot of heavy images? Too many plugins? Uploading videos on a shared host rather than embedding them on YouTube for example? Or perhaps it is a plugin that stores data poorly and creates bottlenecks in your database. Truly optimising your website for speed involves hands-on work that continues as you work on your website. It can be some work, but the benefit in the long run will be tremendous.
So, before reaching for the biggest speed plugin in the market, try seeing if best practices would solve your problems first.
