Why your WordPress site got slower this year
The site was fine when it launched. Nobody changed the design. And yet it now takes a beat too long to appear, the admin feels sticky, and a customer mentioned it "took a while to load." Nothing broke. It just got slower, gradually, the way a car does.
There are five usual causes, and you can check all of them in about ten minutes.
1. Plugins that accumulated
Every plugin you added since launch is still loading. Most add code to every page. Open the plugin list and look for ones you forgot you had. A site that launched with eight plugins and now runs twenty-five has roughly tripled the code every visitor downloads.
The quick test: deactivate everything that is not essential, open the home page in a private window, and feel the difference. Then turn things back on one at a time.
2. Images that were never resized
Someone uploaded a photo straight from a phone. It is 4,000 pixels wide and three megabytes, displayed in a box 600 pixels wide. WordPress makes smaller copies, but themes and builders do not always use them, and some uploads skip the process entirely.
Open your media library, sort by size, and look at the top ten. If any are over 500 kilobytes and appear on a busy page, that is your slowest asset.
3. The database grew
WordPress keeps a revision of every edit to every page. It keeps transients, logs, spam comments and the leftovers of plugins you deleted years ago. None of this is visible, and all of it makes queries slower.
Most hosting panels show the database size. A small business site should be a few tens of megabytes. If it is several hundred, something is hoarding.
4. The hosting did not grow with the site
Shared hosting is sized for a site that gets a few hundred visits a day and runs a handful of plugins. Add a store, a booking calendar and a chat widget, and the same plan is now running an application, not a brochure. The server has not changed; the demand has.
You can see this when the site is fast at six in the morning and slow at noon. That is the server, not the code.
5. Scripts from outside
Analytics, a chat widget from a third party, an embedded map, a social feed, a font loaded from somewhere else. Each one is a request to another company's server, and the page waits. Four or five of these can add a full second on a phone.
Open the page in a browser's developer tools, look at the network tab, and sort by domain. Everything that is not your own domain is a decision.
What "slow" actually costs
Search engines measure how long a page takes to become usable and treat it as a ranking signal. Visitors on phones leave early. For a business site the number that matters is not a score; it is whether the person who searched for a plumber at nine at night waited for the page or tapped the next result.
The maintenance nobody schedules
How to measure it
Do not trust your own browser; it has the site cached and loads it from memory. Use a private window, or a free page-speed tool, and test the home page and one inner page. Two numbers matter: how long until something appears, and how long until the page stops moving. Write them down. A measurement from last quarter is the only way to know whether this quarter's change helped.
Test on a phone connection if the tool offers it. Most of your visitors are on one.
The fixes, in order of effort
Resizing images is an hour of work and often the largest single gain. Removing unused plugins is an afternoon. Cleaning the database can be done with a plugin that removes revisions and transients, or by asking the host. Moving to better hosting is a decision with a monthly cost attached, and it is the right one when the site has become an application.
Caching deserves its own line. A caching plugin, or caching at the host, serves a saved copy of each page instead of rebuilding it for every visitor. For a site that does not change minute to minute, this is the largest gain available after images. Pages with a cart or a booking calendar need to be excluded from it, and that exclusion is the part most people miss.
What not to do
Do not install a plugin to fix the slowness caused by plugins. Speed plugins can help, but they add their own weight, and a site with three of them is slower than a site with none. Do not switch themes to fix speed; the theme is rarely the cause and the switch is rarely free. And do not accept "it's WordPress, it's always slow." It is not. It is a site that has been used for a while and not looked at.
Before you click update
Updates are part of keeping a site fast and safe, and they are also where sites break. The risk grows with the plugin count, because the number of things that can disagree grows with it. Five minutes of routine turns an update from a gamble into a chore.
A backup you have seen restore. Most hosts offer one and most owners have never tested it. A backup that has never been restored is a hope.
Read what changed. Words like "major", "rewrite" or "breaking" in a changelog mean that update waits for a quiet day, never a Friday afternoon. Use the host's staging copy for those if it has one.
In order, one at a time. WordPress first, because plugin updates are written against the current version. Then the theme. Then plugins one by one, busiest last, looking at the site between each. One update followed by a white screen is a fact; fourteen at once is a mystery.
Check the pages that make money. Home, the contact form, the checkout, the booking page. Keep screenshots of each working, including a successful form submission and a confirmation. Most breakage is not a white screen; it is a button that stopped doing anything, visible only to someone who remembers it working.
Automatic for small fixes only. Let minor and security updates install themselves; keep major versions manual. Most plugins can be set individually.
PHP is a separate deadline. Hosts retire old PHP versions, and old plugins are what breaks on a newer one. Most control panels let you switch the version and switch it back, so try the new one on a quiet day and check the same pages.
If it breaks anyway, it is almost always one plugin. Rename that plugin's folder in the host's file manager or over FTP and the site comes back. With a backup the fix is minutes; without one it is days.
None of the five causes above is a bug. They are what happens when a site is used. A speed check once a quarter, the same ten minutes, keeps all five in view. The sites that stay fast are not the ones built better; they are the ones someone looks at.
If the slowdown traces to the plugin stack, how many plugins is too many covers how to thin it. For how search engines read a slow page, why your pages are not in Google yet.
