Poor LCP in field data (p75 > 4 s)
cwv_lcp_poorShort answer
Largest Contentful Paint measures when the biggest visible element (usually the hero image or the main heading) finishes rendering. For this site or page, the 75th percentile of real Chrome users is above 4 seconds, which is Google's "poor" threshold (good is ≤ 2.5 s). The largest content arrives after 4 seconds. Users leave while they wait, and the page experience signal is negative too. Fix it by finding the LCP element and removing everything that delays it: slow server response, render-blocking CSS, a late-discovered or oversized image.
Why it matters
LCP is one of the three Core Web Vitals and the one most often in the "poor" range. Google uses field data (CrUX) for its page-experience signal, so lab improvements only count once real users see them. Beyond search, every second of LCP measurably increases bounce rate.
How Glimana detects it
Glimana reads field data from the Chrome UX Report (CrUX) for the origin and, where available, for individual URLs, and fires the rule when lcp_p75 is above 4,000 ms. The evidence shows the measured p75; the Speed page shows the full distribution (good / needs improvement / poor) and the lab Lighthouse run that points to the specific element.
Note
The thresholds are Google's: LCP good ≤ 2.5 s, poor > 4 s. Glimana reports only the "poor" state as an issue; "needs improvement" (2.5–4 s) is shown on the Speed page without creating a task.
How to fix it
- Find the affected pages in Glimana. Open Speed in the panel. The field panel shows the p75 and the good / needs improvement / poor split; the Lighthouse run under it names the element, resource or script responsible. The task under Tasks links to the same page.
-
Apply the fix on your platform.
LCP has four phases; the Lighthouse run on the Speed page shows which one dominates.
- TTFB. If the server itself takes more than 800 ms, start with the slow server response guide. Nothing else helps until the HTML arrives.
- Resource load delay. The LCP image must be discoverable in the HTML immediately: a plain
<img src>(not lazy-loaded, not a CSS background, not injected by JavaScript). Addfetchpriority="high"to it and, if it is a background or in a carousel,<link rel="preload" as="image">. - Resource load time. Serve the image in a modern format (AVIF/WebP), at the displayed size, from a CDN with long cache headers.
- Render delay. Remove render-blocking CSS and synchronous scripts from
<head>; inline the critical CSS and defer the rest; usefont-display: swapor preload the heading font.
Make sure the hero image is not lazy-loaded (WordPress skips
loading="lazy"on the first image, but many themes and plugins add it back). Use WP Rocket / Perfmatters to exclude the LCP image from lazy loading and setfetchpriority. Serve WebP/AVIF through your image plugin or CDN, and enable critical CSS.In Dawn-based themes the hero is a section image; set its size to match the displayed width, keep "lazy load" off for the first section only, and use
image_tagwithpreload: true(Online Store 2.0 supports it). Remove apps that inject render-blocking scripts.Preload the LCP resource, use
fetchpriority="high", serve responsivesrcsetwith modern formats, and ensure the server responds fast (edge caching). Avoid client-side rendering for above-the-fold content; SSR or static generation keeps the LCP element in the initial HTML. -
Publish and clear caches. Deploy, purge the CDN, then run Lighthouse again from the Speed page (or PageSpeed Insights) to confirm the lab number moved. Field data lags: CrUX reflects the change over the following 28 days.
- Verify in Glimana. Open the task under Tasks and click Mark as done once you have confirmed the fix yourself; this rule is not auto-closed by a crawl because field data lags by about 28 days. Mark it done when Lighthouse confirms the improvement; the Speed page will show the field p75 catching up over the following weeks, and the rule stops firing once the CrUX p75 is below 4 s.
How the fix is verified
This rule is verified manually: field data lags by about 28 days, so Glimana does not auto-close the task. Mark it done from the task when Lighthouse confirms the improvement; the Speed page will show the field p75 catching up over the following weeks, and the rule stops firing once the CrUX p75 is below 4 s.
FAQ
Lighthouse says my LCP is 1.8 s but Glimana says poor. Why?
Lighthouse is a lab test on a fast connection from one location; CrUX is real users on real devices, weighted toward whatever your audience uses. The field number is the one Google uses. Look at the mobile share of your traffic and test on a throttled connection.
Can I fix LCP for one page only?
Yes, but the page-experience signal uses URL-level data when there is enough traffic and origin-level data otherwise. For most sites the template (hero image, theme CSS) is what matters, so fixing it once fixes the origin.