How to Improve Largest Contentful Paint (LCP)

PageSpeed Insights says your LCP is 4 or 5 seconds on mobile. You have already installed a caching plugin, compressed a few images, maybe swapped the hero photo for a smaller one, and the number has barely moved. That is frustrating, and it usually means the fix was aimed at the wrong part of the problem.

Knowing how to improve Largest Contentful Paint starts with working out where the time goes. LCP is not one delay. It is four delays stacked on top of each other, and each has a different cure. Find the biggest one and you fix slow LCP far faster than by trying every tip at once.

If you need a reminder of what the three Core Web Vitals are and where Google sets the line, start with our plain-language overview of Core Web Vitals. The short version here: LCP counts as good at 2.5 seconds or less, judged at the 75th percentile of real visits.

Step one: find out which element is your LCP

You cannot speed up the largest element until you know what it is, and it is often not what people assume. On one page it is the hero image. On another it is a heading, because the image above it is small or loads late. On mobile it may be a different element from desktop, since the layout stacks differently.

Three ways to identify it:

• PageSpeed Insights. In the lab section, look for the diagnostic about the Largest Contentful Paint element. It names the element and shows a snippet of its HTML.
• Chrome DevTools, Performance panel. Record a page load. The LCP marker in the timings track can be clicked to highlight the element on the page.
• Elements that count. Images, the poster image of a video, background images loaded through CSS, and large blocks of text. Knowing this helps when the tool points at something odd, like a paragraph inside a cookie banner.

Write down the element for both mobile and desktop. If the cookie notice or a popup is the LCP element on mobile, that is a finding in itself: a big overlay is being treated as the main content of your page.

Step two: split LCP into its four parts

Google’s own guidance on LCP breaks the time into four sub-parts. PageSpeed Insights shows this breakdown in its LCP diagnostic, and DevTools shows it too. This is the single most useful view when you are working out how to improve Largest Contentful Paint, because it tells you which kind of problem you have.

If the LCP element is text, there is no image download, so only the first and last parts apply. That alone narrows things down: a slow text LCP usually comes down to server time or render blocking.

When server time is the biggest slice

If most of the LCP is spent waiting for the first byte, no amount of image work will help. The browser cannot start on anything until the HTML arrives.

Check, in this order:

1. Is the page served from cache? Load the page in a private window and look at the response headers in DevTools. Most caching plugins and hosts add a header showing a hit or miss. A miss on every load means the page is being built from scratch for each visitor.
2. Are there redirects? A link to http:// that bounces to https://, then to www, adds a round trip each time. Ads and email campaigns are common sources of these chains.
3. Is the server far from your visitors? A site hosted in one continent and visited mainly from another pays a distance cost on every request.

Server waiting time has its own measurement and its own post. If this is your biggest slice, read how time to first byte is made up and measured before changing anything else.

When the image is found too late

Resource load delay is the part most sites can improve quickly, and the part most often overlooked. The browser reads your HTML from top to bottom and starts fetching images as it finds them. If the hero image is not in the HTML at all, or is marked to wait, the browser discovers it late.

Common reasons the LCP image is discovered late

• It is lazy-loaded. Lazy loading tells the browser to wait until an image is near the viewport. For an image that is already in the viewport, that wait is pure delay. This is a common LCP mistake on WordPress sites, and it is covered properly in our post on how lazy loading works and where it backfires.
• It is a CSS background. Page builders often set hero banners as background images. The browser only finds them after downloading and reading the stylesheet.
• A slider or script inserts it. If JavaScript builds the slideshow, the first slide does not exist until that script runs.
• Too many competing downloads. Dozens of scripts, fonts and small images all requested at once can push the important one down the queue.

How to bring it forward

• Make sure the hero is a normal <img> tag in the page HTML where you can, not a background set by the builder.
• Exclude the first image on the page from lazy loading. Most optimisation plugins have a setting to skip the first one or two images, or to exclude by class name.
• Add fetchpriority="high" to the LCP image. This hints to the browser that this image should jump the queue. Recent versions of WordPress try to add it automatically to the image they judge most likely to be the LCP, but themes and builders can override that, so check the HTML.
• If the image must be a background, a preload hint in the page head (<link rel="preload" as="image">) lets the browser start fetching it before it reads the stylesheet. Use it for one image only, or it stops meaning anything.

When the download itself is slow

Here the browser asked for the image in good time, but the file took a long time to arrive. The fix is a smaller file, a closer server, or both.

• Serve the right size. A 2,400-pixel photo shown at 400 pixels wide on a phone is mostly wasted bytes. WordPress creates several sizes of every upload; make sure the theme is actually offering them to the browser.
• Use a modern format and sensible compression. WebP or AVIF versions of the same photo are generally much smaller than a JPEG at similar visible quality.
• Use a CDN for static files if a lot of your visitors are far from your server.

Images on a website are a big subject on their own, and we have covered it in the practical guide to optimising website images. For LCP, only one image really matters: the one the tools named in step one.

When the image has arrived but nothing shows

Element render delay is the gap between the file being ready and the visitor seeing it. The browser has the image but cannot paint it yet, usually because it is still waiting on something else.

• Render-blocking CSS and JavaScript. The browser will not paint until it has the stylesheets in the head. Large combined stylesheets and scripts loaded without defer hold everything back.
• Web fonts. If your LCP element is a heading and the font is set to stay invisible until downloaded, the heading cannot paint until the font arrives.
• Sliders and animations. Some sliders hide the first slide until their script has initialised, or fade it in from transparent. The image is loaded; the visitor still sees nothing.
• Client-side rendering. If a script builds the hero section, nothing paints until that script runs.

A quick test for the slider and fade-in problem: turn the animation off for the hero, or replace the slider with one fixed image on a test copy, then compare LCP. If render delay collapses, you have your answer.

How to improve Largest Contentful Paint and prove it worked

Before you change anything, save a PageSpeed Insights result for the page and note the four sub-parts, not just the total. After each change, test again a few times, because lab results vary from run to run. You are looking for the slice you targeted to shrink.

Then remember that the field data Google judges you on covers the past 28 days. A fix made today shows up gradually as new visits replace old ones. Do not undo a good change because the field number has not moved by the next morning.

Mistakes that make LCP worse

• Preloading everything. Preload hints for five images, three fonts and two scripts compete with each other. The LCP image ends up no further forward.
• Lazy loading by default with no exceptions. Good for long pages, harmful for the first screen.
• Hiding the hero on mobile and showing a different one. Some themes load both images and hide one with CSS. The visitor downloads two heroes.
• Delaying all JavaScript blindly. If the hero depends on a script, delaying that script delays the LCP.
• Testing only the homepage. Product pages, blog posts and service pages often have a completely different LCP element and a different problem.

For how LCP fits alongside hosting, caching and everything else that affects load time, the complete guide to website speed lays out the bigger picture.

Frequently asked questions

Why is my LCP fine on desktop but poor on mobile?

Phones have slower processors and often slower connections, so every part of LCP takes longer. The layout also changes, so the largest element on mobile may be a different image or a text block. Test the mobile view separately, find its own LCP element, and check whether a smaller image size is actually being served to phones.

Can a cookie banner or popup become the LCP element?

Yes. If a consent banner or popup covers a large part of the first screen on mobile, the browser may treat its text as the largest content. That makes LCP depend on whenever the banner script runs. Making the banner smaller, or loading it in a way that does not depend on a late script, usually helps.

Will a CDN improve my LCP?

It can shorten the image download if many visitors are far from your server, and a CDN that also caches whole pages can cut server time. It does nothing for an image that is discovered late or a page held back by render-blocking files. Check which of the four parts is largest before deciding a CDN is the answer.

Does a video in the hero section count for LCP?

The poster image of a video counts as a candidate, and so does the first frame of a video once it is shown. A large autoplaying hero video can therefore push LCP back, especially on mobile data. A light poster image that appears quickly is often the most practical way to keep LCP in the good range.

Fixes that sit deep in a theme or builder are easier to judge with this breakdown in hand. Our speed optimisation work for small business sites starts from an audit like the one above and shares a prioritised fix list before any change is made, so you know what will be touched and why.

Next in this series: Interaction to Next Paint Explained: What INP Measures