Slow LCP: Fixing Largest Contentful Paint

What LCP actually measures

While a page loads, the browser keeps track of the largest piece of content it has painted inside the viewport so far. Each time something bigger appears, it becomes the new candidate. When the visitor first interacts with the page, by tapping, clicking or pressing a key, the browser stops looking, and the last candidate becomes the Largest Contentful Paint. Scrolling does not count as an interaction for this purpose on every browser, so treat the first screenful as what matters.

Only certain kinds of element can be the LCP element:

• Images in an <img> tag, including the one chosen from a <picture> element or a srcset.
• Images inside SVG drawn with the <image> element.
• Video poster images, and in current Chrome the first painted frame of a video.
• CSS background images loaded with url(), as opposed to gradients.
• Block-level elements containing text, such as a heading or a paragraph.

The size used is what is visible on screen, so an image that is partly off the edge only counts its visible area, and an image stretched beyond its natural size is counted at its natural size. Chrome also ignores elements with no visible content and very low-detail placeholder images, so a blurry placeholder usually does not steal the LCP from the real hero image that replaces it.

The time is measured from when the visitor started navigating to your page, not from when the HTML arrived. Redirects, DNS lookups, connection set-up and a slow server all count towards it before a single byte of your hero image has been requested.

The four parts of LCP time

Every LCP time can be split into four consecutive stages. Knowing which stage is long tells you which fix to apply, and it stops you spending a day compressing an image when the real problem is that the browser did not ask for it until two seconds in.

For a text LCP element, such as a large heading, there is no resource to fetch, so the two middle stages are zero and the time is split between TTFB and render delay. That usually points at blocking stylesheets or a web font.

As a rough guide, a healthy page spends most of its LCP time in TTFB and in downloading the image, with the load delay and render delay both kept small. If either of the "delay" stages is the largest slice, you have a prioritisation problem rather than a file-size problem, and that is good news, because prioritisation fixes are usually a single line of HTML.

How to find your LCP element and its bottleneck

Start with the Core Web Vitals checker or PageSpeed Insights for the failing URL. Check the field result first, on mobile, to confirm the problem is real, then look at the lab diagnostics to see which element Lighthouse chose and how its time breaks down.

The lab element is not always the one real visitors see. A cookie banner, a different hero on small screens or personalised content can all change it. To see what your own browser records, open DevTools, go to the Console and paste this before reloading:

new PerformanceObserver((list) => {
  const entries = list.getEntries();
  const last = entries[entries.length - 1];
  console.log('LCP candidate', Math.round(last.startTime), 'ms', last.element, last.url);
}).observe({ type: 'largest-contentful-paint', buffered: true });

Every new candidate is logged, so the final line is the LCP element. Repeat on a phone-sized viewport with the network throttled, because mobile layouts often have a different hero.

Collecting it from real visitors

For the full picture, record LCP from real visits using Google's open-source web-vitals library with its attribution build. It reports the element selector and the time spent in each of the four stages, which you can send to your analytics tool:

import { onLCP } from 'web-vitals/attribution';

onLCP(({ value, attribution }) => {
  navigator.sendBeacon('/rum', JSON.stringify({
    lcp: Math.round(value),
    element: attribution.target,
    ttfb: Math.round(attribution.timeToFirstByte),
    loadDelay: Math.round(attribution.resourceLoadDelay),
    loadDuration: Math.round(attribution.resourceLoadDuration),
    renderDelay: Math.round(attribution.elementRenderDelay)
  }));
});

Group the results by page template. If the same element and the same slow stage keep coming up, you have found the fix to make.

Common causes, stage by stage

Long TTFB

If the first byte takes more than about 800 ms for most visitors, fix that before anything else. Common causes are pages built from scratch on every request, uncached database queries, a server on another continent from your visitors, and chains of redirects such as http to https to www. The TTFB guide covers server-side fixes in detail.

Long resource load delay

• Lazy-loaded hero image. A loading="lazy" attribute on the main image tells the browser to wait until layout is known, which delays the request. Many themes and plugins apply lazy loading to every image by default.
• Image set by JavaScript. Sliders, carousels and lazy-load libraries that keep the real address in data-src hide the image from the browser's preload scanner until the script runs.
• CSS background image. The browser only learns about a background image after it has downloaded and parsed the stylesheet and matched the rule to an element.
• Client-side rendering. If the HTML is an empty shell and the page is built by a JavaScript framework, the image cannot be requested until the bundle has downloaded and run.
• Normal priority. Images start at low priority in Chrome until layout shows they are in the viewport, so the hero can queue behind scripts and fonts.

Long resource load duration

The file is simply too big for the connection: a 2,400-pixel-wide JPEG sent to a 400-pixel phone screen, no modern format, or an image served from a separate domain that needs its own connection set up. Serve AVIF or WebP, use srcset and sizes so small screens get small files, and host images on the same origin or a CDN that is already connected.

Long element render delay

The image has arrived but the browser is not allowed to paint it yet. Blocking stylesheets and synchronous scripts in the <head> are the usual reason. Others are A/B testing snippets that hide the page until an experiment loads, fade-in animations that start at zero opacity, a hero that is only revealed once a slider script initialises, and text headings waiting for a web font with a long block period.

The key HTML changes

For most image heroes, the fix is a correctly written image tag that the browser can find in the first chunk of HTML and knows is important:

<img
  src="/images/hero-1200.avif"
  srcset="/images/hero-600.avif 600w, /images/hero-1200.avif 1200w, /images/hero-1800.avif 1800w"
  sizes="100vw"
  width="1200" height="675"
  alt="Walkers on the coastal path above Hartcliffe Bay"
  fetchpriority="high"
  decoding="async">

There is no loading attribute, which means eager loading. fetchpriority="high" tells the browser to request it ahead of other images, and it is now supported across Chrome, Edge, Safari and Firefox. The width and height reserve space so the image does not also cause layout shift.

When the image cannot be in the HTML

If the hero must stay a CSS background, or it is inserted by a framework, preload it so the request starts straight away:

<link rel="preload" as="image"
  href="/images/hero-1200.avif"
  imagesrcset="/images/hero-600.avif 600w, /images/hero-1200.avif 1200w"
  imagesizes="100vw"
  fetchpriority="high">

Put it high in the <head>, before stylesheets and scripts. Preload only the one LCP image per template; preloading several images makes them compete with each other and with your CSS.

Images on another domain

<link rel="preconnect" href="https://images.example-cdn.com" crossorigin>

A preconnect lets the browser do the DNS lookup, connection and TLS handshake for an image host early. Use it for the one or two origins that serve above-the-fold content, not for every third party.

Platform notes

• WordPress. Since version 6.3, WordPress core adds fetchpriority="high" to the image it judges most likely to be the LCP element and skips lazy loading for it, but page builders, sliders and optimisation plugins can override that. Check the rendered HTML, not the setting screen. See Core Web Vitals in WordPress.
• Shopify. The Liquid image_tag filter accepts loading and fetchpriority parameters, so the hero section can be written to load eagerly with high priority. See Core Web Vitals in Shopify.
• Next.js. Mark the hero next/image as the priority image (the priority prop, or preload in newer versions) so it is preloaded and not lazy-loaded. See Core Web Vitals in Next.js and Nuxt.
• Static and custom sites. You control the markup, so apply the tag above directly and make sure your build tool is not rewriting it with a lazy-load attribute.

The fix, step by step

Edge cases worth knowing

• The LCP is a cookie banner. A large consent notice with plenty of text can become the LCP element. That is fine if it appears quickly; if the consent script loads late, it can make LCP worse. Keep banner text short and load the consent tool early and lightly.
• Back and forward navigation. Pages restored from the back/forward cache report very fast LCP in field data. Making your pages eligible for that cache, by avoiding unload handlers and Cache-Control: no-store where you can, genuinely improves the field figure.
• Carousels. An auto-rotating slider can make the LCP a later slide, and slider scripts often hide slides until they initialise. Render the first slide as a plain image in the HTML and enhance it afterwards, or replace the carousel with one static hero.
• Video heroes. Always set a poster image that is small and fast, and preload that poster rather than the video file.
• Different element on mobile. A hero hidden with display: none on small screens is often still downloaded. Use a <picture> element with media conditions so each screen size downloads only the image it shows.

Keeping LCP fast

LCP tends to drift back when a new hero section, a new slider or a new plugin arrives. A few habits stop that:

1. Write the hero image rules into the template itself, so editors cannot switch lazy loading back on for the first section.
2. Set a size budget for hero images and have your upload process create AVIF and WebP versions at fixed widths.
3. Add a Lighthouse check to your deployment process that fails when LCP on a test page goes over an agreed limit, and keep real-user monitoring running so field regressions are noticed within days.
4. Review any script that must run before the page is shown, such as A/B testing or personalisation tools, before it is added.

If your pages also move around as they load, the layout shift guide covers the related fixes, and the First Contentful Paint guide deals with the blocking files that delay the very first paint.