Three metrics, three thresholds, and one rule that decides everything: assessment happens at the 75th percentile of real page loads, segmented across mobile and desktop.
| Metric | Measures | Good | Needs work | Poor |
|---|---|---|---|---|
| LCP | Loading | ≤ 2.5s | 2.5–4.0s | > 4.0s |
| INP | Responsiveness | ≤ 200ms | 200–500ms | > 500ms |
| CLS | Visual stability | ≤ 0.1 | 0.1–0.25 | > 0.25 |
The 75th percentile is the part that changes how you work. You are not optimising for a typical visitor. You are optimising so that three-quarters of real page loads clear the threshold — which means the slowest quarter of your visitors, on the oldest phones and the worst connections, are the ones deciding your assessment.
And note that "First Input Delay" is gone. INP became a stable Core Web Vital in 2024 and FID was retired. Any guide still optimising for FID is at least two years behind.
LCP: the loading number
LCP measures when the largest visible element finishes rendering — usually an image, sometimes a heading or a block of text.
On WordPress it is almost always one image: the featured image, a hero banner, or the first image in a post.
The diagnostic that names your fix
LCP is not one number. It breaks into four consecutive parts, and web.dev gives target proportions for each:
| Subpart | What it is | Should be about |
|---|---|---|
| Time to First Byte | Before the browser has any HTML | ~40% |
| Resource load delay | HTML arrived, image not yet requested | < 10% |
| Resource load duration | The image downloading | ~40% |
| Element render delay | Image loaded, not yet painted | < 10% |
Whichever part is oversized names the fix, and the two delays are the diagnostic ones:
- A large resource load delay means the browser found the image late. The image is in CSS, or behind JavaScript, or lazy-loaded when it should not be
- A large resource load duration means the image is simply too heavy for the connection
- A large TTFB is a hosting or caching problem, not an image problem
- A large render delay usually means render-blocking CSS or a web font holding up the paint
The guiding principle from web.dev: "The vast majority of the LCP time should be spent loading the HTML document and LCP source. Any time before LCP where one of these two resources is not loading is an opportunity to improve."
The WordPress causes, in order
Lazy-loading the LCP image. WordPress adds loading="lazy" automatically and core tries to skip images near the top of the page — but themes, page builders and image plugins routinely defeat that logic. web.dev's position leaves no room: "Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay, and will have a negative impact on LCP."
Check the rendered HTML, not the settings screen. View source on a real post and look at the <img> tag for the hero. If it carries loading="lazy", that is your problem and it is a five-minute fix.
No fetchpriority="high". Without it, the browser treats the hero the same as every other image on the page and may fetch it after scripts and fonts.
An oversized original. A 3000-pixel-wide photograph displayed at 800 pixels, uploaded straight from a phone.
Slow TTFB. Covered in speed up WordPress, and it puts a floor under LCP that no image work can get below.
A slider as the hero. Sliders load a library, then decide what to show, which is close to worst-case for LCP.
INP: the responsiveness number
INP measures the delay between a visitor interacting and the screen updating, across all interactions on the page — not just the first one, which is what FID measured.
The three parts of an interaction
- Input delay — the time before your event handler can run, because the main thread is busy
- Processing duration — how long your handler takes
- Presentation delay — the time before the browser paints the result
"The sum of these three subparts is the total interaction latency."
On WordPress, input delay is usually the culprit, and the reason is structural: the main thread is one queue, and everything shares it.
What causes poor INP on WordPress
web.dev names the general causes — script loading and parsing, long tasks delaying callbacks, large DOM sizes, layout thrashing, excessive client-side rendering. Here is what each looks like on a WordPress site.
| Cause | What it is on WordPress |
|---|---|
| Long tasks blocking the thread | Analytics, tag managers, chat widgets, A/B testing scripts |
| Large DOM | Page builders producing deeply nested wrapper divs around every element |
| Scripts loading everywhere | Plugins enqueueing their assets on every page rather than where they are used |
| Continuous work | Sliders, carousels, animated counters, parallax effects |
| Excessive client-side rendering | Block-based interactivity or a headless front end doing layout work in the browser |
The uncomfortable finding for most WordPress sites: the single biggest INP improvement is usually removing something, not optimising it. A chat widget you enabled two years ago and never used costs every visitor on every page.
What actually helps
- Remove what you do not use. Audit method in how to audit your WordPress plugins
- Load third-party scripts only where needed, not site-wide from the theme header
- Defer non-critical JavaScript so it does not compete with interaction handling
- Reduce DOM size, which usually means simplifying page-builder layouts rather than adding a plugin
- Do less in event handlers, and yield to the main thread between chunks of work
Test INP by interacting, not by loading. A lab page load tells you almost nothing about it. Open the page and click the menu, the search box, the accordions — the things visitors touch.
CLS: the stability number
CLS measures how much visible content moves unexpectedly while the page loads. It is the metric behind clicking the wrong thing because a banner appeared.
It is the easiest of the three to fix, and the causes on WordPress are short and predictable.
| Cause | Fix |
|---|---|
| Images without dimensions | Set width and height so space is reserved before the file loads |
| Embeds and iframes | Give them a container with a reserved aspect ratio |
| Cookie or consent banners | Overlay rather than insert, or reserve their space in the layout |
| Web fonts | font-display: swap with a fallback matched for size, so the swap does not reflow the text block |
| Ads and dynamic content | Reserve the slot at its largest expected size |
| Anything injected above the fold late | Notification bars, announcement banners, region pickers |
The font one is the subtle case. font-display: swap alone does not fix CLS — it guarantees the text is visible, then shifts everything when the real font arrives at a different size. Matching the fallback's metrics is what removes the shift.
And the banner one is the most common. A consent banner that pushes the page down after 400 milliseconds produces a large CLS on every single page view, and it is entirely avoidable by overlaying rather than inserting.
Diagnosing which one is failing
Five steps, in order.
Step 1 — Read the field data in Search Console
Core Web Vitals report, mobile and desktop separately. This is the assessment. It groups URLs, so a failing group usually means a failing template rather than a failing page.
Field data lags, because it is a rolling window of real visits. That is normal and it is why you do not iterate against it.
Step 2 — Pick one representative URL and run PageSpeed Insights
Read the field section first, then the lab diagnostics. The score at the top is a weighted lab composite and is not what is assessed.
Step 3 — Break the failing metric into its parts
For LCP, get the four subparts and compare against the target proportions. For INP, interact with the page in Chrome DevTools rather than reloading it. For CLS, watch what moves.
This step is where most people skip to a plugin. The subpart breakdown is what turns "LCP is 4 seconds" into a specific instruction.
Step 4 — Change one thing, on the template
Fix it in the theme or template, not on the single post you tested. The report groups by template, and so does the improvement.
One change at a time, or you will not know which one worked.
Step 5 — Confirm in the lab, then wait for the field
Lab data confirms the change took effect. Field data confirms it mattered, and it takes time to accumulate because it is measuring real visits.
Do not re-optimise while waiting. That is how sites end up with three caching plugins.
The mobile-first detail people miss
Assessment is segmented across mobile and desktop, and mobile is where WordPress sites fail.
A site can pass on desktop and fail on mobile with identical code, because the phone has less CPU for the JavaScript, a slower connection for the images, and a narrower viewport that makes layout shifts proportionally larger.
So test on mobile settings by default, and treat a desktop pass as no information at all.
Frequently asked questions
What are the Core Web Vitals thresholds?
LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less — assessed at the 75th percentile of real page loads, segmented across mobile and desktop.
Why does my WordPress site fail LCP?
Usually the hero or featured image: lazy-loaded when it should not be, without fetchpriority, or far larger than displayed. Slow server response time is the other common cause, and it puts a floor under LCP that image work cannot get below.
Should I lazy-load images in WordPress?
Yes, except the LCP image. web.dev states never to lazy-load it, because that always adds unnecessary resource load delay. WordPress tries to skip images near the top automatically, but themes and page builders often defeat that — check the rendered HTML.
What is a good INP score and how do I improve it?
200 milliseconds or less at the 75th percentile. On WordPress the improvement usually comes from removing third-party scripts, loading plugin assets only where used, reducing DOM size from page builders, and deferring non-critical JavaScript.
What causes CLS on a WordPress site?
Images and embeds without reserved dimensions, cookie banners that insert rather than overlay, and web fonts that reflow text when they load. Setting width and height on images fixes the largest share of it.
Does font-display: swap fix CLS?
Not on its own. It makes text visible sooner, then shifts the layout when the real font arrives at a different size. Matching the fallback font's metrics to the web font is what removes the shift.
Why does Search Console show different numbers from PageSpeed Insights?
Search Console reports field data from real visits over a rolling window. The PageSpeed score is a lab simulation of one load on a synthetic device. They measure different things and routinely disagree.
Why do I pass on desktop but fail on mobile?
Assessment is segmented, and phones have less CPU for JavaScript, slower connections for images, and narrower viewports that make layout shifts proportionally larger. Identical code can pass one and fail the other.
What to do next
Open one of your published posts and view source. Find the <img> tag for the hero or featured image and check two things: whether it says loading="lazy", and whether it has fetchpriority="high".
If the first is present and the second is missing, you have found the most common WordPress LCP failure, and fixing it in the template fixes every post using it.
Related guides
- Speed up WordPress: what actually moves the number — the levers in order of payoff
- WordPress caching explained — the layer under TTFB and LCP
- How to audit your WordPress plugins — finding what is blocking the main thread
- Choosing WordPress hosting for speed — when TTFB is the ceiling
- Technical SEO: what actually needs fixing — where speed sits among the signals
- Google Search Console reports, read properly — including the Core Web Vitals report
The short version
- Read the field data in Search ConsoleCore Web Vitals report, mobile and desktop separately. It groups URLs, so a failing group usually names a failing template rather than one page.
- Run PageSpeed Insights on one representative URLRead the field section first and the lab diagnostics second. The score at the top is a weighted lab composite, not the assessment.
- Break the failing metric into its partsFor LCP compare the four subparts against their target proportions. For INP, interact with the page rather than reloading it. For CLS, watch what moves.
- Change one thing, in the templateThe report groups by template and so does the improvement. One change at a time, or you will not know which one worked.
- Confirm in the lab, then wait for the fieldLab data confirms the change took effect; field data confirms it mattered, and it accumulates from real visits. Do not re-optimise while waiting.
The WordPress Email Delivery Checklist
Stop your WordPress emails from failing silently. Get the complete setup guide.
Muhammad Basim has worked in digital marketing since 2013, focused on email deliverability and AI-assisted content production. He is the author of The Email Deliverability Playbook and The Email Copywriting Playbook.
Related Articles
Choosing a WordPress SEO Plugin
This page names no winner, and the reason is that the choice matters far less than the category's marketing implies. The major WordPress SEO plugins do the same six things. They have converged, they will continue to converge, and the difference between them is interface preference and a small number of features most sites never […]
Two-Factor and Login Hardening for WordPress
Login attacks against WordPress are constant, automated and indiscriminate. Every public WordPress site receives them, regardless of size or traffic, because the cost of trying is near zero. They are also the least successful route into a WordPress site. Vulnerable plugins account for more compromises than password guessing, which is worth holding onto — login […]
WordPress Email: Why Your Site’s Emails Never Arrive
WordPress sends email in a way that fails modern authentication by default, and it reports success while doing it. That combination is why this problem is so persistent. The site is not broken. Nothing is logged. wp_mail() returns true, the order is placed, the form says thank you — and the message never reaches an […]