What each metric actually measures

Core Web Vitals replaced vague notions of “fast” with three specific, user-centric measurements. Largest Contentful Paint (LCP) records the time from navigation start until the largest visible element — usually a hero image, a background image, or a large block of text — is painted to the screen. It is a proxy for “when did the main content become visible and usable.” Interaction to Next Paint (INP), which replaced First Input Delay in March 2024, measures the latency of every interaction across the full page lifespan and reports something close to the worst typical case. It captures the full journey from user input to the browser painting the next frame, which includes input delay, processing time and presentation delay. Cumulative Layout Shift (CLS) measures unexpected visual movement of elements after they have already rendered, weighted by how much of the viewport moved and how far.

None of these metrics measure “speed” in a single number. They measure specific, observable frustrations: waiting for content, waiting for a click to do something, and having the page jump around while you are trying to read or tap. That framing matters because it changes how you diagnose problems — you are chasing user-perceived friction, not a lab score.

Field data versus lab data, and why they disagree

Lab data comes from a single simulated run in a tool such as Lighthouse or PageSpeed Insights’ lab section, WebPageTest, or a local DevTools trace. It is reproducible, deterministic within a margin, and useful for debugging a specific rendering path. Field data comes from the Chrome User Experience Report (CrUX), which aggregates anonymised, real-user measurements from Chrome users who have opted into usage statistics, over a rolling 28-day window.

The two disagree constantly, and both are right for what they measure. A page can score perfectly in Lighthouse on a fast desktop connection with an empty cache, and still fail CLS or INP in the field because real users are on mid-range Android phones, throttled mobile networks, ad blockers, browser extensions, or with a warm cache serving stale layout before a font swap kicks the text down a line. Google’s ranking signal comes from field data (CrUX), specifically the 75th percentile of visits at the origin or URL level. Lab data is a diagnostic tool to reproduce and fix what field data tells you is broken; it is not the thing being ranked.

Practically: never optimise purely to a green Lighthouse score. Pull the actual CrUX numbers for the URL and, where volume is too low for URL-level data, the origin-level numbers, then reproduce the failure locally with throttled CPU and network before you start changing code.

Real causes of poor LCP

Real causes of poor INP

INP problems are almost always caused by the main thread being busy when the user tries to interact with it. The three recurring patterns are long tasks (any JavaScript execution block over 50ms that cannot be interrupted to handle input), hydration cost in JavaScript-framework-driven sites where the whole interactive layer rebuilds on load, and third-party scripts — tag managers, chat widgets, ad tech, A/B testing snippets — that inject their own event listeners and timers competing for the same thread. A single heavy analytics or personalisation script initialising on load can single-handedly push INP from “good” to “needs improvement” on an otherwise well-built page.

On WordPress specifically, page builders that generate deeply nested DOM structures with inline style recalculation, and plugins that attach click handlers to every element on the page rather than delegating events, are common contributors that rarely show up until you profile actual interactions in the field.

Real causes of poor CLS

CLS is almost always one of four things: images or embeds without explicit width and height attributes (or a CSS aspect-ratio), so the browser cannot reserve space before the asset loads; ads, cookie banners or subscription prompts injected into the flow of the page rather than into a reserved slot; web fonts that swap in with different metrics than the fallback, shifting every line of text below the fold; and dynamically injected content, such as related-posts widgets or personalised banners, that pushes existing content down after the user has started reading.

Animated diagnosis: waterfall and gauges

Diagnosis workflow

Prioritised fix list

WordPress-specific fixes

Most WordPress performance problems trace back to a handful of repeat offenders. Page caching (Rank Math’s own stack pairs well with a caching plugin such as WP Rocket or a server-level solution like Nginx FastCGI cache) removes PHP execution time from repeat visits and is the single highest-leverage TTFB fix. Object caching via Redis or Memcached matters even more on sites with heavy database queries, such as WooCommerce catalogues or membership sites. Serving AVIF or WebP through a plugin or CDN image service, with correctly sized responsive srcsets, routinely cuts LCP by a full second or more on image-heavy pages. Script deferral, whether through a caching plugin’s built-in delay-JS feature or manual defer/async attributes, keeps third-party tags from blocking the main thread during initial load and interaction. Finally, plugin bloat is worth auditing directly: every additional plugin that enqueues its own CSS and JS on every page, whether it is used on that page or not, adds parse and execution cost that shows up as long tasks. A quarterly plugin audit that removes unused functionality, and conditional loading for the plugins you keep, is one of the more underrated INP fixes on WordPress specifically.

How speed relates to rankings and conversion

Core Web Vitals are one input into the page experience signal, which Google has described as a tie-breaker among pages of otherwise comparable relevance and quality, not a dominant ranking factor on its own. A page with thin or poorly matched content will not outrank a strong competitor purely by passing its Core Web Vitals thresholds. That said, the practical value of fixing these metrics rarely comes from the ranking signal alone. Slow LCP and high INP correlate strongly with bounce rate and abandoned form submissions, and layout shift directly causes mis-clicks on buttons and links, which erodes conversion rate independently of search visibility. Treat Core Web Vitals work as a conversion and retention project that also happens to remove a minor ranking headwind, and budget it accordingly rather than expecting it alone to move rankings.

Frequently asked questions