Six weeks later the Core Web Vitals report in Search Console still says the same URLs are failing. Nothing moved.

Here is why, and it is the single most important thing to understand before touching anything: the score and the assessment are two different measurements of two different things. The score is Lighthouse running a simulated page load on throttled hardware, once, from wherever you are. The assessment is Chrome telemetry from real visitors on real devices, aggregated over 28 days, graded at the 75th percentile.

Worse: Lighthouse cannot measure one of the three metrics at all. Interaction to Next Paint requires an actual human interacting with the page, so no lab tool produces it. You can score 100 and fail INP for every mobile visitor you have.

This walks through fixing Core Web Vitals on WordPress the way that actually shifts the report: get field data first, then work each metric in the order that pays.

Field data first, or you are guessing

Three facts that determine everything else.

You are graded at the 75th percentile. Three quarters of page views need a good result. Not the median, not your laptop. The fourth-slowest visitor out of four, typically a mid-range Android phone on patchy mobile data, decides whether you pass.

The window is 28 days and it rolls. Deploy a fix today and the report will not reflect it for weeks, and even then it moves gradually as old data ages out. Anyone promising you a same-week improvement in Search Console does not understand the mechanism.

Thin URLs fall back to origin-level data. If a page has too few visits for its own dataset, Google uses a group or your whole origin instead. So one badly performing template can drag URLs that are individually fine.

Practically: start in the Core Web Vitals report in Search Console to see which templates fail and how many URLs are affected. Then run PageSpeed Insights on a representative URL and read only the field data section at the top to decide what is broken. Use the Lighthouse section below it to work out why, which is what lab data is genuinely good for.

If you want faster feedback than 28 days, add real user monitoring. Google’s web-vitals JavaScript library reports all three metrics from your own visitors and you can send them wherever you like. On a site where performance matters commercially, this is worth the afternoon it takes.

LCP: the biggest thing on screen

Largest Contentful Paint is when the largest visible element finishes rendering. Good is under 2.5 seconds. On WordPress it is almost always the hero image or the first image in post content, and the causes are boringly consistent.

The lazy-loaded hero

Still the most common LCP problem on WordPress sites, years after core started handling it. Core skips lazy loading on the first image in content and adds fetchpriority="high" to the likely LCP candidate, but the heuristic only works on images core knows about. A hero rendered by a page builder, a theme header, or a slider often sits outside that, and some optimisation plugins re-add loading="lazy" to everything regardless.

# Look at what the server actually sends. If your hero image has
# loading="lazy" on it, you have found your LCP problem.
curl -s https://example.com/ | grep -o '<img[^>]*>' | head -5

For a theme-rendered hero, be explicit rather than hoping a heuristic catches it:

<!-- No loading="lazy". width and height reserve space, which
     also protects CLS. fetchpriority tells the browser this
     is the one image worth fetching before everything else. -->
<img src="/hero.webp"
     width="1600" height="900"
     fetchpriority="high"
     decoding="async"
     alt="">

Slow server response

LCP cannot be faster than time to first byte. On shared hosting with no page cache, an uncached WordPress response can eat most of your budget before a single byte of image is requested. Full-page caching is the single highest-yield change on most WordPress sites, and a CDN in front of it removes the geographic distance as well.

If TTFB is still poor with caching on, the cache is being bypassed. Cookies from analytics, a cart, or a logged-in session will do it. Check the cache-status header on a real request rather than trusting the plugin’s dashboard.

Render-blocking CSS

The browser will not paint until it has the stylesheets. A theme loading four separate CSS files plus a font stylesheet plus an icon library delays every LCP candidate on the page. Self-host fonts with font-display: swap, drop icon libraries you use six glyphs from, and be sceptical of “combine CSS” plugin features, which on HTTP/2 often make things worse rather than better.

Speculative loading, which is free

Worth knowing because most WordPress performance guides predate it. Since WordPress 6.8, core ships speculative loading using the Speculation Rules API: the browser starts fetching a link’s destination when the visitor interacts with it, so the next page is partly or entirely loaded before they arrive. It is on by default for logged-out visitors, using prefetch with “conservative” eagerness, and it is a progressive enhancement with no downside for browsers that do not support it.

You can push it further, at a cost:

add_filter( 'wp_speculation_rules_configuration', function ( $config ) {
    // Prerender actually renders the next page, including running
    // its JavaScript. Much faster, and analytics or anything with
    // side effects may fire for a visit that never happens.
    return array(
        'mode'      => 'prerender',
        'eagerness' => 'moderate',
    );
} );

Test that carefully on anything transactional. Core also honours no-prefetch and no-prerender CSS classes on individual links, which is the simplest way to keep carts, checkouts and logout links out of it.

INP: the hard one, and it is your JavaScript

Interaction to Next Paint measures the time from a user interacting to the browser painting the response, across every interaction on the page, and reports roughly the worst one. Good is under 200 milliseconds; above 500 is poor.

It replaced First Input Delay in March 2024, and the change matters more than a metric swap sounds. FID measured only the delay before processing the first interaction. INP measures the whole round trip, every time. Plenty of sites that comfortably passed FID fail INP, because the thing that was always sluggish is now the thing being graded.

Since no lab tool reports it, use Total Blocking Time in Lighthouse as a proxy, and Chrome DevTools’ Performance panel to find which handler is blocking. On WordPress the usual suspects:

• Plugin JavaScript loading site-wide. A form builder, a slider and a popup tool each shipping their bundle on every page, including pages that use none of them.
• Third-party tags. Tag managers, chat widgets, heatmaps, ad scripts. These run on the main thread and are usually the largest single contributor.
• Long tasks in event handlers. Anything doing real work synchronously in response to a click.
• jQuery-era code attaching handlers to hundreds of elements on a listing page.

The fixes, in order of yield. First, stop shipping JavaScript to pages that do not use it. Conditionally dequeue plugin assets rather than accepting that a contact form script belongs on every article. This alone often solves INP.

Second, audit the third-party tags. Every one is somebody’s request from two years ago, and at least one of them is for a tool nobody uses any more. Removing a tag is the cheapest performance work available.

Third, break up long tasks so the browser can paint between chunks:

// Yielding lets the browser respond to the click that started this,
// instead of finishing all the work first. INP measures exactly
// that gap, so yielding moves the metric even though total work
// stays the same.
async function processAll(items) {
  for (const item of items) {
    doWork(item);
    await new Promise(resolve => setTimeout(resolve, 0));
  }
}

Newer Chrome versions offer scheduler.yield(), which does the same thing without losing your place in the task queue. Feature-detect it and fall back to the above.

One honest warning: “delay JavaScript until user interaction” features in optimisation plugins look like an INP fix and frequently are not. Delaying scripts until the first interaction means the first interaction now waits for all of them to load and execute, which is the worst possible moment. It improves lab scores and can make INP worse.

CLS: usually an afternoon

Cumulative Layout Shift measures unexpected movement of visible content. Good is under 0.1, and it is the metric most likely to be fixable in one sitting.

• Images without dimensions. Set width and height so the browser reserves space before the file arrives. WordPress does this for media library images; hand-written theme markup often does not.
• Ads and embeds. Reserve a fixed-height container. An ad slot that collapses to nothing and then expands is a large shift on every page view.
• Fonts. A web font swapping in at a different metric reflows everything. font-display: swap plus size-adjust on the fallback, or a system font stack, both work.
• Cookie banners and notices injected by JavaScript that push the page down rather than overlaying it.
• Lazy-loaded content above the fold that appears after paint.

Chrome DevTools’ Performance panel highlights layout shifts with the element that moved, which turns this from detective work into a checklist.

The order I’d work in

1. Anything in the “poor” band, whichever metric it is. Poor hurts more than two mediocre metrics.
2. Caching and TTFB, because it is one change and it moves LCP for every page at once.
3. The LCP image on your highest-traffic template.
4. JavaScript you can delete. Unused plugin assets and dead third-party tags, for INP.
5. CLS, which is quick and visible to users even where the number already passes.
6. Everything else, measured one change at a time.

What I would skip: chasing a green Lighthouse score once field data passes, stacking a second optimisation plugin on top of the first, and micro-optimising a metric that is already comfortably good. There is no bonus for 1.1 seconds when 2.5 is the bar.

When the numbers don’t move

It has been two weeks. That is normal. The window is 28 days and rolling, so give it a full month before concluding anything.

Lab improved, field did not. You optimised something the lab measures and users do not experience, or the problem is INP, which the lab never measured. Go back to the field data section.

Desktop passes, mobile fails. Expected, and mobile is what is graded for most sites. Test with CPU throttling on, because the gap is usually processing rather than network.

One URL is fine but the group fails. Origin-level fallback, or a different template in the same group is dragging it. Check what else Search Console has bundled together.

It regressed after a plugin update. Very common, and the reason to record your field numbers before and after any significant change rather than relying on memory.

Common mistakes

• Treating the PageSpeed Insights score as the thing being measured.
• Optimising INP with a lab tool that cannot measure INP.
• Testing from a fast laptop on fibre and concluding the site is fine.
• Lazy-loading the hero image, or letting a plugin re-add it.
• Running two optimisation plugins that both minify and both defer.
• Enabling “delay JavaScript until interaction” and expecting INP to improve.
• Judging a fix after a week.
• Loading every plugin’s JavaScript on every page.
• Adding a CDN while the origin has no page cache.
• Fixing the homepage when the failing template is the blog archive.

Best practices

• Decide what is broken from field data; work out why from lab data.
• Fix by template, not by URL, since one template covers thousands of pages.
• Full-page caching first, then a CDN, then image work.
• Explicit width and height on every image in theme markup.
• fetchpriority="high" on the LCP image and lazy loading on nothing above the fold.
• Dequeue plugin assets on pages that do not use them.
• Review third-party tags on a schedule and delete the ones nobody owns.
• Self-host fonts with font-display: swap.
• Real user monitoring so you are not waiting a month for feedback.
• Record field numbers before and after every significant change.

FAQ

Why is my PageSpeed score 95 but Search Console says I’m failing?

They measure different things. The score is a simulated load on your connection; the assessment is real Chrome users at the 75th percentile over 28 days. Read the field data section at the top of PageSpeed Insights, not the score.

How long before a fix shows up?

The data window is 28 days and rolls daily, so improvement appears gradually and takes about a month to fully reflect. Real user monitoring gives you same-day feedback if you cannot wait.

Will a caching plugin fix Core Web Vitals?

It will help LCP substantially, because TTFB is a floor under it. It does very little for INP, which is about JavaScript execution, and nothing for CLS. Caching is a strong first move and not a complete answer.

What happened to FID?

INP replaced it in March 2024 and FID is retired. Any guide still listing it predates the change, which is a useful signal about the rest of its advice.

Do I need to switch themes?

Sometimes, and it is a bigger project than it looks. A heavy multipurpose theme loading a page builder, a slider library and an icon set on every request is fighting you. Measure first, because a theme swap on a site with hundreds of pages is rarely the cheapest route to passing.

Does passing actually help rankings?

Core Web Vitals are a ranking signal among many, and content relevance dominates. The reliable win is on the user side: faster pages convert better and get abandoned less. Treat ranking as a bonus rather than the business case.

The one thing to remember

You cannot fix what you are not measuring, and the tool most people measure with cannot see the metric most people are failing. Lighthouse is a debugger. The Chrome User Experience Report is the exam.

So open Search Console before you open PageSpeed Insights, find out which of the three is actually red, and fix that one. Then wait a month before deciding whether it worked, because the measurement takes longer than the work.

Site failing and not sure why?

Most of the WordPress sites I get sent have already had a fortnight thrown at the wrong metric. Work I take on:

• Diagnosing which Core Web Vital is actually failing, for which templates, from field data rather than a score.
• LCP work: caching and TTFB, image priority and formats, render-blocking CSS, CDN configuration.
• INP work, which is mostly JavaScript archaeology: dequeuing plugin assets by page, auditing third-party tags, breaking up long tasks.
• CLS fixes across templates, including ads, embeds, fonts and consent banners.
• Setting up real user monitoring so you get feedback in a day instead of a month.
• Untangling sites running two or three overlapping optimisation plugins.

Send me your Search Console Core Web Vitals report and a URL from a failing template, and I will tell you what is actually wrong.

The post A 100 Score and a Failing Report: Fixing Core Web Vitals on a Real WordPress Site appeared first on John Nessime.