Ordered by how much difference each change actually makes, not by how technical it sounds. Most slow WordPress sites are fixed by the first two items.
If you do nothing else: serve correctly sized images in a modern format, and turn on page caching. Between them they resolve the majority of slow WordPress sites, and neither requires touching code.
Measure first, though — a single full-resolution hero image can outweigh every other problem on the page combined, and you cannot tell by looking.
Optimising without measuring is how people spend a weekend minifying CSS on a site whose real problem is a 4MB background image. Before changing anything, get two pieces of information: what real visitors experience, and what specifically is heavy on the page.
A lab test runs once, from one location, on a simulated connection. Field data aggregates what actual visitors experienced on actual devices. They frequently disagree, and when they do the field data is the one that reflects your customers and informs search ranking. Use lab tests for comparing before and after a change; use field data for deciding what to change.
A performance score is a summary, and summaries hide the answer. The waterfall view shows every request, its size and when it blocked rendering — which turns “the site is slow” into “this specific font file blocks for 800ms and this image is 3MB”. That is something you can act on.
| Problem | Impact | Effort | Notes |
|---|---|---|---|
| Oversized images | Very high | Low | The most common single cause of a slow WordPress page, and usually the easiest to fix. |
| No page caching | Very high | Low | Removes PHP and database work from most requests entirely. |
| Underpowered or oversubscribed hosting | High | Medium | Sets the floor. No amount of optimisation rescues a starved server. |
| Outdated PHP version | High | Low | Newer PHP versions are substantially faster, and it is usually a control-panel toggle. |
| Too many plugins loading assets | Medium–High | Medium | The cost is rarely the count itself — it is assets loading where they are not needed. |
| Bloated database | Medium | Low | Grows quietly for years; also inflates every backup you take. |
| No CDN | Medium | Low | Matters most when visitors are geographically distant from the server. |
| Render-blocking fonts and CSS | Medium | Medium | Affects perceived speed and layout stability more than total load time. |
Three separate problems usually travel together: images uploaded at camera resolution and scaled down in the browser, images served in older formats, and images below the fold loading immediately. Fix all three — correct dimensions, a modern format such as WebP or AVIF, and lazy loading for anything not initially visible.
The largest single win is almost always the hero image, because it is both the biggest file and the one blocking the largest contentful paint.
Without caching, every visitor triggers PHP execution and a series of database queries to rebuild a page that has not changed. Page caching stores the finished HTML and serves that instead. For a content site this is close to free performance.
Stores and membership sites need more care — cart, checkout and account pages must be excluded, or visitors will see each other's data. Any competent caching plugin handles this by default, but verify rather than assume.
Hosting sets the ceiling. A site on an oversubscribed shared plan will stay slow regardless of what you optimise, because the constraint is CPU you are not being given. Check your PHP version too — successive versions have delivered substantial performance gains, and upgrading is usually a control-panel setting rather than a project.
Post revisions accumulate without limit by default, transients expire but are not always removed, and uninstalled plugins routinely leave their tables and metadata behind. The effect on query time is gradual and the effect on backup size is immediate. Limiting stored revisions is worth doing on any site with heavy editing.
The problem is rarely the number of plugins. It is that a contact form plugin loads its JavaScript on every page including ones with no form, a slider library loads on pages with no slider, and three separate plugins each load their own copy of an icon font. Identify what loads where, and stop assets loading on pages that do not use them.
Removing plugins you no longer use is worth doing anyway — every one is also maintenance and attack surface, as the maintenance guide covers.
Custom fonts block rendering while they download, and swapping them in late causes text to reflow — which visitors experience as jank even when total load time is good. Limit weights to the ones you genuinely use, self-host where practical, and set a sensible font-display behaviour.
Speed is not a project with an end. A site optimised today drifts back over eighteen months as content, images and plugins accumulate — each addition individually reasonable. The only thing that holds the gain is a recurring check.
Performance work across a portfolio is mostly the same handful of fixes repeated, which makes it a poor use of skilled time and a good candidate for a scheduled routine: measure, clean the database, check image weight, report the trend.
It is also work where a mistake is easy to make and easy to miss — an aggressive caching rule that breaks a checkout may not surface for days. Being able to reverse a specific change on a specific site, rather than restoring a backup, is what makes optimising client sites at volume reasonable.
One-click undo covers reversibility, and the agency overview covers running recurring checks across a portfolio.
In most cases: unoptimised images, no page caching, an outdated PHP version, or hosting that cannot supply the resources the site needs. Plugin count matters less than people assume — what matters is whether plugins load their scripts and stylesheets on pages that do not use them. Measure before changing anything, or you will optimise the wrong thing.
There is no correct number. Twenty well-built plugins that load assets only where needed will outperform five that load everything everywhere. The useful question is not how many are installed but how much each one adds to a page load, which a profiling plugin can measure directly.
It fixes one specific and very common cause — rebuilding every page from PHP and database queries on every request — and it usually produces the largest single improvement after images. It does not help with a heavy page that is slow once cached, and it can complicate sites with genuinely dynamic content such as carts and checkouts.
They are a ranking signal, but a modest one next to relevance and content quality. The stronger argument for improving them is conversion: slow pages lose visitors before they see anything, and that cost is immediate rather than algorithmic.
Field data, for decisions. A lab score is a single test on a simulated connection and is useful for comparing before and after. Field data is what your actual visitors experienced on their actual devices and networks, which is what both search engines and your revenue respond to.
Scheduled performance checks and database cleanup across your whole portfolio.
Start free