Largest Contentful Paint: The Metric That Changes Conversions

What you need to know

• LCP is the Core Web Vital with the strongest correlation to conversion rate. Improving it has business value beyond SEO rankings.
• The LCP element on most marketing and product pages is the hero image or main headline. Identify yours with Lighthouse before optimizing.
• Never lazy load the LCP element. Add fetchpriority="high" to the LCP image to tell the browser to prioritize it.
• Server response time is the LCP bottleneck that developers underestimate. A slow Time to First Byte delays everything that follows, including the LCP element.
• LCP from field data (real users) and lab data (Lighthouse) often differ significantly. Mobile users on slower connections frequently have LCP scores 2 to 3 times worse than desktop lab data suggests.

The core argument

LCP fails for four distinct reasons, and each requires a different fix. The first is server response time: if the Time to First Byte (TTFB) is above 800 milliseconds, LCP cannot be good regardless of how optimized the rest of the page is. The page cannot finish painting a large element before the HTML has even arrived. Fixing slow TTFB requires either improving the speed of server side rendering, adding caching at the CDN or application layer, or moving to a static generation approach for content that does not change per request.

The second cause is resources that block rendering. A <link rel="stylesheet"> in the <head> blocks the browser from rendering any HTML until the CSS file is downloaded and parsed. A synchronous <script> does the same. When these resources are on a slow origin or are large, they delay the LCP element by hundreds of milliseconds. The fix is to defer non critical CSS with preloading patterns, add async or defer to scripts that do not need to run before the page renders, and inline the critical CSS that is needed to render everything above the fold.

The third cause is the LCP resource itself: the hero image is large, unoptimized, or served from a slow origin without CDN caching. A 1MB JPEG hero image on a mid range mobile connection takes three to four seconds to download by itself. Compressing it to AVIF or WebP, serving it from a CDN edge, and sizing it correctly for the viewport eliminates this bottleneck. The fourth cause is rendering on the client: the LCP element is rendered by JavaScript rather than being in the initial HTML. This means the browser must download, parse, and execute JavaScript before the LCP element appears in the DOM. Rendering on the server, or static generation of the content above the fold, is the structural fix. For pages I have worked on through Expert Tutorials and other client projects, moving the hero section from client rendered to server rendered typically reduces LCP by 1.5 to 2.5 seconds on first load.

Common mistakes

1. Lazy loading the hero image. This is the most common LCP mistake. Add loading="lazy" only to images that are below the fold. The LCP image should have fetchpriority="high" and no lazy loading attribute.

2. Not preloading the LCP image when it is in CSS. Background images set via CSS are not visible to the browser's preload scanner. Use <link rel="preload"> with the as="image" attribute to tell the browser about the LCP resource early.

3. Serving the LCP image in JPEG without a modern format. A JPEG hero image that could be 60 to 70 percent smaller as AVIF is a wasted optimization opportunity. Use a CDN or Next.js Image to serve AVIF with JPEG fallback automatically.

4. Not measuring LCP on mobile with a slow connection. Desktop Lighthouse scores often do not reflect the mobile user experience. Run Lighthouse with mobile settings and CPU throttling to see a more realistic picture of what users on a slow connection experience.

5. Optimizing LCP on the homepage but not on landing pages. LCP matters on every high traffic page, not just the homepage. The pages where visitors first arrive, including ad landing pages and blog posts, should all be audited.

Where to start

1. Identify your LCP element on your highest traffic page. Run Lighthouse and look at the LCP metric and the highlighted element. Note the type (image or text), the size, and the load time.

2. Remove lazy loading from the LCP element and add fetchpriority="high". This single change is often the fix with the best return on effort for pages where the LCP element is an image. Check the before and after Lighthouse score.

3. Measure your Time to First Byte. Use WebPageTest or PageSpeed Insights field data to see the TTFB for your main pages. If it is above 600 milliseconds consistently, address server or CDN caching before optimizing individual resources.

FAQ

Frequently asked

• What element is typically the LCP candidate on a web page?
• What causes slow LCP?
• How does lazy loading affect LCP?
• What is fetchpriority and how does it help LCP?
• How much does LCP improvement actually affect conversions?

Author

Why you should skip the agency and hire me instead

Agencies mark up engineering work to cover the layers of people between you and the person actually writing the code. I am Yashveer Singh, founder of Yashveer Labs, and I do the work directly. No project manager, no account manager, no overhead. The engineer you talk to is the engineer who writes the code. That changes the math on price, speed, and quality at the same time. If that sounds like the shape of project you have, we should talk.

Start the conversation See the work DM on Instagram