What this check flags
This check fires when the Largest Contentful Paint element on your page finishes rendering later than Google's threshold, meaning the biggest thing above the fold, usually your hero image or headline, shows up too late. Google grades LCP as good at 2.5 seconds or under, needs-improvement between 2.5 and 4 seconds, and poor above 4 seconds, and a poor LCP drags down the whole Core Web Vitals assessment that feeds the ranking signal.
The LCP element is not what most people think
LCP measures the render time of the single largest content element visible in the viewport, not the whole page and not the last thing to load. On a blog post it is often the featured image; on a SaaS landing page it is frequently a big H1 or a background image applied through CSS. Chrome picks the winner as the page paints, and it can change mid-load. Before you fix anything, you have to know which element Chrome is actually clocking, because optimizing the wrong asset is a guaranteed way to burn an afternoon and move the number by nothing.
A real example, and the fix
Here is a classic offender. The hero image sits in the HTML but nothing tells the browser it matters, so it queues behind the stylesheet, the web font, and three analytics scripts:
<!-- Before: browser discovers this late, loads it lazily -->
<img src="/hero.jpg" loading="lazy" alt="Product hero">Two problems. First, loading="lazy" on an above-the-fold image is self-sabotage, it tells the browser to defer the exact thing LCP is timing. Second, the browser has no idea this image is high priority until it parses the whole tag. Fix both, and add a preload so discovery happens in the first bytes of HTML:
<!-- In <head>: discovered immediately -->
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">
<!-- In <body>: eager, high priority, correctly sized -->
<img src="/hero.avif" fetchpriority="high" width="1200" height="630"
alt="Product hero" decoding="async">The fetchpriority="high" hint plus the preload moves the hero to the front of the queue, and swapping the JPEG for AVIF typically cuts the byte count by half or more. On a real site this combination routinely pulls LCP from the high 3-second range down under 2.5s without touching the server.
The four things that make LCP slow
| Cause | What you'll see in the trace | Primary lever |
|---|---|---|
| Slow server response | Long TTFB before anything paints | Cache HTML, upgrade host, edge CDN |
| Render-blocking resources | Big gap between HTML arrival and first paint | Defer JS, inline critical CSS |
| Heavy or late-discovered image | Image request starts late or downloads slowly | Preload, fetchpriority, AVIF/WebP |
| Client-side rendering | Blank HTML, LCP waits on JS to build the DOM | SSR or static render the hero |
How to detect it
- PageSpeed Insights. Run the URL, then open the diagnostics and expand "Largest Contentful Paint element". It names the exact node and gives you the four-phase breakdown: TTFB, load delay, load time, render delay. That breakdown tells you which lever to pull, see the PageSpeed Insights reference for reading it.
- Chrome DevTools. Open the Performance panel, record a load with 4x CPU throttle and Slow 4G, and look for the LCP marker on the timeline. Hover it to see the element and the timestamp, then trace backward to find what blocked it.
- CrUX and field data. Lab numbers are diagnostic; the ranking signal is field data. Check your CrUX LCP at the 75th percentile, and read field vs lab data so you don't chase a lab win that never shows up for real users.
- Search Console. The Core Web Vitals report groups failing URLs by issue type. Filter for "LCP issue: longer than 2.5s" to see how many templates share the same root cause.
How to fix it, in priority order
- Preload and prioritize the LCP image. Add the preload plus
fetchpriority="high", and never lazy-load anything above the fold. This is the single highest-leverage change on most sites. The preload key requests check covers the mechanics. - Shrink and modernize the image. Serve AVIF or WebP, size it to the actual container with
srcset, and strip metadata. A 1.4MB hero has no business being 1.4MB. - Clear the render-blockers. Defer non-critical JavaScript and inline the critical CSS so first paint doesn't wait on a stylesheet round trip, walked through in eliminate render-blocking resources.
- Fix the server. If TTFB is the biggest phase, no front-end trick will save you; cache the HTML and put a CDN in front, per TTFB too slow.
For the full picture, the LCP complete guide and the improve LCP walkthrough go deeper than a check page can.
FAQ
My LCP is fine in Lighthouse but Search Console still says it's slow. Why?
Lighthouse is a single lab run on a fixed device profile. Search Console reports field data from real Chrome users at the 75th percentile, which includes slow phones and bad networks you never test on. Trust the field number, it's the one Google ranks with.
Does lazy-loading images help or hurt LCP?
Below the fold it helps by saving bandwidth. On the LCP element itself it hurts, badly, because you're deferring the exact thing being measured. Lazy-load everything except what's visible on first paint.
Is text or an image better as the LCP element?
Text renders faster because there's no separate download, so a text LCP is usually easier to get under 2.5s. But a well-optimized preloaded image is perfectly fine, don't restructure your page just to avoid a hero image.
Will a faster LCP actually move my rankings?
Core Web Vitals is a real but modest signal, and it's a tiebreaker, not a magic wand. The bigger win is usually engagement: a hero that paints in 2 seconds instead of 5 keeps people from bouncing before your page even shows up.
Claude Vincent is a technical SEO consultant focused on crawlability, rendering, and AI-search visibility. He writes the field guides and case studies at SEO ProCheck, with a bias toward the durable, unglamorous work that decides whether search engines and AI answer engines can actually read and cite a site.
About SEO ProCheck
Technical SEO consulting and GEO strategy with 20 years of enterprise experience. Case studies, resources, and tools for search and AI visibility.
Work With Me
Technical SEO audits, GEO strategy, site migrations, and international SEO. Hourly consulting for teams who need hands-on support, not just reports.
Subscribe to our newsletter!
