A driver at the wheel with city lights blurred at dusk
Core Web Vitals

The Complete Guide to Optimizing Largest Contentful Paint (LCP)

WebPMagic Avatar WebPMagic Editorial
12 Min Read

Of the three Core Web Vitals, Largest Contentful Paint is the one sites fail most often — and the one with the most direct connection to images. LCP marks the moment your main content becomes visible, and Google wants that to happen within 2.5 seconds for real users. This guide is a practical, ordered checklist: find your LCP element, then work through the fixes that consistently move the needle.

Key Takeaways

  • A good LCP is 2.5 seconds or less, measured on real users in the field.
  • First, identify which element is actually your LCP — usually a hero image or large heading.
  • Right-size and modernize that asset, preload it, and never lazy-load it.
  • Then clear the path: reduce server response time, eliminate render-blocking resources, and lean on caching and a CDN.

First, What Counts as the LCP Element?

LCP times the render of the largest content element visible in the initial viewport. In practice that is almost always one of: a hero or banner image, a large background image, a video poster frame, or a big block of headline text. On content-heavy pages it is overwhelmingly an image — which is precisely why image work pays off so quickly here.

Step 1: Identify Your LCP Element

Do not guess. Open Chrome DevTools, run a Lighthouse report, and expand the "Largest Contentful Paint element" diagnostic — it points at the exact node. The Performance panel can also flag the LCP marker on its timeline. Knowing the element tells you which of the steps below actually apply: optimizing a hero image does nothing if your LCP is a block of text held up by a slow web font.

Step 2: Right-Size and Modernize the Image

If your LCP element is an image, this is the highest-impact fix. Two problems are nearly universal: the file is in an outdated format, and it is far larger in pixels than it will ever display. Convert it to WebP or AVIF, and export it at the actual rendered dimensions (with a responsive srcset for high-density screens). A hero that drops from a 2 MB JPEG to a 220 KB WebP can shave entire seconds off LCP on mobile.

Always set width and height

Explicit dimensions do double duty: they protect your Cumulative Layout Shift score and let the browser reserve and prioritize the image earlier. There is no downside to including them on every image.

Step 3: Preload It — and Never Lazy-Load It

This single mistake silently wrecks more LCP scores than any other: applying loading="lazy" to the hero image. Lazy loading deliberately defers a download, which is wonderful for off-screen images and disastrous for the one element Google is timing. Above-the-fold images must load eagerly.

You can go further and actively prioritize the LCP image. A preload hint tells the browser to fetch it immediately, before it has even finished parsing the rest of the page, and fetchpriority="high" bumps it to the front of the queue.

<!-- In the <head>: fetch the hero as early as possible -->
<link rel="preload" as="image" href="hero.webp" fetchpriority="high">

<!-- The element itself: eager, high priority, never lazy -->
<img src="hero.webp" alt="Product on a clean background"
     width="1200" height="675" fetchpriority="high">

Step 4: Eliminate Render-Blocking Resources

Even a perfectly optimized hero cannot paint while the browser is stuck downloading and parsing CSS and JavaScript in the document head. Every render-blocking resource pushes your LCP later. The remedies are well established: inline the small amount of critical CSS needed for above-the-fold content, load the rest asynchronously, and add defer to non-essential scripts so they never block parsing.

Web fonts deserve special attention when your LCP is text. A font that blocks rendering can hold your headline invisible for hundreds of milliseconds. Use font-display: swap so text renders immediately in a fallback font, and preload the critical font file.

Step 5: Cut Server Response Time (TTFB)

LCP cannot start until the browser receives the HTML. A slow Time to First Byte therefore caps how good your LCP can ever be. If your server takes 800 ms to respond, you have already burned a third of your budget before a single byte of image has moved. Cache rendered pages where you can, optimize slow database queries, and put a CDN in front of your origin so content is served from a node near the user.

# Cache static images aggressively so repeat views are instant
<FilesMatch "\.(webp|avif|jpg|jpeg|png|gif)$">
  Header set Cache-Control "public, max-age=31536000, immutable"
</FilesMatch>

Step 6: Beware Client-Side Rendering Delays

On JavaScript-heavy single-page apps, the hero may not exist in the initial HTML at all — it appears only after a bundle downloads, executes, and renders. That guarantees a poor LCP. Where possible, server-render or statically generate the above-the-fold content so the LCP element is present in the very first HTML response, and hydrate the interactivity afterwards.

The LCP Checklist at a Glance

  • Identified the real LCP element with DevTools.
  • Converted the LCP image to WebP/AVIF and sized it to its display dimensions.
  • Set explicit width and height.
  • Removed loading="lazy" from the hero; added preload + fetchpriority="high".
  • Inlined critical CSS, deferred non-critical JS, and used font-display: swap.
  • Reduced TTFB with caching and a CDN.
  • Ensured the hero is in the initial HTML, not rendered later by JavaScript.

Work through the list in order and re-measure against field data after each change. LCP problems almost always come down to a small number of heavy resources on the critical path — and the heaviest one is usually an image you can fix in minutes.

Shrink your hero image first

The single fastest LCP win is a smaller hero. Convert and resize yours to WebP right now — instantly, privately, and entirely in your browser.

Optimize Images Now
WebPMagic Editorial

About WebPMagic

WebPMagic is an independent project focused on image optimization and web performance. These guides are researched and edited to give developers clear, practical, and accurate information for building faster websites, with tips drawn from hands-on use of our own WebP conversion tool. Found an error or have a suggestion? Let us know via our contact page.