Speeding Up a Slow Website Without Rebuilding It

A lot of the messages I get start with "my website is slow, do I need a new one?" Usually the answer is no. Most slow small business sites I look at are slow for a handful of fixable reasons: huge photos, too many plugins or scripts, no caching, or hosting that has been struggling for years. Fixing those takes days, not the weeks a rebuild takes, and the owner keeps the site they already know.

In this post I'll go through the order I work in when someone asks me to speed up an existing site, what each fix involves, and the cases where a rebuild really does make more sense. If you want the details on LCP, INP and CLS and the red "Assessment: Failed" line in PageSpeed Insights, I wrote about that separately in how I fix Core Web Vitals.

First, measure before changing anything

I never start by installing a speed plugin. I start by writing down how the site performs today, so I can show the owner what changed and so I don't fix the wrong thing.

• PageSpeed Insights on mobile for the homepage and the two or three pages that bring in the most enquiries. I note the real user data at the top if there is any, and the lab numbers below it.
• A real phone on mobile data. I open the site on my own phone with Wi-Fi off and just watch. How long until I see the main heading? Does the page jump? Does the menu respond straight away?
• Time to first byte. If the server takes more than about a second just to start sending the page, no amount of image work will make the site feel fast. This one number tells me early whether hosting is part of the problem.
• Page weight. In the browser's network tab I check the total size of the page and which files are the biggest. On slow sites it's common to see 5 to 10 MB for a single page, and most of that is images.

After the work is done I run the same checks again on the same pages.

The fixes I make, in the order I make them

I go roughly from the biggest effect with the least risk to the smaller, fiddlier gains.

1. Resize and convert the images

This is the fix that helps most often. Owners upload photos straight from their phone or camera, 4000 pixels wide and 3 to 6 MB each, and the site shows them in a box 800 pixels wide. The visitor downloads the full file anyway.

I resize every image to the largest size it's actually shown at (about double for sharp screens), convert it to WebP, and keep a JPG fallback only where needed. Images below the first screen get loading="lazy" so they only load when someone scrolls to them. The hero image at the top is the opposite: it should load first, so it doesn't get lazy loading. I also add width and height to images so the page doesn't jump while they load.

2. Remove what the site doesn't need

Older sites collect things over the years: a slider nobody looks at, two analytics tags, an old chat widget, a Facebook feed, a popup plugin that was switched off but still loads its files. Each one adds requests and JavaScript that the phone has to download and run.

I list every plugin and every third party script and ask the owner about each one. Is anyone using this? Do you look at this report? Often we remove a third of them.

3. Turn on caching and compression

Without caching, the server builds every page from scratch for every visitor, running PHP and database queries each time. With page caching, it builds the page once and serves a saved copy until something changes.

On WordPress I use one well configured caching plugin, or the host's own cache if it has one. On custom PHP sites I add simple file caching for pages that rarely change. I also make sure the server sends files compressed (gzip or Brotli) and sets browser cache headers, so returning visitors don't download the same logo and CSS on every page.

4. Fix fonts and the files that block the page

A common one: the site loads four or five weights of a Google Font, plus an icon font for six icons. I cut fonts down to the two weights actually used, host them on the same server, and add font-display: swap so text shows straight away. Icon fonts get replaced with small inline SVG icons.

I also look at the CSS and JavaScript that load in the head of the page. Scripts that aren't needed for the first screen get defer, and large unused CSS files from old page builders or themes get trimmed where it's safe.

5. Check the database and the server

If time to first byte is still slow after caching, I look deeper. On WordPress that usually means a database full of old revisions, expired transients and leftovers from deleted plugins, or a slow query from one plugin. On custom PHP sites it's often a missing database index or a page running the same query dozens of times in a loop.

I also check the PHP version. Moving an old site from PHP 7 to a current PHP 8 version often makes it noticeably faster on its own, but it has to be tested properly first, because old plugins and old code can break on newer versions.

6. Decide whether hosting is the real problem

Sometimes I do all of the above and the server is still slow. Very cheap or overloaded shared hosting, a server on the other side of the world from your customers, or a plan that has run out of resources can all cause this. In that case I tell the owner plainly that moving host is the next step, and I don't keep charging for small tweaks that won't fix it.

What I'm careful about

Speed work can break things if it's rushed. A few habits I stick to:

• Backup first. Files and database, before any change on a live site.
• One change at a time. If I change five things at once and the contact form stops working, I don't know which change did it.
• Test the important parts after each step. The contact form, WhatsApp button, menu on mobile, any booking or checkout. A fast site with a broken form is worse than a slow one.
• Don't chase a perfect score. Going from 40 to 85 on mobile usually makes a real difference for visitors. Going from 92 to 100 often means removing things the business actually needs, like a map or a review widget.

When a rebuild does make sense

I don't want to pretend every site can be saved. I suggest rebuilding when:

• The site is built on a heavy page builder or theme that loads megabytes of code on every page, and removing it would mean redoing every page anyway.
• The code is so old that it can't run on a current PHP version without a lot of rewriting.
• The site also has bigger problems: it doesn't work well on phones, the content is out of date and the owner can't edit it.

Even then, I tell the owner which quick fixes are worth doing now so the current site performs better while the new one is built.

What you can check yourself today

If you're a business owner and not technical, here are three things you can do without touching any code:

1. Run your homepage through PageSpeed Insights on mobile and save a screenshot of the result.
2. Open your site on your phone with Wi-Fi off and count how many seconds it takes before you can read the main heading.
3. Write a list of every plugin, widget and tracking tool on the site, and mark the ones you actually use.

That's exactly the information I ask for at the start of a speed job, and with it most developers can tell you quickly whether your site needs a few days of fixes or something bigger. If you'd like me to take a look at yours, you can send me the link and I'll tell you honestly which one it is.