When someone asks me to speed up a slow WordPress site, the conversation usually starts with a quote from another developer for a full rebuild. Sometimes that is the right call. Most of the time it is not. The slow sites I have worked on had the same four or five problems, and every one of them could be fixed on the existing site without touching the design.
Here is the order I work in, and why.
Measure first, or you are guessing
Before changing anything, I run the homepage, one product or service page, and one blog post through PageSpeed Insights and write down the numbers. I also look at the Core Web Vitals report in Search Console, because that is field data from real visitors, not a lab test from a fast connection.
I save a copy of everything. When the client asks if the work made a difference, I want to show them the before and after, not my impression of it.
Why is my WordPress site so slow?
This is the question people actually search, and the honest answer is that it is usually several small things stacked on top of each other. In my experience the usual suspects, roughly in order of how often they are the main cause:
- Cheap shared hosting or an old PHP version.
- No page caching, so every visit rebuilds the page from the database.
- Huge images uploaded straight from a camera or a supplier’s folder.
- Too many plugins, a few of which load scripts on every single page.
- Third party scripts: chat widgets, tracking pixels, embedded reviews, social feeds.
A page builder theme can add weight too, but I do not start there. It is the most expensive thing to change and rarely the biggest win.
Fix hosting and PHP before anything clever
If the server takes a long time to respond, nothing you do on the front end will fully cover it. I check time to first byte in the PageSpeed report. When it is slow on an uncached page, the host is the bottleneck.
The quick wins here are boring. Update PHP to a currently supported version through the hosting panel, after taking a backup and testing on staging if the host offers it. Then look at whether the plan is simply underpowered for the site. Moving a busy WooCommerce store off the cheapest shared plan has done more for some sites than every plugin I could install.
Turn on page caching and check it works
Caching saves a finished copy of each page so WordPress does not rebuild it for every visitor. Many managed hosts include it at the server level. If not, a caching plugin does the job. I use one caching solution, never two, because stacking them causes strange bugs that eat hours.
On stores I make sure cart, checkout and account pages are excluded. Caching a cart page is how one customer ends up seeing another customer’s items, which is a far bigger problem than a slow page. After switching it on, I load pages in a private window and check the response headers to confirm the cache is actually being hit.
Shrink the images
On the stores I ran with thousands of products, images were always the heaviest part of the page. Supplier photos come in at whatever size the supplier had, which is often far larger than any screen will show.
- Set a maximum upload size so new images get resized on the way in.
- Run an image optimization plugin over the existing library to compress and serve modern formats like WebP.
- Make sure images below the fold load lazily, and the main hero or product image does not, since that one affects how fast the page feels.
- Set width and height on images so the layout does not jump while they load.
I run bulk optimization in batches and keep the originals until I have checked a sample of pages. A compression setting that looks fine on a product shot can look rough on a photo with text in it.
Audit plugins and scripts
I export the plugin list into a spreadsheet and go through it line by line. For each plugin I ask what it does, whether anything on the site still uses it, and whether it loads assets on pages where it is not needed. A form plugin loading its scripts on every product page is a classic example.
Inactive plugins get deleted. Duplicate functionality gets merged. For the ones that stay, a script manager plugin lets me unload their files on pages that do not use them.
Third party scripts get the same treatment. I list every tag in the site and in Google Tag Manager, then ask the client which ones they still look at. Old pixels from ad platforms nobody uses anymore are surprisingly common. Each one is another request to someone else’s server that the visitor has to wait on.
Clean the database
Years of post revisions, expired transients, spam comments and leftover tables from deleted plugins build up. On their own they rarely make a site slow, but on older stores the autoloaded options can get heavy and slow down every request. I take a full backup, then clear revisions and transients and check the autoload size. This is the step where a backup matters most, so I never skip it.
When a rebuild actually makes sense
If the theme is abandoned, the page builder is generating enormous pages, and the site needs a redesign anyway, then rebuilding can be the right move. But I want that decision made after the cheap fixes, not instead of them. Often the fixes buy a year or more, and the rebuild happens on the client’s schedule, not out of panic.
If your site is slow today, start with this: record your PageSpeed scores, check your PHP version, confirm caching is on, and compress your ten heaviest images. Then measure again before you spend money on anything bigger.