WordPress can pass Core Web Vitals comfortably. What usually stops it is not WordPress — it is twenty-eight plugins, a page builder generating deeply nested markup, and a 4MB hero image being lazy-loaded.
This is the fix list I work through, in the order that produces the most improvement per hour spent.
First: measure the right thing
Ignore the score out of 100. Google uses field data — real Chrome users on your site over the previous 28 days — and that is what appears in Search Console under Experience > Core Web Vitals. Start there.
PageSpeed Insights is useful for diagnosis because it tells you why, but a lab score of 94 on a site whose field data is failing tells you nothing. Check field data first, then use lab tools to find the cause.
The three metrics:
- LCP (Largest Contentful Paint) — how long until the biggest visible element renders. Target under 2.5s.
- CLS (Cumulative Layout Shift) — how much the layout jumps while loading. Target under 0.1.
- INP (Interaction to Next Paint) — how quickly the page responds to input. Target under 200ms.
Fixing LCP on WordPress
LCP is nearly always the hero image or a render-blocking stylesheet.
- Identify the LCP element in PageSpeed Insights. Do not guess.
- Never lazy-load it. This is the single most common self-inflicted WordPress LCP problem: an optimisation plugin lazy-loads every image including the one above the fold, which guarantees a late LCP. Exclude it explicitly.
- Serve it at the right size. A 3000px-wide image displayed at 800px wastes most of its bytes. Correct
srcsetand sizes attributes matter more than compression level. - Convert to WebP or AVIF. Typically 30–50% smaller than an equivalent JPEG.
- Preload it with
fetchpriority="high". - Reduce render-blocking CSS. Most WordPress sites load the full stylesheet of every active plugin on every page. Inline critical CSS, defer the rest, and remove plugin CSS from pages where the plugin is not used.
- Check your host. Time to First Byte above roughly 600ms puts LCP under pressure before a single image loads. Sometimes the honest fix is better hosting, not another plugin.
Fixing CLS on WordPress
- Set width and height on every image so the browser reserves space. Missing dimensions are the classic cause.
- Use
font-display: swapand preload the fonts used above the fold. Late-swapping webfonts shift text visibly. - Reserve space for anything injected — cookie banners, notification bars, ads, embedded widgets. An element that appears after paint and pushes content down is pure CLS.
- Be careful with sliders and animated hero sections, which commonly shift on initialisation.
- Avoid inserting content above existing content after load.
Fixing INP on WordPress
- Audit third-party scripts. Chat widgets, heat-mapping, multiple analytics tags and ad scripts are usually the largest contributors. Ask what each one earns.
- Defer non-critical JavaScript, and load things like chat widgets on interaction rather than on page load.
- Cut plugin JavaScript that loads site-wide for a feature used on one page. Conditional loading is worth the setup effort.
- Reduce main-thread work — long tasks from heavy sliders, animation libraries and over-configured page builders.
Plugin rationalisation — the biggest WordPress-specific win
Go through the active plugin list and ask three questions of each one: what does it do, is anything else already doing that, and does it load assets on pages where it is not used. Typical findings:
- Two caching or optimisation plugins fighting each other
- Two SEO plugins both emitting canonical and meta tags
- A slider plugin loading its library site-wide for one homepage section
- A form plugin loading CSS and JS on every page for a form on the contact page
- A “related posts” plugin running expensive queries on every request
Remove plugins on staging, with a backup, one at a time. Not all at once, and not on production on a Friday.
Page builders
Elementor, Divi, WPBakery and heavy Gutenberg block libraries all add markup depth and asset weight. You can improve them substantially — disable unused widgets and features, cut global animation libraries, enable the builder’s own performance options, avoid nesting sections more than necessary. But there is a structural ceiling. If a site needs to be exceptionally fast and the builder is genuinely the constraint, the honest answer is that the template has to change, and a caching plugin will not fix it.
Caching and CDN, done in the right order
Caching should be the last layer, not the first. A caching plugin installed on top of unresolved problems hides them from you while still serving them to some users. Get the underlying page fast, then add page caching, then object caching if the site is database-heavy, then a CDN for static assets.
And verify that your caching layer is not serving stale pages to Googlebot — that one is easy to miss and genuinely damaging.
After the work: verify in field data
Field data updates on a 28-day rolling window, so Search Console will not reflect your changes immediately. Expect two to four weeks before the Core Web Vitals report moves. Use lab tools to confirm the fix landed in the meantime, but judge success on field data.
Frequently asked questions
Can a WordPress site pass Core Web Vitals?
Yes, routinely. The usual obstacles are oversized images, lazy-loading the above-the-fold hero, render-blocking CSS from unused plugins, and third-party scripts — not WordPress itself. Some heavy page-builder templates hit a structural ceiling that requires a template change rather than further optimisation.
Which is the best WordPress speed plugin?
No plugin substitutes for fixing the underlying problems. Caching and optimisation plugins help once images, render-blocking assets and plugin bloat are addressed; installed first, they mask problems rather than solving them. Whichever you use, run only one.
Why does PageSpeed Insights show a good score but Search Console says my site is failing?
PageSpeed Insights includes a lab test run in controlled conditions. Search Console reports field data from real Chrome users on real devices and networks over 28 days. Google uses the field data. Always trust it over the lab score.
What is the most common LCP mistake on WordPress?
Lazy-loading the largest above-the-fold image. An optimisation plugin applies lazy-loading site-wide, the hero image is deferred, and LCP is guaranteed to be late. The fix is excluding that image explicitly, and it is often the single biggest improvement available.
How long before Core Web Vitals improvements show in Search Console?
Two to four weeks, because field data is a 28-day rolling average. Lab tools will confirm the fix landed immediately, but the official report lags by design.
Will removing plugins break my site?
It can, which is why removals belong on staging with a backup in place, done one at a time so cause and effect are clear. Every removal should have a reason and a rollback path.
Does hosting affect Core Web Vitals?
Yes. Time to First Byte above roughly 600ms puts LCP under pressure before any front-end work begins. On cheap shared hosting, better hosting is sometimes the highest-impact single change available.
Want this done rather than read?
Core Web Vitals work on WordPress is careful, incremental and best done with backups and staging — which is exactly how WordPress SEO services are structured here. Send me the URL and I will tell you what is slowing it down.