By Mehdi HassanHow do you improve LCP on a marketing website?
You improve Largest Contentful Paint by finding the element that counts as the largest paint, almost always something in the hero, and removing every delay between the request and that element appearing. Google's threshold for good LCP is 2.5 seconds or less at the 75th percentile of real visits.
We design heroes for a living, so we look at LCP from both sides: the design choices that make a hero slow and the build choices that make it fast. Most slow heroes can be fixed without changing what visitors see. For the wider context on all three metrics, start with Core Web Vitals explained for marketers and founders.
What is your LCP element and why does it matter?
Your LCP element is the largest image, video poster or text block visible in the first screen as the page loads. Every fix depends on knowing which one it is, because a slow hero image and a slow headline have different causes.
PageSpeed Insights and the Chrome DevTools performance panel both name the LCP element. Check it on mobile and desktop separately, since a different crop or layout can change it. On many marketing pages, the LCP element is the hero image on desktop and the headline on mobile, where the image sits below the fold or is hidden.
Where does slow Largest Contentful Paint time come from?
Slow LCP time comes from four phases, a breakdown Google documents for diagnosing it. Measure which phase is longest before choosing a fix.
Phase | What it is | Hero-specific cause | Fix |
|---|---|---|---|
Time to first byte | Waiting for the HTML | Page rendered on the server per request, slow host | Static or cached pages served from a CDN |
Resource load delay | Time before the hero file starts downloading | Image set by CSS or JavaScript, lazy loaded hero | Image in the HTML with high fetch priority |
Resource load duration | Time to download the hero file | Oversized or uncompressed image or poster | Right-sized AVIF or WebP with responsive sizes |
Element render delay | Time between download and paint | Blocking fonts or scripts, entrance animation, client rendering | Non-blocking fonts, deferred scripts, no fade on the LCP element |
In our experience, load delay and render delay are the most common culprits on modern marketing sites. The image itself is often fine; it's just found late or painted late.
How do you fix the hero image for LCP?
Fix the hero image by making it discoverable early, prioritizing it, and serving the smallest file that still looks sharp. These steps work on any platform.
Put the image in the HTML
Use a real img element, or your framework's image component, rather than a CSS background or a JavaScript slider that injects it after load.
Turn off lazy loading for the hero
Lazy loading is right for images below the fold and wrong for the hero. Set it to load eagerly.
Give it high fetch priority
Add fetchpriority high to the hero image, or the priority option in your framework. Prioritize only one or two images.
Serve responsive sizes
Provide several widths with srcset and an accurate sizes value, so phones get a phone-sized file. Our guide to next/image, fonts and scripts covers this for Next.js.
Use a modern format and sensible quality
AVIF or WebP at moderate quality is usually indistinguishable from a much larger JPEG at hero sizes.
Preconnect to the image host
If images come from a CMS or image CDN on another domain, add a preconnect hint so the connection is ready early.
For format and compression detail across all platforms, see image and video optimization for fast marketing sites.
How should hero video, fonts and animation be handled?
Handle hero video with a fast poster, fonts with a non-blocking strategy, and entrance animation by keeping the LCP element visible from the first frame. These three are where design decisions most often slow LCP down.
Hero video
The browser counts the poster image, or the first frame, as the LCP candidate. Give every hero video a compressed poster sized like a hero image, set preload to none or metadata, and keep the loop short. On mobile, consider showing the poster only. Our guide to hero image vs product screenshot vs video helps decide whether video earns its weight at all.
Fonts
When the headline is the LCP element, a blocking web font delays it. Self-host fonts, preload the one used in the headline, use font-display swap or optional, and match fallback metrics so the swap doesn't shift layout. Load fewer weights; a single variable font often replaces three or four files.
Entrance animation
A headline that fades or slides in from zero opacity isn't painted until the animation reaches visible frames, so LCP gets pushed back. Keep the LCP element visible on first paint and animate secondary elements instead, or start the animation from a visible state. Our guide to hero section animation shows patterns that explain the product without hiding it.
Hypothetical example: a hero with a background video and fade-in headline
For example, suppose a homepage hero has an autoplaying background video with no poster, a headline in a custom font from a third-party provider, and a fade-in animation on the headline that starts after the page script loads.
On a phone, the LCP element is the headline. It waits for the font, then for the script, then for the fade. The fixes: add a compressed poster and show only the poster on small screens, self-host the font with a preload and a tuned fallback, and start the headline visible while animating only the supporting elements. The hero looks the same, but the headline paints on the first frame.
How do you fix server response time and blocking scripts?
Fix server response time by serving marketing pages as static or cached HTML from a CDN, and fix blocking scripts by deferring everything that doesn't affect the first screen. Both shorten the time before the hero can even start loading.
- Cache the HTML. Pages rendered fresh on every request have slow first bytes. Static generation or full-page caching fixes that.
- Avoid redirect chains on landing URLs, especially from ads. Each hop adds a round trip; see our guide to redirect chains and broken links.
- Defer third-party scripts. Tags in the head that load synchronously block rendering. Our third-party scripts audit covers how to find them.
- Inline only critical CSS if your platform supports it, and keep the rest non-blocking.
How do you confirm the LCP fix worked?
Confirm the fix in the lab immediately, then in field data over the following weeks. Lab tools show whether the phases got shorter; field data shows whether real visitors benefit.
Run PageSpeed Insights and a DevTools trace after each change and compare the four phases. Then watch Search Console's Core Web Vitals report, which uses a rolling 28-day window, so the full effect takes up to four weeks to show. If LCP passes but interactions still feel slow, move on to how to fix INP, because the same scripts often affect both.
