Performance

How to Fix a Slow Largest Contentful Paint (LCP)

A slow LCP means visitors wait for your main content. Find your LCP element, then fix server response, images, render-blocking files and late discovery.

By Zebra Hosting Cloud

Largest Contentful Paint is the moment the biggest visible element on the first screen finishes rendering. Google considers 2.5 seconds or less good and anything above 4 seconds poor. Because LCP is closest to what a visitor means by "the page has loaded", it is usually the first Core Web Vital worth fixing.

The trick is not to guess. LCP can be split into parts, and each part has a different remedy. This guide walks through finding the element, working out which part is slow, and fixing it.

Work through it step by step

Step 1: find your LCP element

Run the page through PageSpeed Insights or Lighthouse in Chrome DevTools. The report names the LCP element, for example an image with a particular class or a heading. Check it on mobile, because the largest element often differs from desktop. On many sites it is a hero image or slider picture; on text-heavy pages it is a headline or paragraph.

Step 2: break the time into four parts

LCP time is the sum of four phases:

  1. Time to first byte: how long the server takes to start responding.
  2. Resource load delay: how long before the browser starts downloading the LCP resource, such as the image.
  3. Resource load duration: how long the download takes.
  4. Element render delay: the gap between the file arriving and it appearing on screen.

Chrome DevTools' Performance panel and several free tools show this breakdown. The biggest number points to the right fix.

Fixing a slow server response

If time to first byte is large, nothing after it can be fast. Enable page caching so the server does not rebuild each page from the database on every visit, use a current PHP version, and avoid redirect chains such as http to https to www. The knowledge base is a good next stop, and a separate article covers TTFB in more depth.

Fixing late discovery of the image

A very common mistake is that the browser does not find out about the hero image until late. This happens when the image is set as a CSS background, injected by JavaScript, or hidden inside a slider script. The remedies are straightforward:

  • Use a normal img element in the HTML for the hero image rather than a background image.
  • Do not lazy-load the LCP image. Lazy loading is excellent for images below the fold, but applied to the main image it delays the very thing you are measuring.
  • Consider the fetchpriority="high" attribute on the LCP image to tell the browser it matters most.
  • If the image must be referenced from CSS or script, a preload hint in the page head lets the browser start earlier.

Fixing a heavy image

If the download itself is slow, the file is too big. Hero photos straight from a camera or stock site are often several megabytes. Resize the image to the largest size it is actually displayed at, compress it, and use a modern format such as WebP or AVIF. Use srcset so phones receive a smaller file than desktops. Our article on image formats covers the choices in detail.

Fixing render delay

When the image has arrived but does not appear, something is blocking rendering. The usual culprits are large CSS files loaded in the head, synchronous JavaScript, and web fonts that hide text until they load when the headline is the LCP element. Remove unused CSS, defer scripts that are not needed for the first screen, and set font-display: swap or optional on custom fonts. Sliders and animation libraries that hide content until they initialise are another frequent cause; consider replacing a slider with a single static hero.

WordPress-specific tips

  • Check that your theme or page builder is not wrapping the hero in a lazy-load script. Most caching and image plugins allow you to exclude the first image.
  • Replace oversized uploads, since WordPress generates several sizes but themes sometimes request the full-size original.
  • Disable plugins that add scripts to every page when they are only needed on one.

Check the result properly

After changes, test again on mobile in PageSpeed Insights. Lab numbers move immediately; field numbers update over the following weeks. If the lab LCP is under 2.5 seconds but the field data is still poor, real visitors may have slower devices or networks than the simulated test assumes, so keep trimming image weight and scripts.

A quick LCP checklist

  • The LCP element is a real img or text block in the HTML, not injected late by a script.
  • The LCP image is not lazy-loaded and has fetchpriority="high".
  • The image is no larger in pixels than the biggest size it is displayed at, and is served as WebP or AVIF.
  • Full-page caching is enabled, and the server answers quickly.
  • CSS in the head is trimmed, and non-critical scripts use defer.
  • Fonts used by the LCP text are preloaded or use a sensible font-display setting.

Work through the list from top to bottom. Each item is cheap to check, and between them they explain the large majority of slow LCP scores on small business sites.

A fast server gives you headroom

Everything above is easier when the server responds quickly. Zebra Hosting Cloud plans come with Plesk, where PHP versions can be selected per site, and the WordPress plans are built around WordPress sites. Compare options on the WordPress hosting page.