Core Web Vitals are three numbers Google collects from real Chrome users about how a page feels to load and use. They matter for two reasons: they are a ranking signal, and — the bigger one — they measure the exact things that make visitors leave before your page has said anything. Core Web Vitals for WordPress are passable without heroics if you know what each one is actually measuring.
This article explains the three metrics in plain terms, the thresholds, where to read your real numbers, and the WordPress-specific causes behind each failure. It is the “why” behind the speed optimization checklist and the Elementor fixes.
The three metrics, in plain terms
| Metric | What it measures | Good | Poor |
|---|---|---|---|
| LCP — Largest Contentful Paint | How long until the biggest thing above the fold (hero image, headline) is on screen | ≤ 2.5 s | > 4.0 s |
| INP — Interaction to Next Paint | How long the page takes to respond visibly after you tap or click, across the whole visit | ≤ 200 ms | > 500 ms |
| CLS — Cumulative Layout Shift | How much the page jumps around while loading | ≤ 0.1 | > 0.25 |
Google grades each page at the 75th percentile of real visits: three out of four visitors must have a good experience. One fast test on your office Wi-Fi tells you nothing about the visitor on a mid-range phone on a train.
Where to read your real numbers
- Google Search Console → Core Web Vitals report. Groups your URLs into good / needs improvement / poor, on mobile and desktop, from real users. This is the report that affects search.
- PageSpeed Insights. Enter a URL; the top section (“Discover what your real users are experiencing”) is field data for that page or the whole origin if the page lacks traffic. The bottom section is a lab test with diagnostics — use it to find causes, not to declare victory.
- Chrome DevTools → Performance panel. For the hands-on diagnosis: which element is the LCP, which script blocked the tap, which element shifted.
LCP: why the biggest thing arrives late
On most WordPress business sites the LCP element is the hero image or the headline. Common causes and fixes:
- Slow server response (TTFB over ~600 ms). Cheap shared hosting, no page cache, or a cache that misses. Fix: server-level page caching that actually hits; better hosting if TTFB stays high on cached pages.
- Hero image too large or the wrong format. A 2 MB PNG where a 120 KB WebP would do. Fix: resize to the display size, convert to WebP, and preload it.
- Hero image lazy-loaded. WordPress or a plugin adds
loading="lazy"to everything, including the one image that should load first. Fix: eager loading andfetchpriority="high"on the LCP image only. - Hero as a CSS background. Background images are discovered late by the browser. Fix: use an
<img>for the LCP image, or preload the background file. - Render-blocking CSS and fonts. Large stylesheets and third-party fonts delay the first paint. Fix: fewer stylesheets, self-hosted fonts with
font-display: swap, preload the heading font. - Headline text waiting on a web font. If the LCP element is text, a late font delays it. Fix: preload the font; keep fallback metrics similar.
INP: why taps feel sluggish
INP replaced First Input Delay in 2024 and it is stricter: it looks at every interaction during the visit, not just the first. On WordPress, the causes are almost always JavaScript:
- Too much script on the main thread. Page-builder addon packs, sliders, animation libraries, multiple pixels, chat widgets, heatmaps. Each one runs when the page loads and competes with your tap. Fix: remove what you do not use; defer or delay the rest until after interaction.
- Heavy event handlers. A mega-menu or filter that rebuilds the DOM on every click. Fix: usually a plugin or theme setting; sometimes replacing the widget.
- Third-party embeds. YouTube, maps, social feeds. Fix: click-to-load facades.
- Long tasks from tracking. Consent tools and tag managers loading a dozen tags at once. Fix: fire non-essential tags on interaction or after load.
Diagnose with DevTools: record a session, tap the slow element, and look for long tasks (over 50 ms) around the tap. The script named in the long task is the culprit.
CLS: why the page jumps
Layout shift is the “it loaded, then everything moved” effect. Visitors tap the wrong thing; Google counts it. WordPress causes:
- Images without dimensions. The browser does not know how tall an image will be until it arrives, so text jumps down. Fix: width and height attributes on every image (media-library images get them automatically; hard-coded ones often do not).
- Web fonts swapping late. Text renders in a fallback font and reflows when the real font lands. Fix: preload the main fonts; choose fallbacks with similar metrics.
- Content injected above existing content. Cookie banners, notification bars, ads. Fix: reserve the space or place them at the bottom / as overlays.
- Elements that render after JavaScript. Accordions expanding, sliders initialising, “reveal on load” animations. Fix: set the initial state in CSS so nothing changes size when the script runs. Elementor’s accordions and animations are frequent offenders.
- Header height changing. A fixed header that grows when a font or logo loads pushes the whole page. Fix: fixed dimensions on the header and its logo.
A sensible order of work
- Read the Search Console report. Fix the metric marked “poor” first; “needs improvement” second.
- For LCP: caching and hosting, then the hero image, then fonts.
- For CLS: image dimensions, then fonts, then late-rendering elements.
- For INP: remove scripts, then defer scripts, then replace heavy widgets.
- Re-test in the lab immediately; check the field data after 28 days, because that is how long the window is.
Field data lags. A fix you ship today shows fully in the Core Web Vitals report about a month later. Do not keep changing things every week waiting for the number to move; fix, verify in the lab, wait.
What “passing” is worth
Honestly: a modest ranking help, and a real conversion help. Google has said the page experience signals are a tie-breaker rather than a headline factor. But the same fixes — a hero that appears in two seconds, a page that does not jump, buttons that respond instantly — are what keep visitors from leaving, and that shows up in enquiries long before it shows up in rankings. Passing is worth doing because it is a proxy for a site that works.
Further reading: Web Vitals (web.dev) · Google Search Console.
FAQ
Do Core Web Vitals affect Google rankings?
They are part of Google’s page experience signals. They are a lighter factor than content and links, and a tie-breaker between otherwise similar pages, but a failing site is at a disadvantage and, more importantly, converts worse.
What is a good LCP score?
2.5 seconds or less at the 75th percentile of real visitors. 2.5 to 4 seconds needs improvement; over 4 seconds is poor.
Why does my lab score differ from the field data?
Lab tests run once on a simulated device and connection. Field data comes from real Chrome users over 28 days on their own devices. Optimise for the field numbers; use lab tests to diagnose.
Which Core Web Vital is hardest to fix on WordPress?
Usually INP, because it comes from JavaScript — page builders, addons, chat widgets, tracking — and fixing it means removing or deferring scripts rather than tweaking a setting.
Failing a metric and not sure which of the causes above is yours? Request a free speed audit — I will name the element, the script or the image responsible, with numbers, before any work starts.
