A client came to us with a 6.2 second LCP, a page-builder theme, forty-one active plugins, and a marketing team who would have resigned if we removed the features they had spent two years asking for. Six weeks later the same site loaded its hero in 1.8 seconds with every one of those features still switched on.
Nothing below is clever. It is just done in the right order, which is the part most speed work gets wrong — people reach for the cache plugin first because it is the cheapest thing to try, and then spend three months confused about why the number will not move.
Work in this order
Caching hides slow code. It does not fix it, and it does nothing for the logged-in editor, the cart page, or the first visitor after every deploy. So the order is: make the page fast when nothing is cached, then cache it.
1. Kill the queries first
Install Query Monitor, load your slowest template as a logged-out user, and read the number of queries. Anything over about eighty on a content page means something is looping where it should be joining.
On this project the homepage ran 614 queries. Four hundred of them came from one “related products” block that fetched every product, then filtered in PHP. Rewriting it as a single meta query with a transient took an afternoon and removed 2.1 seconds.
The three usual culprits
Post loops that call get_post_meta inside the loop without priming the cache. Menu walkers that resolve every URL individually. And any plugin that stores serialised arrays in an autoloaded option — check wp_options for autoload rows over 100KB before you blame the theme.
2. Set an asset budget
Agree a number before you start deleting things: 120KB of CSS and 180KB of JavaScript, compressed, is a comfortable target for a marketing site with real design on it. Write it into the ticket so it is a requirement rather than an aspiration.
Then dequeue per template. Most plugins enqueue their assets on every page because that is the safe default; a contact-form script has no business loading on a product listing. Conditional dequeuing on this site removed 340KB from the homepage without touching a single feature.
If you cannot say what your CSS budget is, you do not have one — and the site will grow until it is slow again.
3. Object cache, then page cache
Redis object caching is the highest-leverage single change on any WordPress site with real content behind it, because it helps logged-in users and dynamic pages too. Page caching only helps the anonymous visitor hitting a page someone already warmed.
Turn the object cache on, re-measure, and only then add page caching. If page caching is masking a 3-second uncached render you will discover it the hard way, on the morning of a campaign, when the cache is cold and the traffic is not.
4. The image pipeline
By this point the remaining LCP is almost always an image. Three rules: the hero image is never lazy-loaded, every image ships as AVIF with a WebP fallback, and the srcset sizes attribute reflects the real layout rather than the WordPress default of 100vw.
That last one is worth more than people expect. A hero declared at 100vw on a 1440px screen fetches a 1440px-wide file for a container that is 720px wide — four times the bytes for no visible gain.
Holding the number
Speed work decays. A plugin update re-enqueues its stylesheet globally, someone uploads a 4MB PNG, a new block ships with a font nobody approved. Without a check in the pipeline you are back at 4 seconds within a quarter.
We add Lighthouse CI to the deploy with the asset budget as a hard failure. If a pull request pushes CSS over the agreed number, it does not merge. That single check has kept more sites fast than every optimisation above put together.
If any of this sounds like your site, the audit is the cheap way to find out which of the four steps is costing you the most. We do those, and the findings come with the fixes.