Why is my WordPress site slow on mobile?

Google’s test simulates a mid-range Android phone on a slow mobile connection, because that is what most of the world browses on. In South Africa most of your visitors are on phones, on data they pay for by the gigabyte, often a long way from wherever your server sits. Your office has fibre and a fast machine, so the site looks fine to you. It is the only place it does.

The single most common cause. A 4,000-pixel photo from a camera, uploaded straight into the hero, displayed at 400 pixels wide on a phone. The phone downloads all four megabytes anyway. Multiply by a gallery.

Plugin fixable? Mostly. Modern WordPress serves smaller versions if the theme asks for them properly, and an optimisation plugin will compress what’s there. The theme asking properly is the part that often isn’t true.

Themes are built to look good on a demo page that sells the theme. They ship every feature anyone might want, and every visitor downloads the code for all of them, whether your site uses them or not. A popular multipurpose theme can load a megabyte of scripts before your first word appears.

Plugin fixable? No. You can trim around the edges, but the theme is the floor. This is where most sites we audit are stuck.

Each plugin that touches the front of the site adds its own scripts and styles, usually to every page, usually loaded before anything paints. Twenty plugins is normal on a site nobody has pruned. A slider plugin alone can cost more than the rest of the page.

Plugin fixable? Partly, by removing plugins. An audit of what each one actually does is a good afternoon’s work and usually retires a third of them.

Five weights of a Google font, plus an icon font for six icons, each a separate download the text waits for. Fonts are invisible on the bill and very visible on the phone, where the headline sits blank until they arrive.

Plugin fixable? Sometimes. Fewer fonts and self-hosting them is a theme decision more than a plugin one.

This is the structural one. A traditional WordPress page is assembled on demand: a request arrives, PHP starts, plugins load, the database answers, and only then does HTML go back. A caching plugin puts a lid on that, but it is a lid on a pot that keeps reheating. Every plugin update, every logged-in editor, every uncached product page starts the process again.

Plugin fixable? A good cache helps a lot, and we recommend one on every traditional site. It does not change the direction of travel. The alternative is to build the pages once, before anyone arrives, and serve them as finished files from a location near the visitor. That is what we mean by headless, and it is why our own builds start in the nineties on the same test.

A server in Europe adds a fifth of a second to every request from Durban before it has done anything. Shared hosting adds more when a neighbour is busy. Neither shows up on your office fibre.

Plugin fixable? No, but a content network in front of the site, or a static frontend on one, removes most of the distance.

The chat widget from a trial you never cancelled. Two analytics tags. A Facebook pixel from a campaign in 2021. Each one is a download and a few hundred milliseconds of the phone’s attention.

Plugin fixable? Yes, by deleting them. Look in the theme’s header settings and in any tag manager you have.

• Run the test at pagespeed.web.dev on your phone address and keep the number.
• Resize the images, prune the plugins, delete the dead scripts. Expect to gain ten to twenty points.
• If the number is still under fifty, the theme is the floor. At that point a rebuild on an architecture that is fast by default costs less over three years than fighting the theme every month.

We publish our own numbers, and we will run the test on your site and tell you which of the seven it is, whether or not you hire us.