Almost every conversation about a slow WordPress site starts in the wrong place. Someone runs a testing tool, sees a number they do not like, installs a caching plugin, and hopes. Sometimes it works. Usually it moves the score and not the experience.
Here is what actually causes slow WordPress sites, roughly in the order we find them, and how to work out which one is yours.
First: stop trusting the lab score
Lighthouse and PageSpeed Insights run a simulated test on one page, from one location, with an empty cache. Your customers arrive on real devices, on real connections, often with a full plugin stack running and a session cookie that bypasses your page cache entirely.
Google ranks on field data — the Chrome User Experience Report, collected from actual visitors. Open Search Console, go to the Core Web Vitals report, and look at what real people experienced. If the lab score is green and the field data is not, the field data is the one that matters.
1. The database
On sites more than a couple of years old this is the single most common cause, and the one most often skipped because it is invisible from the front end.
- Autoloaded options. Every page load reads the entire autoloaded options table. Plugins that never cleaned up after themselves leave megabytes in there.
- Missing indexes. Meta queries across large tables without an index will scan everything, every time.
- Post revisions and transients. Years of accumulation nobody has ever pruned.
Install Query Monitor on a staging copy and look at the slowest queries on your heaviest page. If one query is taking hundreds of milliseconds, no amount of front-end work will save you.
2. Plugin weight on every page
Most plugins load their CSS and JavaScript on every page of your site, whether that page uses them or not. A contact form plugin loading its assets on your homepage is very common and completely unnecessary.
Audit what each plugin costs: how many queries it adds, and how much CSS and JS it enqueues. Then remove, replace, or load conditionally. Twenty plugins doing the work of six is not unusual on an inherited site.
3. Render-blocking CSS and JavaScript
Anything in the <head> that the browser must fetch and parse before it can paint delays your Largest Contentful Paint directly. Third-party scripts — tag managers, chat widgets, heatmaps — are usually the worst offenders and the easiest to defer.
4. Images that were never optimised
A 4MB hero image uploaded straight from a camera will beat every other optimisation you make. Serve modern formats, size images to their actual display dimensions, lazy-load anything below the fold — and never lazy-load your LCP image, which is a mistake we see constantly.
5. Caching that cannot help where it matters
Page caching serves anonymous visitors a stored copy. It does nothing for cart, checkout, My Account, or any logged-in session — which on a store is precisely where revenue happens.
Those pages need a different approach: object caching so repeated queries are not re-run, and query optimisation so the ones that do run are fast. If your store is quick on the homepage and slow at checkout, this is why.
6. Server response time
If Time To First Byte is consistently poor, the problem is underneath everything else and nothing on the front end will fix it. Check whether it is genuinely the host or an unoptimised site running on adequate hardware — a well-tuned site on mid-range hosting routinely beats a bloated one on expensive hosting.
7. Layout shift
Not speed exactly, but it is a Core Web Vital and it is what makes a site feel broken. Content jumping while it loads almost always comes from images without dimensions, web fonts swapping in, or ad slots that expand after they arrive. Reserve the space before it is needed.
What to fix first
In order of how often it turns out to be the answer:
- Measure with field data so you know what you are solving
- Database — autoloaded options, indexes, slow queries
- Plugin audit — what is loading where, and why
- Images and render-blocking assets
- Caching architecture, including the uncacheable pages
- Hosting, only once you have ruled out the above
The reason order matters is that people routinely spend a month on image optimisation for a four percent gain while a single unindexed query costs them two seconds on every page.