Search Console Core Web Vitals "LCP issue: longer than 4s (mobile)"
Real mobile visitors saw the page's largest element finish painting after 4 seconds for the slowest quarter of loads, failing LCP.
What you see
Why URLs aren't considered good LCP issue: longer than 4s (mobile) 12 URLs affected — Poor
What’s actually happening
The Core Web Vitals report flags a group of mobile URLs with "LCP issue: longer than 4s," and they sit in the red Poor bucket. This is field data from Chrome users, not a lab score, so it reflects what people on real phones and real networks actually got. The 4s figure is the 75th percentile — a quarter of loads were that slow or slower. Because the page's largest element (usually the hero image, a headline, or a big text block) renders late, the page feels broken even after it technically loads.
Common causes
- Slow server response — high TTFB from unoptimized backend, no caching, or a distant origin pushes every downstream milestone back, LCP included
- Render-blocking CSS and synchronous JS in the <head> delay first paint, so the LCP element can't draw until they finish
- A heavy or late-discovered hero image: no width/height, no priority hint, lazy-loaded above the fold, or served as an unoptimized JPEG/PNG instead of WebP/AVIF
- Web fonts blocking text render (no font-display: swap), so a text LCP element waits on the font download
- Client-side rendering frameworks that paint nothing until JS hydrates, making the LCP element appear only after a large bundle parses
How to fix it
- Identify the actual LCP element firstOpen the page in Chrome DevTools, Performance panel, and look at the Timings track for the LCP marker — it names the exact node. Don't optimize the wrong image. PSI's Lab Data also labels the LCP element under diagnostics.
- Cut TTFBMeasure server response with curl -w "%{time_starttransfer}" or the Network panel. Add full-page or edge caching, put a CDN in front of the origin, and fix slow database queries or cold serverless starts. Anything over ~600ms server time is eating your LCP budget.
- Make the LCP image load immediatelyAdd fetchpriority="high" to the hero <img>, remove loading="lazy" from anything above the fold, set explicit width/height, serve AVIF/WebP, and add a <link rel="preload"> for it. For background-image heroes, preload the image URL since CSS-referenced images are discovered late.
- Unblock the critical render pathInline critical CSS, defer non-critical stylesheets, and move non-essential scripts to defer or async. Add font-display: swap and preload the primary web font so text-based LCP isn't gated on a font fetch.
- Validate, then wait for the field data to catch upConfirm the fix in lab (PSI/Lighthouse) and in the field via the CrUX History API. Search Console field data lags real-user behavior by about 28 days, so after deploying, use "Validate Fix" and expect the report to stay Poor for several weeks before it moves.
Stop it recurring
Set a performance budget that caps LCP element load and TTFB, and test it on throttled mobile in CI before every release.