How to Improve Largest Contentful Paint (LCP)
- Difficulty
- Moderate
- You need
- PageSpeed Insights, Chrome DevTools
- Optional
- Access to hosting or CDN settings
On this page
To improve Largest Contentful Paint, find which element is the LCP, then shorten each stage before it appears: the server's first response, the wait before the browser starts loading that element, the download itself and any delay before it is painted. Good LCP is 2.5 seconds or less for 75% of visits. This guide is part of our website design best practices guide.
You'll need PageSpeed Insights and Chrome DevTools. Access to your page templates helps with most steps, and hosting or CDN settings help with step 3. If you're new to the metric, start with Core Web Vitals.
What counts as the LCP element
LCP times the largest image, video or text block visible in the viewport when the page loads. Browsers consider img elements, images inside SVG, the poster or first frame of a video, elements with a CSS background image and block-level elements that contain text.
Some elements are left out on purpose. Chrome ignores invisible elements with an opacity of 0, elements that cover the whole viewport and look like a background, and low-detail placeholder images. The browser also stops reporting new LCP candidates once the visitor taps, scrolls or presses a key.
On most business sites, the LCP element is a hero image, a large heading or a hero video. Knowing which one it is decides which steps below matter most.
Where LCP time goes
The Chrome team breaks LCP into four parts. Every fix in this guide shortens one of them, so it helps to know which part is the largest on your page.
| Part | What it covers | Common causes of delay |
|---|---|---|
| Time to first byte | Navigation start to the first byte of HTML | Slow server, no caching, redirects |
| Resource load delay | First byte to when the LCP file starts loading | Image found late, lazy loading, low priority |
| Resource load duration | Downloading the LCP file itself | Oversized image, wrong format |
| Element render delay | File loaded to element painted | Blocking CSS or scripts, hidden by script |
If the LCP element is text, there is no file to load, so the two middle parts are close to zero. The remaining time sits in server response and render delay.
Steps
- Start from field data, on mobile.
Run the page through PageSpeed Insights and read the field section first. It shows LCP from real Chrome visits over the previous 28 days, at the 75th percentile. If the field LCP is already good, your time is better spent elsewhere. If it's poor, note whether mobile, desktop or both fail, and fix the template rather than one page if many URLs share it.
- Identify the LCP element.
In the same report, the Lighthouse diagnostics name the LCP element and show its breakdown into the four parts. In Chrome DevTools, the Performance panel marks the LCP and highlights the element. Check at a phone width as well as desktop, because the largest element often changes with the screen size. Write down the element and its largest part.
- Reduce server response time.
A slow first byte delays everything after it. Cache HTML at the server or a CDN where the page allows it, remove redirects before the final URL, and check that slow database calls or plugins aren't holding the response. Google's guide suggests most sites aim for a TTFB of 0.8 seconds or less. It's not a Core Web Vital itself, so treat it as a target only.
- Make the LCP resource discoverable in the HTML.
The browser's preload scanner can only start a download early if it sees the file in the initial HTML. An img element with src or srcset in the markup is found at once. An image set as a CSS background, or inserted by JavaScript after the page loads, is found late. Where you can, use a real img element for the hero.
- Give the LCP image high priority, and never lazy-load it.
Add `fetchpriority="high"` to the LCP image so the browser fetches it ahead of less important files. Remove `loading="lazy"` from it. Lazy loading is for images below the fold, and on the LCP image it always adds delay. Set width and height so the layout stays stable:
html<img src="/images/hero-1200.webp" alt="Crew filming on a studio set" width="1200" height="675" fetchpriority="high"> - Make the LCP file smaller.
Serve a modern format such as WebP or AVIF, and give phones a smaller file with srcset and sizes instead of the desktop original. Compress to the lowest quality that still looks right on a large screen. The format and sizing choices are covered step by step in our guide to image optimization.
- Remove render-blocking resources.
Even a loaded image can't be painted while the browser waits on stylesheets and scripts in the head. Defer scripts that aren't needed for the first view, remove unused CSS, and keep critical styles small. If the LCP element is a text block, the web font can also hold it back. See web font loading for ways to keep text visible.
- Don't hide the LCP element behind scripts.
Some pages render the hero only after JavaScript runs. Others hide it while a testing tool or slider decides what to show, or fade it in from opacity 0. All of these add render delay. Render the hero in the initial HTML where you can, and start any entrance animation from a visible state.
- Re-test, then watch the field data.
Run a new lab test to confirm the LCP element loads earlier and the largest part has shrunk. Field data takes longer, because PageSpeed Insights shows the previous 28 days of visits. In Search Console, start a validation on the fixed issue and check the URL group again over the following weeks.
How much of this you can change depends on the platform, which we cover in how platforms differ. If you'd rather have it handled, our in-house web team builds sites with performance planned from the first template.
Hero images, video and accessibility
The LCP element is usually the first thing a visitor sees, so it's also where accessibility problems show up first. Speed fixes shouldn't undo them.
Alt text. If the hero image carries meaning, give it alt text that says what it shows in the context of the page. If it's purely decorative, use an empty alt attribute (`alt=""`) so screen readers skip it. WCAG's Non-text Content criterion, Level A, covers both cases.
Text in images. A headline baked into a hero image can look sharp and load as one file, but screen readers can't read it and it can't be resized or restyled. WCAG's Images of Text criterion asks you to use real text where you can. Real text is often faster as an LCP element too.
Video and motion. An autoplaying hero video that runs for more than five seconds needs a way to pause or stop it, under WCAG's Pause, Stop, Hide criterion. Respect the `prefers-reduced-motion` setting by showing a still poster instead. The poster image is then the LCP element, so give it the same priority as a hero image.
Troubleshooting
The LCP element is different on mobile and desktop
Cause: responsive layouts change what's largest in the viewport. A wide headline may be the LCP on desktop, while a tall hero image wins on a phone, or the reverse. Fixes aimed at one element then help only one device type, and the other keeps failing in Search Console.
Fix: identify the LCP element at both widths in Chrome DevTools and note each one. Apply the discoverability, priority and size steps to the element that wins on each device. Where art direction differs, use the picture element with media conditions, so each device downloads only its own image. Avoid loading a large desktop hero on mobile and hiding it with CSS, because it still downloads and competes for bandwidth.
LCP is fine in the lab but poor in the field
Cause: a lab test runs on one simulated device and connection. Real visitors use older phones, slower networks and different entry points, such as an ad link with tracking parameters that skips the cache or adds redirects. Pages opened from a cold start, without anything cached, are also slower than a repeat test.
Fix: turn on network and CPU throttling in DevTools and test again with a mid-range phone profile. Test the exact URLs people land on, including campaign parameters, and check for redirects. Look at server response time under real load. If you can, collect your own field data with a small script that reports LCP and its parts, so you can see which part is slow for real visitors.
LCP got worse after adding a hero video or slider
Cause: a video's LCP is the earlier of its poster image or its first frame, so a video without a poster waits for the video file. Sliders often load several large images at once, inject them with JavaScript, or start hidden while the script sets up, which adds load and render delay.
Fix: give the video a poster image, sized and prioritized like a hero image, and add pause controls. For a slider, render the first slide as a real img element in the HTML with high priority, and lazy-load the slides that follow. Ask whether the page needs a slider at all. A single clear hero is faster, and it is easier for keyboard and screen reader users.
Common questions
Is a text headline or an image better for LCP?
Text usually renders sooner, because it doesn't need a separate file download, especially with a system font or a font that loads early. That doesn't mean you should drop your hero image. Choose the layout that serves the page, then optimize whichever element ends up as the LCP. A well-prioritized, correctly sized image can still render well within the good threshold.
Should I preload my hero image?
Only if the browser can't find it in the HTML. If the hero is an img element with its src or srcset in the initial markup, adding fetchpriority high is usually enough. Preloading helps when the image is set as a CSS background or added by a script. Preload just the one critical image; preloading many files makes them compete for bandwidth.
Why is my LCP worse on mobile than on desktop?
Mobile visits often run on slower processors and networks, so every step takes longer. The LCP element can also differ: a headline on desktop might give way to a tall hero image on a narrow screen. Check which element is the LCP on each device, serve smaller image files to small screens, and test with network and CPU throttling turned on.