Performance
Core Web Vitals for WordPress, without the jargon
9 August 2026 · 7 min read
On this page
Core Web Vitals are three measurements Google uses to describe how a page feels to use. They are a ranking factor, though a smaller one than most agencies imply, and they are a genuinely good proxy for whether visitors will stay.
Here is what each one means and what fixes it on WordPress.
LCP — how long until the main thing appears
Largest Contentful Paint measures when the biggest visible element finishes loading. Usually your hero image or headline.
Pass: under 2.5 seconds. Between 2.5 and 4 needs work. Over 4 is failing.
This is the one that matters most and the one most WordPress sites fail. The causes, in order:
Slow server response. If your time to first byte is over 600ms, nothing else you do will rescue LCP. This is usually hosting, and no plugin fixes a slow server.
An enormous hero image. A 3MB photograph as your banner is a guaranteed fail. Resize, compress, convert to WebP.
Render-blocking CSS and JavaScript. The browser will not paint until it has processed them.
No caching. Without it WordPress rebuilds the page from the database on every request. Caching properly configured is the single biggest easy win.
INP — how quickly the page responds when you touch it
Interaction to Next Paint replaced First Input Delay in 2024. It measures the delay between a click or tap and the page visibly reacting.
Pass: under 200ms. Up to 500ms needs work.
INP is almost entirely a JavaScript problem. The usual WordPress causes:
- Too many plugins each loading their own scripts
- A page builder shipping large JavaScript bundles
- Third-party scripts — chat widgets, analytics, ad pixels, embedded video
- jQuery loaded multiple times by different plugins
The fix is nearly always removal rather than optimisation. Audit what is loading and delete what you do not need. A single badly built plugin can dominate this number.
CLS — how much the page jumps around
Cumulative Layout Shift measures content moving after it appears. You start reading, an ad loads, the text jumps down, you lose your place.
Pass: under 0.1.
The WordPress causes are specific and fixable:
Images without width and height attributes. The browser does not know how much space to reserve, so everything below moves when the image arrives. WordPress adds these automatically now, but themes and page builders sometimes strip them.
Web fonts swapping. Text renders in a fallback font, then reflows when the custom font loads. Use font-display: swap with a fallback of similar metrics.
Content injected above existing content. Cookie banners, notification bars, ads. If it must be there, reserve the space for it.
CLS is usually the easiest of the three to fix and the one people ignore, because it does not feel like "speed".
How much do they actually affect rankings?
Less than the SEO industry suggests, and more than nothing.
Google has been explicit that Core Web Vitals are one signal among many, and that relevance beats speed. A fast page about the wrong thing does not outrank a slow page about the right thing.
Where they matter: as a tiebreaker between similarly relevant results, and — far more importantly — for conversion. A page that takes four seconds and jumps around loses visitors regardless of where it ranks.
Optimise for the visitor, not the score. A perfect 100 in PageSpeed Insights with a 3-second LCP on real devices is worth nothing. Measure what real users experience, not what a lab test says.
Where to see your real numbers
PageSpeed Insights shows both: lab data from a simulated test, and field data from real Chrome users if you have enough traffic. The field data is the one Google uses. Lab data is diagnostic.
Search Console → Core Web Vitals shows your whole site grouped by URL pattern, which is how you find out that your blog passes and your product pages do not.
Low-traffic sites often have no field data at all. In that case the lab numbers are all you have, and they are a reasonable guide even though they are not what is measured.
The realistic order of work
- Fix hosting if TTFB is over 600ms — nothing else matters until this is right
- Caching, configured properly, one layer not three
- Images — resize, compress, WebP, dimensions set
- Remove plugins you do not need, especially script-heavy ones
- Then defer render-blocking assets, which is the fiddliest and most likely to break a layout
Most sites get the majority of their improvement from the first three.
If you would rather not do it, our speed optimisation is a fixed $299 with before and after Core Web Vitals you can verify yourself — and we will tell you honestly if hosting is the bottleneck rather than taking the money for a 10% gain.