Search "speed up WordPress" and you get the same twenty-item checklist every time, usually ending in "install a caching plugin". That advice isn't wrong, it's just unordered — and order is everything, because two of these fixes do more than the other six combined.
Core Web Vitals measures three things. LCP (Largest Contentful Paint) is how long until the biggest visible element finishes loading. INP (Interaction to Next Paint) is how quickly the page responds when someone taps or clicks. CLS (Cumulative Layout Shift) is how much the layout jumps around while loading. Here they are in the order worth fixing them.
1. Fix your hero image first (LCP)
On the overwhelming majority of WordPress sites, the Largest Contentful Paint element is the first image on the page — a hero banner or featured image. If that one file is a 1.5 MB PNG, nothing else you do matters much.
Three changes, all cheap: serve it as WebP, size it to the largest dimension it actually displays at (a 3000px-wide photo in a 1200px container wastes most of its bytes), and make sure it is not lazy-loaded. That last one catches people out constantly — lazy loading is good for images below the fold and actively harmful for the one at the top, because the browser delays the exact file it should be rushing.
2. Stop render-blocking requests (LCP)
Every stylesheet and synchronous script in your <head> is a gate the browser must pass before it paints anything. A typical WordPress install accumulates a dozen of these from plugins that load their CSS on every page whether they're used or not.
Open DevTools, look at the network waterfall, and find requests that finish before your first paint begins. Anything that isn't needed for above-the-fold rendering should be deferred, loaded asynchronously, or conditionally dequeued on pages that don't use it.
3. Reserve space for anything that loads late (CLS)
Layout shift has one dominant cause: elements that arrive after the first paint and shove existing content down. Images without width and height attributes, ad slots, embedded videos, cookie banners, and web fonts that swap.
The fix is always the same — reserve the space in advance. Set explicit dimensions on images, give ad containers a fixed min-height, and use font-display: swap with a metric-compatible fallback so text doesn't reflow when your webfont lands. CLS is the easiest of the three to score well on, because it's almost entirely a discipline problem rather than a performance one.
4. Cut JavaScript before you cache it (INP)
INP replaced First Input Delay because responsiveness turned out to matter more than initial delay. It measures the whole interaction: tap, processing, repaint.
Caching plugins do nothing for INP. What helps is having less JavaScript competing for the main thread. Audit your plugins honestly — sliders, page builders, animation libraries, chat widgets, and analytics stacks are the usual offenders. A plugin you installed for one page but loads on all of them is pure tax.
5. Use a caching plugin (LCP, TTFB)
Now cache. Page caching turns a database-driven render into a flat file, which typically cuts server response time from several hundred milliseconds to a few dozen. It's a genuine win — it's just fourth on the list, not first, because caching a bloated page produces a fast bloated page.
6. Get your fonts under control
Self-host them. A Google Fonts request means an extra DNS lookup, TLS handshake, and round trip before any text renders in your chosen typeface. Self-hosted WOFF2 files with preload on the one or two weights you actually use will beat the CDN every time. And be ruthless: most sites ship six font weights and use three.
7. Trim the database and the autoloaded options
WordPress loads every option marked autoload = yes on every single request. Plugins that have been installed and removed over the years often leave theirs behind. A site with 2 MB of autoloaded options is paying that cost on every page view, forever. Check it, clean it, and clear out post revisions and expired transients while you're there.
8. Only then, consider a CDN
A CDN helps genuinely global audiences and does very little for a site whose visitors all live in one country near the origin server. It's a good final optimisation and a poor first one.
How to know it worked
Test with field data, not lab data. PageSpeed Insights lab scores fluctuate wildly and measure a simulated device; the Core Web Vitals report in Google Search Console shows what real visitors experienced. Lab tools tell you what to fix, field data tells you whether the fix landed. Give it 28 days — that's the rolling window Google uses.
One caveat worth keeping in perspective: Core Web Vitals is a real ranking signal but a small one. A fast page with thin content still loses to a slow page that answers the question better. Fix your speed because it improves conversions and because visitors deserve it — then go back to the fundamentals.
