Core Web Vitals need improvement in field data

SeverityLow

ScopeWhole site

EffortMedium

Verified byManually

Rule keycwv_needs_improvement

Short answer

Chrome’s real-user data (CrUX, phones, 75th percentile) puts at least one Core Web Vital in the “needs improvement” band: LCP between 2.5 and 4 s, INP between 200 and 500 ms, or CLS between 0.1 and 0.25. Search Console counts a URL as passing only when all three are good, so these pages show as not passing even though nothing is “poor”.

Why it matters

Core Web Vitals are part of Google’s page experience signals. Their effect on ranking is small compared with relevance, but the metrics measure what visitors actually feel: how fast the main content appears, how quickly the page reacts and whether it jumps while loading. A metric in the middle band is the cheapest place to win, because a few targeted changes usually move it to good.

How Glimana detects it

Glimana reads the latest origin-level CrUX record for phones that it stores daily. For each of LCP, INP and CLS it checks whether the 75th percentile is above the “good” threshold and at or below the “poor” threshold. Metrics above the poor threshold are reported by the separate “Poor LCP / INP / CLS” rules instead. The evidence lists the metrics in the middle band with their values.

How to fix it

Find the affected pages in Glimana. Open Issues › Core Web Vitals need improvement in field data. Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
Apply the fix on your platform.

Work on the metric listed in the evidence. LCP: make the main image or heading arrive early (no lazy-loading on it, fetchpriority="high", compressed modern format, fast server response). INP: break up long JavaScript tasks and defer third-party scripts. CLS: give images, embeds and ad slots fixed dimensions and avoid inserting content above what is already shown.

WordPressShopifyCustom code

Use a caching plugin with page caching and critical CSS, serve images in WebP/AVIF with width and height set, and exclude the first image from lazy-loading. Audit plugins that add scripts on every page (sliders, chat widgets, page builders) — they are the usual INP cost.

Theme apps and tracking scripts are the most common cause of slow INP; remove apps you no longer use, since their code often stays in the theme. Use Shopify’s image_url with explicit widths so images are resized, and reserve space for app blocks that load later.

Measure with the web-vitals library or Chrome DevTools’ Performance panel on a throttled phone profile. Preload the LCP resource, split long tasks with scheduler.yield() or setTimeout, and set aspect-ratio or dimensions on every media element.
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with curl -s https://your-domain/page | grep -i '<title\|canonical\|robots' that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached.
Verify in Glimana. Field data is a 28-day rolling window, so improvements show gradually. When you have shipped the changes, mark the task done; Glimana keeps reading the daily CrUX record and the issue closes when every metric is back in the good band.

How the fix is verified

Verification is manual: CrUX is a 28-day rolling average, so the issue closes on its own once the daily record shows all three metrics as good.