Why Your LCP Is Slow
LCP is a race between the browser requesting your page and that one largest element finishing its render. Almost every slow LCP traces back to one of four things standing in that race's way:
- Slow Time to First Byte.If the server takes 2 seconds just to respond, LCP can't start the clock any earlier than that - everything downstream inherits the delay.
- An unoptimized hero image. A 4MB PNG served at display size instead of a compressed, correctly-sized format is the single most common cause we see.
- Render-blocking CSS or JS in
<head>.The browser can't paint anything, including the LCP element, until it finishes downloading and parsing render-blocking resources. - Late resource discovery. If the LCP image is only referenced deep inside a CSS
background-imageor loaded by JavaScript after hydration, the browser doesn't even know to start fetching it until much later than it could have.
How to Identify Your LCP Element
Guessing which element is your LCP is unreliable - it changes with viewport size and content. Scanverra's Website Audit runs a real Lighthouse pass on both a desktop profile and a 375px mobile viewport and reports the LCP value and timing directly from that run, not an estimate, so you're looking at the same metric Google's field data eventually reflects, not a proxy for it.
In Chrome DevTools you can also open the Performance panel, record a page load, and look for the "LCP" marker in the timings track - it highlights the exact element in the rendered page when you hover it.
How to Fix It
1. Preload the actual LCP resource
If the browser can only discover your hero image after parsing CSS or running JS, tell it about the image up front instead:
1export default function RootLayout() {
2 return (
3 <html lang="en">
4 <head>
5 <link
6 rel="preload"
7 as="image"
8 href="/hero.webp"
9 fetchPriority="high"
10 />
11 </head>
12 <body>{/* ... */}</body>
13 </html>
14 );
15}2. Mark the LCP image as high priority
If you're rendering the hero image through a component-level image tag, mark it as the priority resource so it isn't lazy-loaded and competes first for bandwidth:
1<img
2 src="/hero.webp"
3 alt="Product dashboard overview"
4 width={1200}
5 height={630}
6 fetchPriority="high"
7 loading="eager"
8/>3. Compress and correctly size the image itself
Serve AVIF or WebP instead of PNG/JPEG where the browser supports it, and never ship an image larger than the largest size it will actually be displayed at - a 3000px-wide source image scaled down with CSS still costs the full download.
4. Get TTFB out of the way first
Preloading a slow-loading image doesn't fix a slow server. If TTFB is a meaningful chunk of your LCP budget, fix that first - see the TTFB guide below - since every other LCP optimization is capped by how late the browser can even start.
5. Remove render-blocking resources from the critical path
Defer or async non-critical JavaScript, inline the small amount of CSS needed for above-the-fold content, and load the rest of your stylesheet without blocking first paint.
How Scanverra Detects LCP Issues
Scanverra's performance checks run a genuine Lighthouse audit against your live URL on both desktop and a 375px mobile viewport, and report the real LCP timing from that run alongside the other Core Web Vitals - this isn't a synthetic estimate or a cached third-party number.