How to fix a slow LCP, step by step

Step 1: find the LCP element

Run the page in PageSpeed Insights on the mobile tab and look at the insights for LCP. The report names the element: a heading, a paragraph, an image, a video poster. You can also open the Performance panel in Chrome DevTools, record a load and look at the LCP marker.

Write down two things: what the element is, and whether it is an image. An image has four parts to its time. A text element has only two, the wait for the server and the delay before the text is drawn, so the image fixes below do not apply to it.

Step 2: split the time into four parts

For an image, the LCP breakdown shows how the time divides. Read what LCP is for the definitions. In short:

Google suggests that on a well-optimized page about 40% of the time is spent on the first byte, under 10% on the load delay, about 40% on the download and under 10% on the render delay. These are guidelines, but they point at the right habit: the two "delay" parts should be small. A load delay of 1.2 seconds or a render delay of 800 milliseconds is wasted time that no amount of image compression recovers.

Fix A: the server is the longest part

If the first byte takes more than a third of your LCP, no front-end fix can rescue the page. Cache the finished page, serve it through a CDN, remove redirects, and look at the hosting. The time to first byte guide has the full list, and reducing server response time shows how to find the cause.

Fix B: the browser finds the image late

The browser starts the image download as soon as it discovers the image. When the image is in the HTML as a plain <img> with a src, it is found almost immediately, even before the CSS has loaded. When it is not, it waits. This is the most common cause of a long load delay.

Find which of these describes your page.

The hero is a CSS background image. The browser only discovers it after it has downloaded and read the stylesheet. Change it to an <img> element, or, if it has to stay a background, preload it:

<link rel="preload" as="image" href="/img/hero-1600.avif" type="image/avif">

The image is added by JavaScript. Sliders, carousels and page builders that build the hero with a script make the browser wait for the script to download and run. Put the first image in the HTML, and let the script take over after that. If you cannot change the markup, preload the first image.

The image is lazy-loaded. loading="lazy" tells the browser to wait until the image is near the screen, which for the image at the top is exactly wrong. Remove it from the LCP image. Many lazy-loading plugins and theme options have a setting to skip the first image; use it.

A script-based lazy loader hides the real address. Some libraries put the file name in data-src and fill in src later. The browser cannot see the image until the script runs. Use the native loading attribute for images below the fold, and a normal src for the first one.

For a responsive image, the preload has to match the srcset and sizes of the image it stands for, or the browser may fetch the wrong file. The link element takes the same two values:

<link rel="preload" as="image" href="/img/hero-800.jpg"
      imagesrcset="/img/hero-400.jpg 400w, /img/hero-800.jpg 800w, /img/hero-1600.jpg 1600w"
      imagesizes="100vw">

imagesrcset works in current versions of Chrome, Firefox and Safari. Preload only the format that most of your visitors will use, because preloading two formats makes some browsers fetch both.

Fix C: the browser finds it, but at low priority

Browsers guess how important each request is, and they guess wrong for images sometimes, especially when a script or stylesheet competes with it. The fetchpriority attribute lets you say that this image matters:

<img src="/img/hero-1200.avif" width="1200" height="600" fetchpriority="high" alt="Description of the picture">

Use it on the LCP image only, or on two images at most. MDN's own warning is that excessive or incorrect prioritization can make a page slower, because every high-priority request pushes the others back. It works in Chrome 102 and later, Firefox 132 and later and Safari 17.2 and later; in other browsers it is ignored. In Lighthouse 13, the "LCP request discovery" insight checks all three of fixes B and C: that the image can be found in the HTML, that fetchpriority="high" is set, and that it is not lazy-loaded.

On WordPress, version 6.3 and later add fetchpriority="high" to the first large image by themselves, if the image has a width and a height. A theme, plugin or page builder that builds the image differently may bypass this, so check the HTML.

Fix D: the image takes too long to download

If the download is the longest part, the file is too big for the connection, or the route to it is slow.

• Use the right size. An image 2,000 pixels wide shown 600 pixels wide wastes most of its bytes. See image optimization for sizes, srcset and compression.
• Use a modern format. WebP or AVIF files are usually much smaller than JPEG or PNG for the same picture. Photos saved as PNG are a common mistake.
• Serve it from a nearby place. A CDN shortens the distance. If the image is on another host than the page, add a preconnect hint so the connection is opened early. The 2025 Web Almanac found about one in six LCP images on a different host from the page.
• Avoid redirects on the image address. An image URL that redirects adds a full round trip.
• Let it cache. Repeat visitors then get it for free.
• Reduce competition. Other large files loading at the same time share the same connection. Lazy-load what is below the fold so it does not compete.

Fix E: the image arrives, but the page does not draw it

If the render delay is long, something is blocking or delaying the draw after the download has finished.

• Render-blocking CSS and JavaScript. See critical CSS and render-blocking resources.
• A page built by JavaScript. If the image's element is created by a script, it appears when the script has run. Render the hero on the server.
• A busy main thread. Long tasks right before the paint delay it. Total Blocking Time shows how much JavaScript work happens during loading.
• An animation or fade-in. A hero that starts at zero opacity and fades in is not counted as drawn until it is visible. Start the hero fully visible.

When the LCP element is not an image

• Text. The delay is the server and whatever blocks the draw. Make sure the heading is in the HTML, and that a web font does not hide it: use font-display: swap and preload the one font the top of the page needs.
• A video. The poster image counts, and so does the first frame of a video that plays by itself. Use a small, compressed poster, and do not start a heavy video above the fold.
• A cookie banner or pop-up. If it is the largest thing on the first screen, it is your LCP. Make it smaller or let it overlay the page.

Step 3: test again

Run the lab test three times and compare the median LCP and its four parts with the numbers you wrote down. A fix that worked shows up as a shorter part, usually the one you worked on. Then check the real-user data again in four weeks, because that is what Google judges.

Check your own page

Run the free audit on your most important page. Find the LCP element, note the longest of the four parts, and start with the fix that matches it. If the report says the main image was found late or lazy-loaded, that is a ten-minute fix with a large effect.

Sources

• Optimize Largest Contentful Paint on web.dev: the four parts and the order in which to fix them.
• fetchpriority on MDN: how it works and the warning against overuse.
• rel="preload" on MDN: preloading images, the one-format advice and the media attribute.
• Performance chapter of the 2025 Web Almanac: how many LCP images are lazy-loaded or on another host.