Core Web Vitals Assessment Failed on WordPress? What It Means and What to Fix First

“Core Web Vitals Assessment: Failed” means that for real Chrome visitors over the last 28 days, at least one of the three metrics (LCP, INP or CLS) was outside the “good” range at the 75th percentile. It comes from field data, not from the Lighthouse score below it, which is why a page can score 90 and still fail.

Here’s how to read the report, find the metric and pages that failed, and fix a WordPress site in the order that gets you to “Passed” fastest.

What “Core Web Vitals Assessment: Failed” actually means

Core Web Vitals are three measurements Google uses to describe real-world page experience:

• Largest Contentful Paint (LCP): how long the main content (usually the hero image or headline) takes to appear.
• Interaction to Next Paint (INP): how quickly the page responds visually when someone taps, clicks or types. INP replaced First Input Delay on March 12, 2024.
• Cumulative Layout Shift (CLS): how much the layout jumps around while the page loads.

PageSpeed Insights takes these from the Chrome User Experience Report (CrUX), which is anonymised data from real Chrome users, covering the previous 28 days. According to Google’s PageSpeed Insights documentation, a page or origin passes only if the 75th percentile of all three metrics is “good”. If there isn’t enough INP data, it passes when LCP and CLS are both good. The thresholds are:

The 75th percentile means three out of four visits have to be at least that good. Your fast office connection doesn’t count for much; a mid-range phone on mobile data does.

Why you can score 90+ and still fail

The big coloured score in PageSpeed Insights comes from Lighthouse, a lab test: one simulated device, one network profile, one page load. The assessment above it is field data from your real visitors. Google’s article on why lab and field data differ covers this in detail. The common reasons on WordPress sites:

• Lighthouse can’t measure INP. Nobody clicks anything in a lab test. Lighthouse uses Total Blocking Time (TBT) as a stand-in, as web.dev explains. A page can have a low TBT and still respond slowly when real people open menus, accept cookie banners or submit forms.
• Real visitors aren’t the test device. Older phones, slow networks and visitors far from your server all pull the 75th percentile down.
• Logged-out, uncached and long sessions. Lab tests load one page once. Real users hit uncached pages, scroll, open popups and trigger scripts that load later.
• You may be looking at origin data. If the page doesn’t have enough traffic, PageSpeed Insights falls back to data for the whole origin (your entire domain). A fast landing page can show “Failed” because your blog or shop pages are slow.
• Mobile and desktop are separate. They’re assessed separately. Mobile is the one that usually fails.

Use the lab score to test fixes quickly. Use the field assessment to judge whether they worked.

Find the metric, and the pages, that failed

In PageSpeed Insights, the field section shows each metric’s 75th-percentile value with a red, amber or green marker. Note which metric is not green, and whether the data says “this URL” or “origin”.

Then open the Core Web Vitals report in Google Search Console. It groups similar URLs (for example all blog posts, or all product pages) and gives each group the status of its worst metric. That tells you whether the problem is one template or the whole site, which matters on WordPress: fixing the single-post template fixes every post at once.

The fix order for WordPress

Fix the failing metric first. If more than one fails, this order usually works best, because server speed affects everything after it. The same order sits behind the speed checks in our MarTech audit checklist.

1. LCP: start at the server

Google’s LCP guide breaks LCP into four parts: Time to First Byte (TTFB), the delay before the LCP image starts downloading, the download itself, and the time to render it. On WordPress, the first part is often the biggest. PHP builds each page on request unless it’s cached, and a slow shared server can use up much of the 2.5-second budget before the browser receives any HTML.

1. Cut server response time: enable full-page caching (at the host or with a caching plugin), run a current PHP version, and put a CDN in front of the site. If TTFB is still slow on cached pages, the hosting is the bottleneck.
2. Fix the LCP element: find it in the PageSpeed diagnostics. If it’s an image, compress and resize it, make sure it isn’t lazy-loaded, and let it load with high priority (fetchpriority="high"). If it’s a slider, replace it with a single image.
3. Reduce render-blocking resources: fewer CSS files in the head, fewer font files, and no unused stylesheets from plugins loading on every page.

If your site is built with a page builder, the template structure matters as well. I’ve covered the Elementor-specific causes separately.

This is the core of my hosting and Core Web Vitals work: fix server response first, then the front end. Results I’ve delivered include −25% load time.

2. INP: get scripts off the main thread

Google’s INP guide splits each interaction into input delay, processing time and presentation delay. On WordPress, input delay is the usual culprit: the browser is busy running long JavaScript tasks when the visitor taps, so the tap waits.

• List every script on the page (chat, popups, heatmaps, several ad pixels, sliders, cookie tools). Remove what nobody uses.
• Load marketing tags through one tag manager and fire them on the right triggers instead of all on page load.
• Check plugins that add front-end JavaScript to every page even where they’re not used.
• Test the interactions real users perform: opening the mobile menu, accepting the cookie banner, submitting the main form.

If you find a script you don’t recognise, don’t just delete it. Unfamiliar scripts can also be a sign of a hack, and a sudden drop in your metrics is sometimes the first symptom.

3. CLS: reserve space for everything

Layout shift happens when something appears and pushes content down. Google’s CLS guide lists the usual causes: images, ads, embeds and iframes without dimensions, content injected after load, and web fonts.

• Give every image and video width and height attributes (WordPress adds them for images inserted through the media library; custom HTML and some themes don’t).
• Reserve space for embeds, maps and ad slots with a fixed-height container.
• Show cookie and promo banners as overlays rather than inserting them above the content.
• Use a fallback font with similar proportions so the swap to the web font barely moves the text.

Want a second pair of eyes before you start? You can have your Core Web Vitals checked for free as part of my MarTech audit. I’ll tell you which metric to fix first and why.

Arabic and RTL sites: fonts, LCP and CLS

Bilingual and Arabic sites, common across Saudi Arabia and the Gulf, have a few extra traps, almost all related to fonts:

• Two sets of fonts. A site that loads a Latin family and an Arabic family in several weights each downloads many font files. Load only the weights each language actually uses.
• Text as the LCP element. On text-heavy Arabic hero sections, the headline is often the LCP element, so a late web font delays LCP directly. Serve fonts from your own domain and preload only the one used above the fold.
• Font swap shifts. Arabic fallback fonts can have quite different proportions from the web font, so the swap moves text. Pick a fallback with similar metrics, or use font-display: optional, which Google suggests for avoiding re-layout.
• Test each language separately. CrUX reports by URL, so /ar/ pages can fail while the English pages pass. Check both in Search Console.

How long until it says “Passed”?

The field data covers a rolling 28 days, so your fixes blend in gradually. PageSpeed Insights updates its field data daily, but the assessment flips only once enough of those 28 days reflect the faster site. Expect it to take up to about four weeks after the fix goes live, longer for low-traffic pages.

In Search Console’s Core Web Vitals report, open the issue once you’ve fixed it on every affected URL and start validation (Google’s help page calls the button “Start Tracking”). Google then monitors those URLs for 28 days. Meanwhile, use the lab score and Chrome DevTools to confirm each change helps.

FAQ

Why does PageSpeed say “Failed” when my score is green?

The score is a one-off lab test. The assessment is real-user data over 28 days at the 75th percentile, and it includes INP, which the lab test can’t measure. They answer different questions.

What does “origin” mean in the Core Web Vitals section?

The page didn’t have enough real-user data, so PageSpeed Insights is showing data for your whole domain. Fixing one page won’t change it much; look for the slow templates in Search Console.

Will a caching plugin fix Core Web Vitals?

It often fixes the server part of LCP, which is a big step. It won’t fix an oversized hero image, heavy third-party scripts (INP) or layout shifts (CLS).

I fixed everything. Why does it still say Failed?

The 28-day window still includes visits from before the fix. Give it up to four weeks, and check that the fix applies to mobile and to every template, not just the page you tested.