Speed & Core Web Vitals

Speed work has a bad reputation, and it’s mostly earned. Someone runs a free test, sees a red score, installs three optimisation plugins, and the score goes green — while the site feels exactly the same to the people using it. Sometimes worse, because one of those plugins has quietly broken the images on mobile.

The problem is that the score isn’t the point. What matters is what your actual customers experience on their actual phones, on their actual connections — and Google publishes that data for real visits to your site. It’s a completely different number from the one a test tool gives you, and it’s the one that affects your search rankings.

So the work goes in one direction: measure what real visitors are experiencing, find the specific thing causing the delay, fix that, then measure again to prove it moved. Not a plugin stack. Not a green badge. A checkout that loads before someone gives up on it.

1. Measure what real visitors experience, before touching anything

What it is
Two different kinds of measurement taken up front: what your actual visitors experienced over the last month, and a detailed diagnostic run in controlled conditions.

Why it matters
The free speed tools everyone uses run a single test from a data centre on a fast connection. That’s useful for diagnosis, but it isn’t your customers. Google separately collects timing data from real Chrome users visiting your site — real phones, real networks, real conditions — and that’s what actually feeds into search rankings. The two numbers frequently disagree, and people spend weeks optimising toward the wrong one.

There’s a second trap. Site-wide averages hide the problem. Your homepage might be fast while your product pages are twice as slow, and since the homepage is what everyone tests, nobody notices. The pages that generate revenue are usually the heaviest ones on the site.

How I handle it
I start with the real-visitor data for your site, split by mobile and desktop, and look at it per page type rather than as one blended average. Then I profile the specific pages that matter to your business — your top products, your key landing pages, your checkout — to find what’s actually causing the delay. Often it’s a single thing: one enormous image, one slow third-party script, one database query on one template.

That diagnosis is what the rest of the work is based on. No changes are made before it, because a fix applied to the wrong bottleneck is just risk with no benefit.

2. Images, fonts, and the things blocking your page from appearing

What it is
Cutting down the weight of what loads first, and removing the things that stop your page from displaying while the browser waits on them.

Why it matters
On most WordPress sites the single biggest delay is one image. A photographer sends a 6MB file, it gets uploaded as-is, and every mobile visitor downloads the whole thing to display it at the size of a postcard. Multiply that across a product listing and you’ve built a page that takes ten seconds on a normal phone connection.

Fonts cause a subtler version of the same problem — the browser downloads a custom font before it will show your text, so visitors sit looking at a blank space, or watch the text visibly jump when the real font arrives. That jump is measured too, and counts against you.

Then there’s the queue. Browsers process certain files in order and won’t display anything until they’re done. A single slow script — often a chat widget, a review tool, or an analytics tag added years ago — can hold your entire page hostage while it loads from someone else’s server.

How I handle it
Images get properly sized and served in modern formats, with the right versions delivered to phones versus desktops, and everything below the fold deferred until it’s needed. The one image at the top of the page gets prioritised deliberately, since that’s usually the thing being measured.

Fonts get trimmed to the weights you actually use, loaded so text appears immediately rather than after a wait, and set so it doesn’t shift when the font lands. Third-party scripts get audited — I’ll usually find two or three loading on every page that nobody has used in a year — and the ones you keep get moved out of the critical path so they load without holding up your content.

3. Only loading what each page actually needs

What it is
Making sure the code required for one part of your site stops loading on every other part of it.

Why it matters
This is the most common source of hidden weight on a WordPress site, and it’s almost never visible from the outside. Plugins load their code everywhere by default. Install a booking form for one page and its scripts and styles now load on every product page, every blog post, and your checkout — on a page where the form doesn’t even appear.

It compounds. A site running twenty plugins, each loading a little bit of code site-wide, ends up with a homepage carrying the baggage of features it doesn’t use. Page builders do this too, shipping styles for every layout element in case one gets used. Your customers download all of it, every time.

How I handle it
I work out what each type of page genuinely needs and restrict everything else to where it belongs. The booking script loads on the booking page only. The gallery styles load where there’s a gallery. Your checkout loads what checkout needs and nothing more.

This is done with hooks and conditions in a small plugin rather than by editing your theme, so it survives updates and can be removed cleanly if you ever move on. It’s unglamorous work and it usually produces the largest single improvement, because you’re not compressing weight — you’re removing it entirely.

4. Caching and database work — where stores actually slow down

What it is
Storing the results of repeated work so your server doesn’t rebuild the same thing for every visitor, and fixing the slow database lookups underneath.

Why it matters
Every time someone loads a page, your server assembles it from scratch — running code, querying the database, building the HTML. Caching means doing that once and serving the saved copy to everyone else, which is dramatically faster.

The complication is stores. Caching works beautifully on a blog and causes real damage on a badly configured WooCommerce site: cached cart contents showing one customer another’s items, prices frozen after a change, the checkout serving a stale page. This is why plenty of store owners have caching switched off entirely — they got burned once and never went back.

Underneath caching sits a separate problem that caching can’t hide. Some pages are slow because of what happens in the database — a plugin running an expensive lookup on every page load, a product filter scanning tens of thousands of rows, an options table bloated with years of leftover data from plugins long since deleted. Logged-in customers and checkout pages can’t be fully cached, so they feel this directly.

How I handle it
Caching gets configured to know the difference between a page anyone can share and a page personal to one customer. Cart, checkout, and account pages are excluded correctly; everything else is cached properly and cleared automatically when you update a product or publish a post.

Where it helps, I add an object cache so repeated database lookups are held in memory rather than re-run. Then the actual slow queries get found and fixed — adding a missing index, rewriting an expensive lookup, cleaning out accumulated junk. That’s the part that speeds up the pages caching can’t touch, which on a store is the part where the money is.

5. Proof it worked, in the numbers that matter

What it is
A clear before-and-after showing what changed, measured on real visitor data rather than a test score.

Why it matters
Speed work is easy to fake. Anyone can move a test-tool score by fifteen points without a single customer noticing a difference, because those scores can be influenced by changes that don’t affect the actual experience of loading the page.

Real-visitor data is harder to game and slower to update — it reflects a rolling window of actual visits, so improvements appear over a few weeks rather than instantly. That lag is worth waiting for, because it’s the number tied to your search rankings and it’s the only one that tells you something genuinely changed for the people buying from you.

How I handle it
You get a straightforward report: the same measurements taken before and after, for the same key pages, split by mobile and desktop. Alongside them, a plain-English note on what was changed and which change produced which improvement.

Anything that didn’t move gets reported too, along with why — sometimes the remaining bottleneck is your hosting, or a third-party script you have business reasons to keep, and you should know that rather than be told everything was a success. Since real-visitor data updates gradually, I check back once it’s caught up and confirm the improvement held.