Most slow WordPress sites are slow for the same three reasons: the theme, the plugins and the images. Hosting matters too, but it is rarely the first bottleneck, and moving host before fixing those three usually moves the problem rather than solving it.
Here are the three real bottlenecks, what to do about each, and how to measure the result.
1. The theme
Many WordPress themes of the last decade were built for the page-builder ecosystem: Elementor, Divi, WPBakery, Beaver Builder. They work by shipping a CSS framework that supports every block the builder could render, a JavaScript runtime that interprets the builder's output, and a rendering pipeline that sits beside the WordPress block editor.
The result is a large amount of CSS and JavaScript shipped on every page, before any of your actual content. On a mid-range Android phone over a mobile connection, that is what makes the first view slow. Lighthouse flags it, and your visitors feel it.
The fix is structural. Replace the theme with a block-native theme: one that uses the block editor, custom fields for structured content, and no page-builder runtime. Measure the CSS and JavaScript the browser downloads before and after, in the Network panel of your browser's developer tools, so you know what the change was worth on your site.
A good shortlist of block-native starting points for 2026: GeneratePress, Blocksy, or a custom block theme started from the official create-block-theme plugin.
2. The plugins
Each active plugin can load its own CSS and JavaScript on every page where its features are enabled, and most of those features are not used on most pages.
Audit:
- List every active plugin.
- For each one, write down what feature it provides and how often that feature actually runs.
- Look for overlap: two plugins doing SEO, security or caching is common and never needed. Pick one of each, remove the rest.
- For plugins that only need their feature on a handful of pages, use a plugin like Asset CleanUp or Perfmatters to stop their files loading everywhere else.
Measure the page weight before and after the audit, the same way as for the theme.
3. The images
WordPress accepts WebP uploads since version 5.8 and AVIF since 6.5, but an older media library is often full of large JPEGs, and the front end can still load them at full size into small containers.
Fix:
- Convert the existing media library to WebP or AVIF. Plugins such as ShortPixel or Smush do it once for the library and then automatically for new uploads.
- Lazy-load every image except the LCP element (usually the hero image at the top of the page).
- For the LCP image, set
fetchpriority="high"and serve it at the correct size for the viewport.
This is often the cheapest improvement to LCP on mobile, and the easiest to see in a before and after test.
What about caching?
Caching matters. It is just not the first lever to pull.
A caching plugin like WP Rocket or LiteSpeed Cache, configured correctly, makes a fast theme faster. On a slow theme it hides some of the cost at best, and a bad configuration can make things worse: stale assets, broken cart pages, logged-in users served someone else's view.
Order of operations:
- Theme audit and replacement.
- Plugin audit and pruning.
- Image optimisation.
- Then turn on caching.
Reverse this order and you are caching the output of a slow site, which is just a slow site that is slow in fewer places.
Hosting
Hosting matters most when the database is heavy: a very large number of posts or products, many logged-in users at once, heavy WooCommerce traffic. For a typical brand site, a reputable host with a current PHP version and OPcache enabled is rarely the bottleneck.
What does matter regardless of host:
- HTTP/2 or HTTP/3 enabled.
- Brotli or gzip compression on text responses.
- A CDN in front of static assets. A free CDN tier is enough for most brand sites; stores and high-traffic publications may need a paid one.
- XML-RPC disabled and login attempts limited. Not a speed fix but a stability one: brute-force traffic on
/xmlrpc.phpcan take a small site down under load.
Measuring honestly
Measure Core Web Vitals on the real production site, on a mid-range Android phone, on a mobile connection. Not on a desktop laptop on home WiFi. The gap between desktop and mobile results is the whole performance story on many WordPress sites.
The thresholds to meet, at the 75th percentile of real visits (web.dev):
- LCP: 2.5 seconds or less. Aim lower if you can.
- INP: 200 milliseconds or less.
- CLS: 0.1 or less.
A Lighthouse score is a useful lab check, but the field data in PageSpeed Insights and Search Console is what the thresholds are defined on.
What this looks like with us
We build against the budget above rather than tuning for it afterwards. The whole process is written out in how we build.
If you want the site built rather than tuned, a website is one of the builds in Startup, the one package we sell, with the price and the timeline published.