Core Web Vitals have changed twice in the last few years, and most advice you find online is still written for the old version. First Input Delay was retired in March 2024 and replaced by Interaction to Next Paint. Largest Contentful Paint and Cumulative Layout Shift are unchanged, but the tools measuring them and the thresholds Google treats as a pass have not moved, and most WordPress sites are still failing at least one of the three.

This is a field guide to what the three current metrics actually measure, which WordPress-specific problems cause each one to fail, and how to read your own data correctly, because the score you see in PageSpeed Insights and the score Google actually uses for ranking are not the same number.

What are the three Core Web Vitals, and what do they actually measure?

Each metric measures a different part of the visitor's experience: how long they wait to see something, how quickly the page responds when they act, and how much the layout jumps around while they are reading. Google scores a URL by the 75th percentile of real visitors over a rolling 28-day window, meaning three out of four visits have to meet the threshold for the page to pass.

Largest Contentful Paint (LCP)

LCP is the time from when the page starts loading to when the largest visible element, usually a hero image, a large heading, or a background image, finishes rendering. It is a proxy for "when does this page feel loaded" from the visitor's point of view. Good is 2.5 seconds or under. Needs improvement is 2.5 to 4 seconds. Poor is anything over 4 seconds.

Interaction to Next Paint (INP)

INP replaced FID as the official responsiveness metric in March 2024. It measures the time from any click, tap, or keypress on the page to the next frame the browser paints in response, and it looks at every interaction during the visit, not just the first one. Good is 200 milliseconds or under. Needs improvement is 200 to 500ms. Poor is anything over 500ms. This is the metric most WordPress sites fail, because it is the one most directly caused by JavaScript, and WordPress sites tend to carry a lot of it.

Cumulative Layout Shift (CLS)

CLS measures how much visible content moves around unexpectedly while the page loads, scored as a unitless number based on how much of the viewport shifted and how far. Good is 0.1 or under. Needs improvement is 0.1 to 0.25. Poor is anything over 0.25. This is the metric that produces the most visible, embarrassing failures: a button that moves right as someone taps it, or body text that jumps down a paragraph because an ad loaded late.

Metric

Good

Needs improvement

Poor

LCP

≤ 2.5s

2.5s – 4s

\> 4s

INP

≤ 200ms

200ms – 500ms

\> 500ms

CLS

≤ 0.1

0.1 – 0.25

\> 0.25

Why does a WordPress site fail LCP?

Three causes account for most LCP failures on WordPress specifically.

  1. 1.An unoptimized hero image. If the largest element is a full-width header image served at its original upload resolution instead of resized for the viewport, without a modern format like WebP or AVIF, and without fetchpriority="high" or a preload hint, it is very often the single largest contributor to a slow LCP.
  2. 2.Render-blocking CSS and fonts. Page builders and many themes enqueue several separate stylesheets and multiple font weights that all have to download and parse before the browser can paint anything, delaying LCP even when the hero image itself is fine.
  3. 3.Slow, uncached TTFB from PHP. LCP cannot start its clock until the HTML response begins arriving. A slow, uncached PHP response, from bloated plugins, an unindexed database query, or an underpowered host, pushes back everything downstream, including LCP, no matter how well the image itself is optimized.

Why does a WordPress site fail INP?

INP is almost always a JavaScript problem, and WordPress sites accumulate JavaScript from more sources than most platforms.

  1. 1.Heavy JavaScript from page builders and sliders. Visual page builders often ship a general-purpose runtime that parses and executes on every page, whether the page uses its features or not, and image sliders and carousels are frequent offenders because they run layout and animation logic on the main thread right as the page becomes interactive.
  2. 2.Third-party scripts. Chat widgets, analytics tags loaded through a tag manager, ad networks, and social embeds all add their own event listeners and periodic work to the main thread, and each one adds latency to every click or tap the visitor makes, not just once at load.
  3. 3.Unoptimized event handlers. A click handler that recalculates layout, queries the DOM repeatedly, or runs expensive work synchronously instead of breaking it into smaller chunks will block the next paint directly, which is exactly what INP measures.

The fix pattern is consistent across all three: reduce total JavaScript, defer what does not need to run immediately, and break up long tasks so the browser can respond to input between them instead of after them.

Why does a WordPress site fail CLS?

CLS failures are usually the easiest to diagnose because you can often see them happen.

  1. 1.Web fonts causing layout shift. When a custom font loads after the page has already painted with a fallback font, text can reflow into a different amount of space, shifting everything below it. Setting font-display: optional or preloading the font file reduces this.
  2. 2.Ads and embeds without reserved space. An ad slot, YouTube embed, or social widget that loads asynchronously and inserts itself into the page without a pre-set height pushes every element below it downward the moment it appears.
  3. 3.Images without dimensions. An <img> tag without width and height attributes gives the browser no space to reserve before the file downloads, so everything below the image jumps once it arrives. WordPress core has added these automatically to images inserted through the block editor since 5.5, but images set via CSS background or added by a theme template can still be missing them.

Why do field data and lab data disagree, and which one matters?

This is the single most common source of confusion in Core Web Vitals reporting, and it is worth being precise about, because the two numbers can genuinely point in opposite directions.

Lab data comes from a single, controlled run: PageSpeed Insights and Lighthouse simulate one visit on a fixed, throttled connection and a mid-range device profile, every time you run the test. It is reproducible and useful for debugging a specific change, but it is one simulated visit, not your real audience.

Field data comes from the Chrome User Experience Report (CrUX), an aggregate of real Chrome users who visited your site, opted into usage statistics, over a rolling 28-day window. This is what Search Console's Core Web Vitals report shows, and it is what Google actually uses as a ranking signal. It reflects your real visitors on their real phones, on their real connections, in their real countries.

For WordPress sites this gap is often wider than average, for two reasons. First, WordPress sites skew toward a broad, mixed audience, from fast fiber connections to slow rural mobile, so the 75th-percentile field number is pulled down by users a lab test never simulates. Second, caching plugins mean the page a lab tool fetches (often already cached and warm) can behave very differently from the page a first-time visitor gets on a cold cache or a personalized session, such as a logged-in WooCommerce customer with a cart. A store can show a green PageSpeed score and a red Search Console report at the same time, and the Search Console number is the one that reflects reality and the one Google uses.

Practical takeaway: use lab data (PageSpeed Insights, Lighthouse) to debug and verify a specific fix, because it is fast and reproducible. Use field data (Search Console, CrUX) to know your actual standing and to decide what to prioritize, because it is the number that reflects your real visitors and the number tied to ranking.

A prioritized action list

If you are starting from scratch, work in this order. Each step is cheap to verify before moving to the next.

  1. 1.Open Search Console's Core Web Vitals report and note which of the three metrics is actually failing at the 75th percentile. Do not guess from a single PageSpeed run.
  2. 2.If LCP is failing, check the hero image first: correct size, modern format, and a preload or fetchpriority hint. Then check uncached TTFB.
  3. 3.If INP is failing, audit third-party scripts and page-builder or slider JavaScript first. Removing or deferring unused scripts is usually the single change with the biggest effect.
  4. 4.If CLS is failing, check fonts, ad or embed containers, and any image missing width and height attributes, in that order.
  5. 5.After each change, wait for the field data to refresh (it is a rolling 28-day window, so early signal shows within days) rather than judging success from a single lab run.

How BoltAudit finds the specific cause on your site

Knowing the thresholds is one thing. Finding out which specific plugin, script, or image on your specific site is causing the failure is the harder part, and it is different for every site.

[BoltAudit](/) is a free, read-only WordPress performance audit plugin. The free Local Audit runs on your own server and checks the frontend, backend, database, and infrastructure factors that feed into LCP, INP, and CLS, and reports which specific asset or script is responsible, not just that a metric is failing. The paid AI Deep Audit goes further, ranking every fix it finds by estimated visitors recovered, with a confidence score and the evidence behind it, so you know which fix to make first. Read-only means it never writes to your database, toggles plugins, or edits files, so it is safe to run on a live site. Audits are located under Tools then BoltAudit in your WordPress admin.

Run it on your site

If you are staring at a red Core Web Vitals report and unsure which of the three metrics to tackle first, or which plugin is causing it, install BoltAudit free and run a Local Audit from Tools, then BoltAudit. It names the specific cause on your site instead of leaving you to guess from a generic checklist.

Key takeaways

  • The three current metrics are LCP (2.5s), INP (200ms), and CLS (0.1), scored at the 75th percentile of real visitors.
  • INP is the metric most WordPress sites fail, and it is almost always caused by JavaScript from page builders, sliders, or third-party scripts.
  • Field data (Search Console, CrUX) reflects your real visitors and is what ranking uses. Lab data (PageSpeed Insights) is one simulated run, useful for debugging, not for judging standing.

Frequently asked

Did INP replace FID for good?

Yes. Interaction to Next Paint replaced First Input Delay as the official Core Web Vital in March 2024, and that change is permanent. FID only measured the delay before the browser started handling the first interaction; INP measures the full time to the next paint across every interaction on the page, so it catches slow event handlers that FID never saw.

Why does my PageSpeed score not match Search Console?

PageSpeed Insights runs a single lab test on a simulated mid-range device and network. Search Console's Core Web Vitals report is field data (CrUX), aggregated from real visitors on real devices and connections over the past 28 days. A cached lab run can look fast while your actual mobile visitors on slower hardware experience something worse, and vice versa.

Do Core Web Vitals actually affect Google rankings?

Google has confirmed Core Web Vitals are a ranking signal, but a minor one relative to content relevance. Where they matter more directly is user behavior: sites that pass all three thresholds see measurably lower bounce rates and higher conversion, which indirectly supports rankings regardless of the direct ranking weight.

Can a caching plugin alone fix my Core Web Vitals?

Caching helps LCP and TTFB, but it cannot fix INP caused by heavy JavaScript running after the page loads, and it cannot fix CLS caused by web fonts or images without dimensions. Caching is one piece of a fix, not the whole fix.

Not sure which metric is costing you rankings? [The free Local Audit](/features) names it in about a minute.

Core Web Vitals LCP Performance

BA

BoltAudit team

Builders and operators who name the exact bottleneck slowing a WordPress site and rank every fix by visitors recovered.

[Talk to us](/contact)

Run BoltAudit on your site

Free plugin · 1 site · 3 audits per month · no credit card.

See plans →