WordPress speed optimization, the four causes in the order they cost you and what a paid speed service has to prove

A slow WordPress site is almost always slow for one of four reasons, and they are not equally expensive to fix. In rough order of how much damage they do per hour of work to repair them: the hosting and the database behind it, the theme and its page builder, unoptimised media, and plugin overhead. Most people start at the fourth and deactivate things, which is the cheapest thing to try and the least likely to be the cause. Google Keyword Planner shows 170 searches a month in the United States for this group of phrasings, read on 31 October 2026 against the United States geo target and taken as the group maximum rather than the sum.

The numbers you are optimising towards

Fix a target before you touch anything, or you will chase a score. Google's own guidance on web.dev, read on 31 October 2026, gives three metrics and three thresholds. Largest Contentful Paint should land "within 2.5 seconds" of when the page starts loading. Interaction to Next Paint should be "200 milliseconds" or less. Cumulative Layout Shift should be "0.1" or less, and it is unitless. The same article says to measure at the "75th percentile" of page loads, split across mobile and desktop.

That percentile instruction is the part worth internalising. You are not trying to make one test fast. You are trying to make three quarters of real loads pass, which is why a single run in a speed tool can be comfortably green while your field data fails. Our note on why five speed test tools give five answers for one page works through which number to trust.

One, the hosting and the database

Shared hosting at the bottom of the market gives you a slow time to first byte, and no amount of front-end work recovers a server that takes 900 milliseconds to start answering. Measure it before anything else. If time to first byte is consistently above about 600 milliseconds on an uncached page, you have a hosting problem, and moving host is a one-day job with a bigger effect than a week of optimisation.

Underneath hosting sits the database, and on an older WordPress install the table that quietly grows is wp_options with autoloaded rows left behind by plugins that were removed years ago. Post revisions, expired transients and orphaned metadata add to it. This is unglamorous, reversible with a backup, and frequently worth 200 milliseconds on every single uncached request.

Two, the theme and the page builder

This is the cause people least want to hear, because it means the site they just paid for is the problem. A heavy multipurpose theme loads a large stylesheet and several script bundles on every page whether the page uses them or not, and a visual builder adds a markup layer and often a second set of assets on top. The result is a page whose critical path is long before your content has done anything.

Two honest tests. Load a near-empty page on the same theme and measure it: if a page with one paragraph is slow, the theme is the ceiling. Then switch temporarily to a default theme on a staging copy and measure the same page. The gap between those two numbers is the price of the theme, and it tells you whether optimisation can help or whether you are rebuilding the front end.

Three, media

Images are the usual Largest Contentful Paint element on a WordPress page, so they are the metric's direct cause. Three changes do most of the work. Serve modern formats so the file is smaller for the same visual quality. Serve the right size, which means letting WordPress responsive images do their job rather than dropping a 3,000 pixel wide photograph into a 700 pixel column. And set explicit width and height attributes on every image, because that is what stops the layout shifting as pictures arrive, which is the Cumulative Layout Shift half of the problem.

Lazy loading helps everything below the fold and hurts the one image above it. Exclude the hero image from lazy loading. A site that lazy loads its own Largest Contentful Paint element has made the metric worse with a performance feature, and it is one of the most common misconfigurations in the category.

Four, plugins, measured rather than counted

A plugin count tells you nothing. Thirty light plugins can be faster than four heavy ones. What matters is which plugins load assets and run queries on pages that do not need them, and the honest method is to measure rather than guess: profile the slowest page, read which plugin is responsible for the largest share of load time and the most queries, and deal with the top two.

The usual offenders are the ones that run everywhere by design. Related-posts and popular-posts widgets that query on every view. Sliders. Social sharing scripts. Anything that calls an external service during the page render, which turns somebody else's uptime into your page speed. Conditional loading, so an asset only loads on the pages that use it, fixes more than deactivation does and keeps the function.

Caching, in the right order

Caching is the amplifier, not the cure. Put it on last, so you are caching a page that is already lean rather than hiding a page that is not. Page caching serves a stored HTML response and removes PHP and the database from the path for anonymous visitors. Object caching helps logged-in and dynamic paths. A content delivery network moves static assets closer to the visitor. Each is worth having, and none of them improves the page an editor sees when they are logged in, which is why your team may still think the site is slow after a good optimisation pass.

What to require from a paid WordPress speed service

Suppliers in this category sell an outcome that is easy to fake with a single cached test. Require four things in the deliverable. Field data before and after, from real users at the 75th percentile, not a lab score. A named list of what was changed, so the work is reversible and legible to your next developer. The result measured on a logged-out page and a logged-in page separately. And a plain statement of which of the four causes above was the actual constraint, because a supplier who cannot name it has optimised around the problem rather than at it.

Be careful about one shortcut in particular. Some services deliver a fast score by deferring or removing JavaScript the site needs, which looks excellent in a test and breaks a form, a basket or a booking widget in a way nobody notices for a fortnight. Ask what was deferred and test the three things on your site that make money.

Questions about WordPress speed optimization

Will a faster site rank higher

Speed is one input among many, and the clearest benefit is behavioural rather than algorithmic: fewer people leave before the page draws. Treat speed work as removing a tax on everything else you publish rather than as a ranking tactic.

Is a caching plugin enough on its own

For a small site on decent hosting it often gets you inside the thresholds. It does nothing for logged-in users, nothing for the first uncached request and nothing for a theme that ships 600 kilobytes of CSS, so read your field data afterwards rather than assuming.

How much should this cost

Prices in this category are quoted per site and vary too widely to be worth a figure without a source, and we are not quoting one we did not read today. What you can control is the scope: ask for the four deliverables above, and compare quotes on those rather than on a promised score.

Should I move off WordPress to go faster

Rarely, and almost never for speed alone. A clean WordPress install on good hosting with a light theme passes the thresholds comfortably. If the real reason is that the editing experience has become unworkable, say that instead, because it leads to a different and better decision.

Why does my score change every time I test

Because a lab test measures one load on one network from one place, and your field data measures thousands. Make decisions from the 75th percentile of field data and use lab tests only to check whether a specific change did what you intended.

The fetch that happens without a browser

There is one reader of your WordPress site that never waits for your JavaScript. The fetchers behind assistant answers take the HTML your server returns and keep the text in it, so anything your theme renders only after a script runs is invisible to them however fast the page feels. That makes server-rendered content a visibility question as well as a speed one. AI Knows Us reads your pages the way those systems do and tells you which of them get used in answers, which is the half of the performance picture no speed tool reports.