Why your WordPress site is slow, and what it is costing you

Run your homepage through PageSpeed Insights. Use the mobile tab, not desktop. Desktop scores flatter everybody and your customers are on phones.

If the number is under 50, this post is about your site.

Why the number matters more than it sounds

Google’s own research puts the bounce rate jump at roughly 32% when load time goes from one second to three, and it climbs steeply from there. That is not a ranking penalty argument, though page speed is a ranking factor too. It is simpler than that: people leave. Somebody searched “plumber near me,” tapped your listing, watched a white screen, and tapped back. You never saw them in any report.

For a business where one job is worth several hundred dollars, a handful of those a week is real money.

The five usual causes

1. Uncompressed images. This is the big one, and it is nearly always the biggest one. A photo straight off a phone is 4 to 8 MB. Ten of them in a gallery is 50 MB of downloads on a page that should weigh under 1 MB. Drone shots are worse.

The fix: resize to the dimensions actually displayed, convert to WebP, and lazy-load anything below the fold. Squoosh does this in a browser for free. Expect a 90% reduction with no visible quality loss.

2. Plugin sprawl. Every active plugin can add CSS and JavaScript to every page, whether or not that page uses it. A contact form plugin loading its scripts on your about page is normal WordPress behaviour and pure waste.

The fix: deactivate anything you cannot name the purpose of. Most sites I look at are running 20-odd plugins and genuinely need six.

3. Page builders. Elementor, Divi, WPBakery. They are why non-developers can edit their own site, which is a real benefit, and they also emit deeply nested markup plus a large runtime on every page load. You are trading speed for editability. That can be the right trade. It is worth knowing you made it.

4. Cheap shared hosting. If server response time (TTFB) is over 600ms, no amount of front-end work saves you, because nothing starts until the server answers. This is common on the $3/mo plans where your site shares a machine with several hundred others.

5. Third-party scripts. Chat widgets, tracking pixels, review carousels, font loaders, tag managers. Each one is a connection to somebody else’s server, and your page waits. A single chat widget commonly costs 300 to 800ms. If nobody is answering the chat, it is pure loss.

Which fixes are worth paying for

Fix	Effort	Typical gain
Compress and resize images	Low	Large
Remove unused plugins	Low	Moderate
Add caching plus a CDN	Low	Moderate
Move to better hosting	Medium	Moderate
Remove the page builder	High	Large
Rebuild on a static stack	High	Very large

The first three are worth doing on any site, today, regardless of what you do next. Together they usually move a score from the 30s into the 60s or 70s.

When a rebuild beats a rescue

If the site is more than about four years old, running a page builder, and scoring under 30, a rescue often costs more than a rebuild and lands somewhere worse. The honest test: if fixing it costs more than half of what replacing it costs, replace it.

Static sites sidestep the whole category. There is no server assembling a page per request, no plugin runtime, no database query. The page is a file, served from an edge location near your customer. That is why the sites I build score in the high 90s without anybody optimising anything, and why they cost about nothing to host.

Two minutes, right now

1. Open pagespeed.web.dev, paste your URL, read the mobile score.
2. Scroll to Opportunities. The top item is where your time is going.
3. Run your closest competitor through it too. That comparison is usually the part that makes the decision for you.

If you would rather have somebody read the report and tell you plainly which of the five causes above is yours, that is what the speed audit is, and the fee comes off a rebuild if you decide to go that way.