WordPress Speed Optimization

What Core Web Vitals actually measure

Three numbers, each describing a different way a page can feel bad. Knowing which one you're failing tells you where the work is — they have almost nothing in common under the hood.

Where WordPress time actually goes

In rough order of how often it's the real problem on sites I'm handed:

1. Time to first byte — the server hasn't even answered yet. If TTFB is 800 ms, no amount of front-end work saves you; you've lost a third of your LCP budget before a single byte of HTML arrives. Causes: no object cache, slow hosting, PHP version two releases behind, or a plugin making external API calls during page generation.
2. The database is doing far too much work. The usual offenders are a bloated wp_options table with megabytes of autoloaded rows, post meta queries with no index, and expired transients nobody ever cleans up. This is invisible to every front-end tool and is routinely the single biggest win.
3. Every plugin loads its assets on every page. A contact form plugin loading its CSS and JS on your homepage, a slider library on pages with no slider. Conditional dequeuing typically removes a third of the payload without changing anything visible.
4. Images are the biggest thing on the page and nobody resized them. A 3000 px JPEG displayed at 800 px, no WebP or AVIF, no width/height attributes (which also wrecks CLS), and lazy-loading applied to the hero image — which makes LCP worse, not better.
5. Fonts block rendering and then shift the layout. Four weights of two families, self-hosted without font-display: swap, or pulled from a third-party origin that needs its own DNS lookup and TLS handshake.
6. Third-party scripts you forgot about. Tag manager, chat widget, two analytics tools, a heatmap, a cookie banner. These often account for most of your INP, and no amount of optimizing your code offsets them.

The process

1. Measure first, on your real pages. Homepage, a category or archive, a product or post, and checkout if you have one. Lab data plus field data plus server-side timing — you can't fix what you haven't attributed.
2. Find the causes and rank them by seconds saved per hour of work. You get this list before any work starts, so you can see exactly what you're paying for and stop wherever the returns flatten.
3. Fix on staging, in order. Server and database first, then assets, then the front end. Nothing touches production untested.
4. Verify functionality, not just speed. Checkout, forms, logged-in views, mobile. A fast broken site is worse than a slow working one.
5. Deploy, then re-measure the same tests. Same pages, same tools, so the comparison is honest.
6. Hand over a written report. What was slow, what changed, the before/after numbers, and what will slowly undo it if left alone.

Why I don't chase a 100 score

A perfect Lighthouse score is achievable on almost any site if you're willing to break things — defer all JavaScript, strip the tracking your marketing team needs, inline everything. I've seen sites with a 100 score and a checkout that no longer works on Safari.

What matters is the moment a real visitor can see and use your page, on the device and connection they actually have. Sometimes that means a lower Lighthouse number and a much better site. I optimise for the field data and for revenue, and I'll tell you plainly when a change would trade real functionality for a prettier number.

WooCommerce is a different problem

Store pages can't be cached the way a blog post can — carts, sessions, and logged-in customers are inherently dynamic. So the work moves: object caching with Redis so repeated queries stop hitting MySQL, careful cache exclusion rules that don't accidentally serve one customer another's cart, cart fragment handling, indexing the meta tables Woo hammers, and taming the admin-side queries that make order management crawl once you pass a few thousand orders.

If you run a store, say so in the form — it changes the audit substantially.

FAQ

How much faster will my site get?

Most sites I take on carry two to five seconds of avoidable delay, and the realistic target is sub-second LCP on a normal connection. I quote a specific target after the audit rather than promising a number blind — a bloated page-builder site and a lean custom theme have very different ceilings.

Do you just install a caching plugin?

No. Caching hides slowness from repeat visitors; it doesn't make the site fast. The work is finding what's genuinely slow and fixing that. Caching goes on top once the underlying page is fast.

Will optimization break my site?

Not when it's done on staging first, which is how I work. Aggressive optimization plugins break sites routinely because they defer and combine assets blindly. Every change is verified — including checkout and forms — before it reaches production.

Does speed actually affect SEO and sales?

Core Web Vitals are a confirmed ranking signal, though a modest one next to relevance and links. The bigger effect is commercial: slow pages lose visitors before they see your offer, which shows up in bounce rate and checkout abandonment far more sharply than in rankings.

How do I know it worked?

Before-and-after numbers from the same tests on the same pages — Lighthouse and WebPageTest for lab data, plus CrUX field data where your traffic is high enough to populate it. Field data is what Google uses, so that's the number that counts.

My host says the site is fine. Who's right?

Often both. Hosts measure server response under ideal conditions; your visitors experience the whole page on a mid-range phone. A server can respond in 200 ms while the page still takes six seconds to become usable.