Optimising WordPress speed: the advanced techniques

Introduction: this article starts where the others stop

Performance guides all say the same thing: enable a cache, compress your images, use a delivery network. That is correct, it is necessary, and once it is done most sites are still slow.

This article assumes those three are in place. It covers what remains — and what remains is almost never in the page rendering:

total time = server time + critical path + what third parties add
                  ↑            ↑                  ↑
           queries, PHP   blocking CSS/JS   scripts you did
           autoload, cron                   not write

The guides handle the middle column. The other two are where the seconds live. For the basics and Core Web Vitals measurement, start with optimising Core Web Vitals.

1. Server time — what caching hides instead of fixing

A page cache makes the problem invisible to anonymous visitors and entirely intact for everyone else: logged-in user, non-empty cart, account page, internal search, form. On a store, those are exactly the pages that pay.

The options table and autoload. WordPress loads, on every request, every option marked as autoloaded. Uninstalled plugins leave entries there, sometimes large, that keep being read forever. It is the first place to look and almost nobody does: measure the total autoload weight, then what makes it up.

Unindexed queries. A query scanning a whole table is painless at a thousand rows and fatal at a hundred thousand. The symptom misleads: the site slows gradually, it gets blamed on hosting, and the cause is a query that never changed.

Scheduled tasks. WordPress triggers them on a page load — a visitor pays for the execution. A heavy task on a low-traffic site produces the worst case: the hour's only visitor waits for the backup. Moving to real server scheduling is one of the highest-return interventions on this list.

The number of plugins. It is not a myth: each adds option reads, scripts and hooks. Going from thirty to fifteen shows on server time with no other intervention — see auditing your plugins in 5 steps.

2. The critical path — the one rule that matters

Anything blocking the first screen is time the visitor watches. The classic techniques (minify, defer) plateau quickly. What genuinely unblocks:

• load what the first screen needs, defer the rest. A single CSS file containing every page's styles makes the home page pay for the checkout's styling;
• do not load scripts where they are not used. A contact form loading its library on all 400 pages of the site is extremely common, and the fix is conditional: load it on the page that uses it;
• reserve space for elements arriving later. A banner, an image, a font that slots in shifts the page — the visitor loses their line, and the visual stability metric collapses. Reserving the height costs one style rule;
• preload the first-screen font and image, but only those. Preloading everything is prioritising nothing.

⚠ The trap: optimising what the measurement tool displays rather than what the visitor experiences. A score obtained by deferring a script that becomes necessary three seconds later improved nothing — it moved the wait outside the measurement.

3. Third parties — the heaviest item and the least examined

On many sites, half the load time comes from code nobody in the company wrote: analytics, consent banner, chat, advertising pixels, remote fonts, maps.

Three rules, by return:

1. Count before arguing. List each third-party script and what it adds in weight and time. The result surprises, and it makes the conversation possible with whoever asked for them.
2. A third party must earn its place. A pixel installed for a campaign that ended eight months ago costs every day. It is the fastest and most profitable cleanup in this whole article.
3. Self-host what can be. Fonts especially: serving them from your domain removes a name lookup, a connection and a security negotiation — and settles a personal-data question along the way.

The consent banner is the trickiest case, because it is mandatory and it arrives early. The solution is not to remove it: it is to insert it without letting it push the page. Covered in our approach to consent and cookies.

4. Images — beyond compression

Compression is a given. What remains:

• the dimensions served. A 2400 px image displayed in a 600 px frame transfers four times too many bytes. It is the most common waste after third parties;
• the format, chosen by content rather than by principle;
• lazy loading, except for the first-screen image. Deferring that one directly degrades the main metric — the classic mistake of the checkbox ticked everywhere;
• alt text, which does not serve speed but is worth handling while you have the subject open. See our comparison against Smush.

5. Measuring — three mistakes that make you work for nothing

Measuring in the lab only. A synthetic test from a nearby data centre on a perfect connection describes nobody. Field data describes your visitors.

Looking at the average. The average hides the tail of the distribution, and the abandonments live in the tail. Look at the high percentiles: those are your customers on a phone, on the move.

Measuring one page. The home page is rarely representative. Measure a content page, a product page and the checkout — three different profiles, three different bottlenecks.

And the one question that settles all of it: did the conversion rate move? A speed gain visible on no business metric is an engineer's gain. On a store, the full reasoning is in optimising the conversion funnel.

6. The advanced protocol, on one page

• Measure first — field and lab, on three page types, and write the numbers down
• Autoload weight recorded, orphan entries from uninstalled plugins removed
• Slow queries identified on the slowest page, not on the home page
• Scheduled tasks moved to real server scheduling
• Third-party inventory, with, for each: who asked for it, what for, still useful?
• Fonts self-hosted, preloaded, and those only
• Conditional scripts: loaded on the pages that use them
• Space reserved for any element that slots in after rendering
• Re-measure, compare with the recorded numbers, and keep an untouched control page

Conclusion

Once caching and compression are in place, speed is no longer won by configuring: it is won by removing. Options loaded for nothing, scripts serving one page in four hundred, third parties installed for a finished campaign, plugins kept just in case.

It is less spectacular than a new caching module, and it is what produces the seconds. Advanced performance is subtraction work, and that is why it is rarely done: there is nothing to install.

The test that tells you where you stand: open the slowest page on your site, not your home page. That is the one your unhappy customers saw.

Next: optimising Core Web Vitals, WooCommerce Core Web Vitals and our comparison against WP Rocket. On the tooling side: page performance and image optimisation — premium versions with a full refund within 14 days.