Why your WordPress site is slow on mobile, and why another caching plugin won’t help

Short version: your WordPress site is slow on phones because the phone is asked to download and run far more than it needs before it can show the first screen. A laptop hides that. A mid-range Android on a 4G connection does not. The usual suspects, in the order they cost time, are one oversized hero image, the theme or builder’s CSS, scripts that load in the head, third-party tags, and only then the server. Caching touches the last one. That is why the caching plugin you installed last month changed the desktop score and nothing else.

First, measure where Google measures

PageSpeed Insights shows two sets of numbers and people usually read the wrong one. The lab score at the bottom is one simulated load. The field data at the top comes from real Chrome users over the last 28 days, split by phone and desktop. That is the number Google ranks on, and it is the number your visitors feel. If the field data says LCP 4.1 s on mobile, the site is slow on mobile, whatever the lab score says.

Open the Core Web Vitals report in Search Console too. It groups URLs, so you see whether the problem is the homepage, every blog post, or every page that uses one template. That tells you where to look before you open a single file.

Where the seconds go

Here is a breakdown from a builder site I audited this year, measured on the homepage on a mid-range Android over 4G. Mobile LCP was 4.1 seconds. Your numbers will differ, the shape rarely does.

The server and its cache were the smallest slice, and they were the only slice a caching plugin can touch. The biggest was one image: 1.9 MB, uploaded straight from the designer’s export, shown at 390 pixels wide, and lazy-loaded, which told the browser to fetch it last. Three settings on one file were worth more than every plugin on the site.

Why the caching plugin didn’t help

A page cache saves a ready-made copy of each page so the server doesn’t rebuild it from PHP and the database on every visit. That shortens the time to the first byte of HTML. Useful, but on most sites it was never the bottleneck. If the first byte arrives in 0.5 seconds and the page then needs four more seconds to show the hero, a perfect cache removes part of that half second and leaves the four alone.

A cache makes the server fast. It doesn’t make the page light.

Optimisation plugins that combine, minify and defer files are a different story. They help a little and break things often, because they can’t know which script the slider needs and which one nothing needs. The gains come from removing work, not from reshuffling it.

The fix order that works

I fix in the order the browser waits, biggest slice first, because each step changes what the next one is worth. Doing scripts before the image is a day of work that moves the number by a tenth of a second.

1. The LCP imageRight size for the screen, AVIF or WebP, preloaded, and never lazy-loaded above the fold. This alone took the site above from 4.1 to 2.6 seconds.
2. CSSUnused theme and builder CSS removed per template. The part needed for the first screen inlined, the rest loaded after.
3. ScriptsDeferred, or removed when a widget isn’t worth its weight. A slider library for a hero that has one slide is a common one.
4. Third-party tagsChat, heatmaps and ad pixels delayed until the first interaction, or loaded only after consent, which they should be anyway.
5. Server and cacheOne page cache configured properly, a CDN in front of static files, and a host that answers in under 0.8 s. Last, because by now it is the biggest slice left.

<!-- Preload the LCP image. Never lazy-load it. -->
<link rel="preload" as="image"
      href="/hero-1200.avif"
      imagesrcset="/hero-800.avif 800w, /hero-1200.avif 1200w"
      fetchpriority="high">

On that site, the order took mobile LCP from 4.1 to 1.9 seconds without changing a pixel of the design. The caching plugin stayed. Two of the three others were removed.

Before you install anything else

Run through this list. On most sites I see, two or three of these fail, and they explain the score better than anything a plugin page promises.

How to know it worked

PageSpeed Insights runs one lab test from one location. Fine for debugging, not for judging. I measure twice: a lab test on handover day to confirm the fix landed, and the field data four weeks later, because that is how long Google needs to collect a new 28-day window. If the Search Console report moves from “poor” to “good” for the mobile group, the work is done. If it doesn’t, something else is loading that the lab didn’t see, usually a tag someone added in the meantime.

If you want the numbers for your own site before deciding anything, the free scan on the home page measures them on a real phone profile in a few minutes.