WordPress largest contentful paint poor on mobile? Find the one element first

PageSpeed says your WordPress Largest Contentful Paint is poor on mobile, and the report lists a dozen things to fix. Most of them do nothing for that one number. LCP is the time until a single element finishes drawing, so the useful first step is to find out which element it is.

This is the narrow version of the problem. For the wider question of why a whole site feels slow, start with what to fix first on a slow WordPress site. Finding and fixing one LCP element is part of our WordPress maintenance work.

When is WordPress Largest Contentful Paint poor on mobile?

Google’s web.dev guide says “a good LCP value is 2.5 seconds or less,” measured at the 75th percentile of page loads and split by mobile and desktop. Lighthouse shows 2.5 to 4 seconds in orange and anything over 4 seconds in red.

Which element is your LCP?

Open PageSpeed Insights, choose the Mobile tab, and look under Diagnostics for “Largest Contentful Paint element.” It names one element and shows a breakdown of where its time went.

Web.dev lists what can be an LCP element: an image, an image inside an SVG, a video, an element with a CSS background image loaded by url(), or a block-level element holding text. Each template has its own, so test the ones you care about.

What did we find on our own site?

On Tue 20 Oct 2026 at 12:24 AM ET we ran Lighthouse 13.5.0 in mobile mode on the distrocode.com home page. The LCP element was the h1 headline, a block of text. Not an image.

The breakdown had only two parts, time to first byte and element render delay. There was no load delay and no load duration, because text is not a file the browser has to fetch. We are not quoting seconds. The run came from our own computer, not a US test location, so the numbers would not describe what a visitor in the US sees.

For our page, that ruled out most of the usual advice. Compressing images or preloading a hero would not move that number. The two places left to look were the server response and whatever holds back the headline’s render, which is the text section below.

How do you fix a hero image that is the LCP element?

Web.dev splits LCP into four subparts: time to first byte, resource load delay, resource load duration and element render delay. For an image, check these in order:

1. Is it lazy-loaded? Web.dev: “Never lazy-load your LCP image, as that will always lead to unnecessary resource load delay.” Check that no optimization plugin or theme setting has added lazy loading to it.
2. Is it discoverable in the HTML? The LCP resource “should be discoverable from the HTML source.” A lazy-load script that hides the real address in data-src, or an image added by JavaScript, makes the browser wait.
3. Does it have high priority? Web.dev suggests fetchpriority="high" on the likely LCP image, and warns that on more than one or two images it stops helping.
4. Is the file too big? Resize it to the width it displays at. We covered why WordPress keeps several copies in how WordPress image sizes multiply your files.

WordPress helps with steps 1 and 3. Since 6.3 it adds fetchpriority="high" to the first large image it finds, and skips lazy-loading for images in the viewport. So if the hero on a WordPress 6.3 or later site is lazy-loaded or lacks that attribute, a plugin or theme has probably changed the default. Look at the page source, search for the hero image tag, and read its attributes.

A hero set as a CSS background is a different case. Web.dev says the browser cannot discover it from the HTML unless it is preloaded with <link rel="preload"> or a Link header.

What if the LCP element is text?

Then the delay is usually the server or the font. When text is the LCP element, there is no image to compress. Look at time to first byte first: with no page cache WordPress builds the page for every visit.

Then the web font. Web.dev says to preload a font the LCP text needs, and that with font-display set so text shows while the font loads, “text will always be visible during load, and LCP won’t be blocked on an additional network request.” Also check render-blocking: style sheets loaded from the HTML “will block rendering of all content that follows them.”

What if a slider is the LCP element?

The first slide is the LCP candidate, and it can break several of the image rules at once. If your slider builds slides with JavaScript, lazy-loads them or uses background images, each of those makes the browser find the image late. Check the page source for which of these yours does.

The cleanest fix is often to replace the slider with one static hero image that follows the checklist above. Web.dev’s one slider advice is the other side of this: slides that are not visible at startup should get lower priority, so they do not compete with the first one.

We did not build a slider in a lab for this post. This section is what the documentation says, not something we timed.

What does a fix look like with us?

We run PageSpeed on the pages that matter, read the LCP element on each, change that one thing on a staging copy, and send you the before and after. On a WordPress or WooCommerce site that is $45 for one problem, $110 for up to three and $250 for up to five. We promise no score. Ask for a free site check and a written report comes back within 2 business days.

If you already know your LCP is poor, send us the page address and what PageSpeed names as the element.