Mobile speed on WordPress is four problems, not forty.

First, check you are looking at the right number

PageSpeed Insights shows you two things and people almost always react to the wrong one. The score at the top is a lab test: one simulated load, on a throttled connection, from a datacentre. It is a diagnostic. It is not what Google uses.

What Google uses is the field data above it, gathered from real Chrome users on real phones on real networks over 28 days. Those two can disagree sharply and both be correct, because they measure different things. A site can score 46 in the lab and pass every field metric, and chasing the lab number in that situation is work with no beneficiary.

Why mobile is slower, and it is not the phone

A modern phone is a fast computer. What differs is the network it is on, which is higher latency and less predictable, and the fact that it has a smaller thermal and power budget for parsing and executing JavaScript.

That distinction points straight at the cause. Mobile punishes payload weight and main-thread work far harder than desktop does, and it punishes them non-linearly. Shipping the same page to both and finding mobile slow is not a mobile problem to solve with a mobile-specific fix. It is the desktop page being heavier than you realised, with the phone honest enough to show it.

Cause one: the images. It is nearly always the images

If you fix one thing, fix this. The usual pattern on a WordPress site is a hero image uploaded at whatever dimensions the camera produced, served at full size to a 390px viewport, in JPEG, with no width and height attributes so the layout jumps when it lands.

Three fixes, in order of payback. Serve modern formats, which for most libraries means AVIF with a WebP fallback and is typically a 40 to 70 percent reduction on the same visual quality. Serve correctly sized variants through srcset so a phone is not downloading the desktop rendition. And set explicit dimensions on every image so nothing reflows, which is a layout shift fix rather than a speed one but comes from the same neglect.

One further thing that is specifically a mobile issue: lazy-loading the hero. Plugins that apply loading="lazy" indiscriminately will lazy-load the largest element above the fold, which delays the exact paint you are being measured on. The image that is visible on load should be eager and, ideally, preloaded. Everything below the fold should be lazy.

Cause two: the theme, and what it lets you build

This is the uncomfortable one, because it is the expensive fix. A page builder that ships its own grid framework, icon set, animation library and three fonts before your content exists has set a floor on your performance that no plugin will get you under.

The tell is simple. Load a nearly empty page on the site, a thin privacy or contact page with almost no content, and measure that. Whatever it weighs is your floor: it is what every page on the site pays before it says anything. If an empty page is 1.4MB, no amount of image work on the homepage will save you.

Cause three: plugin sprawl and the optimisation plugins themselves

Every active plugin can enqueue scripts and styles on every page, whether or not the page uses it. A contact form plugin loading its bundle on all 400 pages because one page has a form is the standard case, and it is usually fixable by dequeuing conditionally rather than by removing the plugin.

The sharper version of this problem is optimisation plugins stacked on top of each other. Two plugins both minifying and combining CSS, one deferring a script the other inlines, a caching plugin caching the output of another caching plugin. The symptom is a site that is faster with all of them deactivated, and it is common enough to be worth testing deliberately before adding a fifth.

Pick one caching plugin. Pick one image plugin. Turn off every optimisation toggle, then enable them one at a time and measure after each, which is slower to do and the only way to know which one earned its place.

Cause four: no real caching, or caching that lies

Page caching is the highest-leverage server-side fix, because it turns a database-driven page assembly into serving a file. On managed WordPress hosting it is often already on at the server level, which is one reason adding a caching plugin sometimes changes nothing.

The failure that costs more than slowness is stale content. A cache that never invalidates correctly serves old prices, old availability and old opening hours, and it does it invisibly. Closing a systemic invalidation failure with four independent root causes is written up in full, and the short version is that the subtle gaps are always the paths nobody modelled: deletion hooks, alternative URL forms, and curated pages that query content rather than being archives of it.

What this buys you

Be clear about the return. Speed is a real ranking signal and a small one: Core Web Vitals are a tiebreaker that decides close calls between comparable pages, not a lever that lifts a weak page. If your pages are not indexed or not competitive, this work will not fix that and the disappointment will be blamed on the wrong thing.

Do it for the person waiting on a train with two bars of signal. That is a good enough reason on its own, the conversion effect is more reliable than the ranking effect, and it does not depend on an algorithm keeping its current weighting.