Core Web Vitals on WordPress: what actually moves the number
Most WordPress speed advice is a list of plugins. Here's the shorter list of things that genuinely shift LCP, CLS and INP — in the order I do them on client sites.

Every WordPress performance audit I inherit has the same shape: four caching plugins, three of them fighting each other, and a Lighthouse score that hasn't moved in a year. The plugins aren't the problem. The order of operations is.
Core Web Vitals measure three specific things, and each one has a small number of real causes. If you fix causes instead of installing tools, most sites get to green in a day.
1. LCP is almost always an image or a font
Largest Contentful Paint is the moment the biggest thing above the fold finishes rendering. On nine out of ten marketing sites that's a hero image or a headline waiting on a web font.
- Serve the hero as AVIF or WebP with explicit width and height attributes — no lazy-loading on the LCP element, ever.
- Preload the hero image and the single font file used in the headline. One preload each, not eight.
- Use font-display: swap and subset the font to the characters you actually ship.
- Kill the slider. Carousels above the fold are the single most reliable way to destroy LCP.
2. CLS is a reservation problem
Cumulative Layout Shift happens when the browser doesn't know how much room something needs until it arrives. The fix is always the same: reserve the space up front.
- Width and height (or aspect-ratio) on every image, iframe and video embed.
- Fixed min-height on ad slots, cookie banners and anything injected by a third-party script.
- Fallback fonts sized with size-adjust so the swap doesn't reflow the paragraph.
3. INP is your JavaScript budget
Interaction to Next Paint replaced FID because FID was too forgiving. INP measures how long the page takes to respond after a real interaction — and on WordPress, the answer is usually 'after jQuery and six tracking scripts finish arguing'.
- 01Open the Coverage panel and find the JavaScript that never executes on that template. Dequeue it per-page rather than globally.
- 02Move analytics, chat widgets and heatmaps behind an interaction or idle callback.
- 03Replace jQuery-dependent plugins on critical templates. One plugin swap often halves main-thread time.
- 04Defer everything that isn't required for the first interaction.
The order I actually work in
Measure on real field data first — CrUX or Search Console, not a single Lighthouse run on your office fibre connection. Lab tools tell you what could be slow; field data tells you what is slow for the people you care about.
A 95 in Lighthouse and a failing CrUX report means you optimized for the test, not the visitor.
Then: images, fonts, layout reservations, JavaScript diet, caching last. Caching is the amplifier — it makes a fast site faster and a slow site slow-but-cached.
Rajat Bharti
Senior Web Developer in Bengaluru, IN. Writes about performance, automation and the parts of client work nobody documents.


