How to pass Core Web Vitals on WordPress
Core Web Vitals fail differently for different reasons, and the fix for one can make another worse. Deferring JavaScript to help LCP can hurt INP. Reserving space to fix CLS can push your LCP element down the page. So the useful approach is metric by metric rather than plugin by plugin.
The thresholds, so they are on the page: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. You need the 75th percentile of real visits to pass — meaning three quarters of your actual visitors must experience it, not your best-case lab test.
LCP — Largest Contentful Paint
LCP measures when the biggest visible element finishes rendering. On most business pages that is the hero image or the headline. This is the metric WordPress sites fail most often.
The four WordPress-specific causes, in the order worth checking:
- The hero image is lazy-loaded. WordPress adds `loading="lazy"` automatically. On the LCP element this is actively harmful — the browser deliberately waits before fetching the exact image the metric is timing. Exclude above-the-fold images from lazy loading.
- TTFB is high. If the server takes 1.5 seconds to respond, LCP cannot be under 2.5 without everything else being perfect. Fix the hosting first; nothing downstream compensates.
- Render-blocking CSS. The browser will not paint until it has processed the stylesheets in the head. Thirty stylesheets means thirty things standing between the visitor and the page.
- The image is enormous. A 4MB unoptimised JPEG hero cannot produce a fast LCP on a mobile connection, no matter what else you do.
INP — Interaction to Next Paint
INP replaced First Input Delay in March 2024 and it is stricter. FID measured only the delay before the browser started handling an interaction. INP measures the whole thing — tap to visible response — across every interaction in the visit, and reports near the worst.
On WordPress, INP failures are almost always JavaScript execution on the main thread. The usual suspects are page builder runtimes, sliders and carousels, chat widgets, and analytics or tag manager stacks with several tags firing.
This one has no plugin fix. You reduce it by running less JavaScript. That is why INP is the metric that most often turns an optimisation conversation into a rebuild conversation — you cannot defer your way out of code that has to run.
CLS — Cumulative Layout Shift
CLS measures how much content jumps while loading. It is the most fixable of the three and the most irritating to users — it is what makes you tap the wrong button because an ad loaded above your thumb.
The WordPress causes are consistent and each has a real fix:
- Images without width and height. The browser cannot reserve space, so everything below jumps when the image arrives. Setting the attributes is enough; the browser computes the ratio.
- Web fonts swapping. Text renders in a fallback font, then reflows when the web font loads. `font-display: optional`, or preloading the font, stops the reflow.
- Cookie banners and promo bars injected at the top. These push the entire page down after it has rendered. Reserve the space or overlay them rather than inserting into the flow.
- Ads and embeds without a reserved container. Same problem, same fix — give the slot a fixed height.
Where optimisation stops working
CLS is nearly always fixable on WordPress. LCP is usually fixable with better hosting, image work and careful CSS. INP is the wall — if a page builder runtime plus five plugins have to execute before the page responds, no configuration change removes that work.
So the practical test is: fix CLS and LCP first, because they are cheap. If INP is still failing after that, the JavaScript is structural, and you are choosing between living with it and rebuilding.
Common questions
What are the Core Web Vitals thresholds?
LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. You must hit these at the 75th percentile of real user visits — three quarters of actual visitors — not in a lab test.
Why does my PageSpeed score say 95 but Search Console says I am failing?
They measure different things. The PageSpeed score is a lab simulation on a synthetic device. Search Console reports field data from real Chrome users on real devices and connections. Field data is what counts for ranking, and it is almost always worse than lab data because real phones are slower than simulated ones.
Can a plugin fix Core Web Vitals?
Optimisation plugins can genuinely help LCP and CLS — image conversion, dimension attributes, critical CSS. None of them meaningfully fix INP, because INP is caused by JavaScript that has to execute and a plugin cannot decide your code is unnecessary. If INP is your failing metric, you are looking at removing functionality or rebuilding.
How long after fixing do rankings recover?
Field data is a 28-day rolling window, so Search Console will not show the improvement for about a month even if the fix worked on day one. Do not judge a fix by week two.
Want us to look at your site?
We will tell you whether the problem is hosting, plugins, architecture or something else entirely — including when the answer is that you should not rebuild and should spend the money on traffic instead. No charge for the assessment.
Pricing: US clients (USD) · India clients (INR)
Related guides
- Why your WordPress site is slow — and what actually fixes it
- Migrating WordPress to Next.js: what it involves and what it costs
- How to migrate a website without losing your Google rankings