How to Fix Largest Contentful Paint on a WordPress Site

If PageSpeed Insights or Search Console says your Largest Contentful Paint is too slow, I’ll show you how to fix Largest Contentful Paint on a WordPress site in the order that actually works. You’ll learn what LCP measures, how to find the element causing the delay, the four parts that make up the number, and the fixes I apply first when a client sends me a slow site. It all works whether your site runs on Elementor, Divi, a block theme or custom code.

What Largest Contentful Paint measures

Largest Contentful Paint, or LCP, is the time between a visitor starting to load your page and the largest visible piece of content appearing on their screen. On most business sites that’s the hero image, a banner, a product photo or, on text-heavy pages, the main heading. It’s the moment the page looks loaded to a human, which is why Google uses it as one of its three Core Web Vitals.

Google’s thresholds are simple: 2.5 seconds or less is good, between 2.5 and 4 seconds needs improvement, and over 4 seconds is poor. The catch is how it is measured. Google looks at the 75th percentile of real visits over the last 28 days, so three out of four visits need to hit 2.5 seconds for the page to pass. A fast test on your office Wi-Fi doesn’t count for much if most of your visitors are on phones.

Mobile and desktop are scored separately, and they often have different LCP elements. On desktop it might be a wide banner. On mobile it might be the heading, because the banner is hidden or stacked lower.

Find your LCP element before changing anything

The most common mistake I see is someone installing an optimization plugin before they know what the LCP element is. Find it first. It takes two minutes.

• PageSpeed Insights: run the page, then look in the diagnostics for the Largest Contentful Paint element or the LCP breakdown. It names the exact element and shows a small preview.
• Chrome DevTools: open the Performance panel on the page. Recent versions show live Core Web Vitals, including which element was counted as LCP.
• Search Console: the Core Web Vitals report tells you which groups of URLs fail, so you know which templates to test first.

On WordPress sites the usual suspects are an Elementor section with a background image, the first slide of a slider, a full-width hero image uploaded straight from a camera, or a heading waiting on a web font.

The four parts of LCP, and which one is hurting you

LCP is not one problem. It’s the sum of four delays, and PageSpeed Insights now breaks them down for you. Fix the biggest one first.

1. Time to First Byte. How long the server takes to send the first byte of HTML. If this alone is over a second, no amount of image work will save you.
2. Resource load delay. The gap between the HTML arriving and the browser starting to download the LCP image. This gets long when the image is a CSS background, is lazy loaded, or is injected by a slider script.
3. Resource load duration. How long the image takes to download. Think large file, slow connection, no CDN.
4. Element render delay. The image is downloaded but not yet painted, because the browser is still waiting on render-blocking CSS, JavaScript, a font or an entrance animation.

How to fix Largest Contentful Paint, step by step

1. Get the server answering quickly

Start with Time to First Byte. Make sure full page caching is on, either through your host or a plugin, and that the page you’re testing is actually served from cache. Google’s own guidance treats a TTFB of 0.8 seconds or less as good. If you’re well above that on cached pages, the problem is hosting or a misconfigured cache, and it needs fixing before anything else.

2. Make the LCP image easy to discover

The browser can only start downloading an image once it knows the image exists. A normal image tag in the HTML is found almost immediately. A CSS background image is found only after the stylesheet is downloaded and read. An image inside a slider may not be found until the slider’s JavaScript runs.

• Where you can, use a real image element for the hero rather than a section background.
• Never lazy load the LCP image. WordPress skips lazy loading for the first images on a page and, since version 6.3, adds fetchpriority="high" to the image it thinks is the LCP. Page builders and optimization plugins sometimes override this, so check the HTML.
• If the hero has to stay a background image, preload it. Most good caching plugins let you preload specific images.
• Replace hero sliders with a single strong image. Sliders delay LCP and rarely convert better.

3. Make the image smaller

Resize the image to the size it is actually displayed at, roughly double the width for sharp screens, and no bigger. Serve WebP or AVIF, compress it sensibly, and make sure WordPress outputs a srcset so phones download a phone-sized file instead of the desktop version. For a phone, a hero image rarely needs to be more than about 100 to 200 KB.

4. Clear the render path

Once the image is downloaded, nothing should stop it from being painted. Defer JavaScript that’s not needed for the first screen, generate critical CSS so the top of the page can render before the full stylesheet arrives, and use font-display: swap so text doesn’t wait for fonts. Remove entrance animations from anything above the fold. An element that fades in only counts once it’s visible, so the animation adds straight to your LCP.

5. When the LCP element is text

If your LCP is a heading, the delay is usually render-blocking CSS or a web font. Host fonts locally, load only the weights you use, and preload the one font file used in the hero.

Work through these in order and most WordPress pages move from poor to good without a rebuild. When the theme or builder structure itself is the bottleneck, a redesign on a lighter structure can cost less than months of patches. If you would rather hand it over, my WordPress speed optimization service starts with exactly this breakdown.

The short version

• Identify the LCP element on mobile and desktop separately.
• Check the LCP breakdown and fix the largest of the four parts first.
• Confirm the page is served from cache and TTFB is under about 0.8 seconds.
• Make sure the LCP image is not lazy loaded and has high fetch priority.
• Resize, compress and convert the hero image, and check that srcset works.
• Remove hero sliders and above-the-fold animations.
• Defer non-critical JavaScript and use critical CSS.
• Retest, then watch Search Console over the next 28 days.

You might also find these useful: a WordPress speed checklist that passes Core Web Vitals and how to fix the WordPress white screen of death, step by step.

Common questions

What is a good LCP score?

2.5 seconds or less, measured at the 75th percentile of real visits. Between 2.5 and 4 seconds needs improvement, and anything over 4 seconds is poor.

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

Phones have slower processors and often slower connections, and PageSpeed Insights tests mobile on a throttled mid-range device. Mobile pages also often load desktop-sized images. Check that phones get smaller images and less JavaScript.

Will a caching plugin fix LCP on its own?

It fixes the server part, which is often the biggest. It won’t fix a 2 MB hero image, a slider or a lazy-loaded LCP image. You usually need both.

How long until Search Console shows the improvement?

Field data covers a rolling 28-day window, so expect the report to catch up over about four weeks. Lab tests in PageSpeed Insights show the change immediately.

Ask for a free website review. I’ll tell you what to fix first.