Your WordPress site was fine last month. What changed?
A site that has slowed down has a cause with a date on it. Five usual suspects, and how to tell which one you have.
You open your own home page and wait. A month ago it came up straight away. Nothing on the site looks different, and you have not touched it.
A site that has always been slow has a design problem. One that was quick and is not now has a cause with a date on it, and finding the date is most of the job.
Start with the calendar
Before you measure anything, work out roughly when it slowed down. Check your emails, your own memory of the last time it felt fine, and the analytics if you have them. Then write down everything that happened in the fortnight before: a plugin installed, a batch of photos uploaded, an update clicked, a message from your host about maintenance.
That list is your suspect list. It beats any speed tool for the first ten minutes, because a tool tells you what is slow and the list tells you what changed.
A plugin that arrived recently
This is the most common cause on small business sites. Somebody installed a plugin to fix one problem, a booking calendar or a pop-up or a slider, and it now loads its files and runs its queries on every page, including the ones that have nothing to do with it.
Go to Plugins, sort by what was added or updated last, and look at the top three. On a copy of the site rather than the live one, switch each off in turn and time the home page. Our piece on why a site is slow covers that test in more detail. A plugin that was fine for two years can also turn slow after an update, so an update counts as a change too.
Images that came in at full size
A phone photo is often 4,000 pixels wide and several megabytes. WordPress will put it into a space 600 pixels wide and send the visitor the whole file. One of these costs you a second. A gallery or a new product range uploaded in one afternoon costs you a lot more.
Look at the Media Library, sorted by date, and check the file sizes of the recent uploads. Anything over about 500KB on an ordinary page is worth resizing. This one is also the easiest to fix, and it is why the slowdown often starts the week somebody updated the portfolio.
A database that has filled up
Every WordPress site keeps a database of its pages, settings and visitors’ form entries. Over a few years it collects revisions of every page you ever edited, spam comments, expired temporary data from plugins you removed long ago, and logs that some plugin has been writing without anyone reading them.
This does not usually cause a sudden drop. It causes a gradual one that tips over when the site gets busy or a new plugin asks the database a harder question than the old ones did. If the slowdown crept in over six months rather than appearing on a date, look here. A clean-up is a job for somebody with a backup in hand, because deleting the wrong table cannot be undone.
A host that moved you
Hosting companies move customers between servers, and now and then they put you on a busier one. Nobody tells you, because from their side nothing is wrong.
The check is a number called time to first byte, which is how long the server takes to begin answering. You can read it in PageSpeed Insights. If it has gone above about 0.8 seconds and the page itself has not grown, the server is the cause. We moved one site from 4.15 seconds average load to 0.52 by putting it on its own server, with nothing else on the page changed. If your host is the problem, no plugin fixes it, and you will want to read about shared hosting against dedicated.
A bot on your login page
Every WordPress site has a login page at a known address, and automated scripts try passwords on it all day. Most of the time that is background noise. Now and then a bot picks your site and sends thousands of attempts an hour, and your server spends its time answering them instead of your customers.
Signs: the site is slow at odd hours as well as busy ones, your host has sent a warning about resource use, or a security plugin shows a long list of blocked logins. The fix is to limit login attempts and, better, to switch on two-factor authentication so a correct guess still gets nobody in. If the traffic is heavy, ask the host to block it before it reaches WordPress.
In what order to check
- Write the dates down. What changed in the fortnight before it slowed down.
- Read the time to first byte. High means the server or a bot. Low means the page itself.
- Check recent plugins and recent uploads. Between them they explain most sudden drops.
- Look at the database last, and only with a backup.
Most of this takes half an hour and costs nothing. The part that is hard to do by yourself is the server side, because you cannot see how busy the machine is or what is hitting it.
If you would like somebody to look at that for you, our website care and hosting includes watching for exactly this, and a free website review will tell you which of the five you are dealing with.
