How to Reduce Largest Contentful Paint (LCP) on WordPress

Largest Contentful Paint problems on WordPress are often blamed on one thing: the hero image. Sometimes that is correct. Often it is not.

LCP measures how long it takes for the largest visible image or text block in the initial viewport to render. Google considers 2.5 seconds or less good, measured at the 75th percentile of page visits. A WordPress page can miss that target because the server responds slowly, the browser discovers the LCP resource too late, the image or font takes too long to download, or CSS and JavaScript delay rendering after the resource is already available.

The fix must match the cause: image compression cannot solve slow PHP, and faster hosting cannot fix a hero hidden by JavaScript.

What Is a Good LCP Score?

Google’s current thresholds are:

For Core Web Vitals assessment, Google evaluates the 75th percentile of real-user visits. A single Lighthouse run can help diagnose a page, but field data is what tells you how real visitors are experiencing LCP over time.

If you need a broader explanation of field data, lab data, and the three Core Web Vitals, see Tenfic’s Core Web Vitals guide and Google PageSpeed Insights guide.

First: Find the Actual LCP Element

Do not optimize the hero image just because it looks large.

Run the page through PageSpeed Insights or Chrome DevTools and identify the element reported as Largest Contentful Paint. Depending on the page, it might be:

• the hero image;
• a featured image;
• a large heading or text block;
• a poster image for a video;
• a CSS background image;
• another large above-the-fold element.

Test the failing template because different page types can have different LCP elements and causes.

Break LCP Into Four Parts Before Fixing It

Google’s current LCP optimization guidance breaks the metric into four subparts:

1. Time to First Byte (TTFB): how long the browser waits for the initial HTML response.
2. Resource-load delay: how long the browser waits before it starts requesting the LCP resource.
3. Resource-load duration: how long the LCP resource takes to download.
4. Element-render delay: how long the browser waits to display the LCP element after the resource is available.

Google’s LCP optimization guide recommends minimizing the two delay portions so the HTML document and LCP resource spend more time loading and less time waiting.

1. Reduce TTFB With Page Caching and Better Hosting

If the initial HTML arrives late, every later LCP step starts late too.

On WordPress, high TTFB commonly comes from uncached page generation, slow hosting, expensive database work, excessive plugin processing, external API calls, or overloaded server resources.

Start with full-page caching for pages that can be cached. Cached HTML can often bypass much of the PHP and database work required to generate the page on every request. WordPress’s own performance documentation recommends caching as one of the highest-impact performance improvements.

If TTFB is still high after caching, inspect:

• server CPU and memory limits;
• PHP performance and version;
• slow database queries;
• large autoloaded options;
• uncached logged-out traffic;
• remote API calls during page generation;
• plugin or theme code that executes on every request.

Do not try to solve server latency by compressing the hero image. The browser cannot request that image until it receives enough of the page to discover it.

2. Make the LCP Image Discoverable in the Initial HTML

For an image-based LCP, the browser should discover the image as early as possible.

The best case is a normal <img> element with its src or srcset present in the initial HTML. Problems appear when a theme, slider, page builder, or JavaScript component adds the image later, stores its URL in a data attribute, or waits for a script before rendering the hero.

Check the initial page source. If the LCP image URL is not available there, the browser cannot request it immediately.

Where practical, use an actual image element for critical hero media rather than injecting it with JavaScript.

3. Never Lazy-Load the LCP Image

Lazy loading is useful for images below the fold. It is usually harmful for the LCP image because it intentionally delays loading until the browser determines that the image is needed.

Google explicitly recommends against lazy-loading the LCP resource. The above-the-fold LCP image should load eagerly.

Modern WordPress includes image-loading heuristics and can apply fetchpriority="high" to an image it considers likely to become the LCP element. WordPress Core introduced this behavior to improve image LCP performance, so avoid optimization plugins or custom code that blindly adds loading="lazy" back to every image.

Check the rendered HTML if you suspect an optimization plugin, CDN, theme, or page builder is overriding WordPress’s loading behavior.

4. Use High Fetch Priority Carefully

fetchpriority="high" tells the browser that an image deserves higher loading priority. It can reduce resource-load delay when applied to the real LCP image.

Do not add high priority to every above-the-fold image. If several resources are all marked high priority, they compete with each other and the hint becomes less useful.

Use it for the most important image, then verify the network waterfall to confirm the LCP request starts early.

5. Optimize the LCP Image Without Making It Blurry

Once the resource starts early, reduce how long it takes to transfer.

For a WordPress hero or featured image:

• upload an image close to the maximum rendered dimensions instead of a huge original;
• use responsive srcset and sizes so smaller screens do not download desktop-sized images;
• use efficient formats such as WebP or AVIF where they fit your image workflow;
• compress the image to a sensible visual-quality level;
• remove unnecessary metadata when your image pipeline supports it;
• avoid serving a 2500-pixel image in a 900-pixel container unless the layout genuinely needs that resolution.

File size matters, but do not optimize it in isolation. Web.dev notes that shortening image download time may not improve total LCP if the browser still waits on JavaScript or rendering afterward.

6. Be Careful With CSS Background Images in the Hero

A CSS background image can become the LCP element, but the browser may discover it later because it first needs to download and parse the stylesheet that references it.

If the design allows it, a semantic <img> or <picture> element is often easier for the preload scanner to discover early.

If the hero must remain a CSS background image, consider preloading the exact LCP asset when testing shows resource discovery is the bottleneck. Do not preload every large image on the page; unnecessary preloads can create network contention.

7. Reduce Render-Blocking CSS Above the Fold

An optimized LCP image can finish downloading and still wait before appearing.

Large stylesheets, chained CSS files, or CSS generated by themes and page builders can delay the first render. Use Chrome DevTools or PageSpeed Insights to determine whether render-blocking resources are materially delaying the LCP element.

Useful fixes include:

• removing unused theme or plugin CSS where practical;
• avoiding duplicate framework styles;
• reducing large global stylesheets;
• delivering critical above-the-fold styles efficiently;
• loading non-critical styles later when doing so does not cause layout shifts or broken rendering.

Do not aggressively defer CSS without visual testing. A fast LCP is not useful if the page flashes unstyled content or shifts after load.

8. Stop JavaScript From Delaying the LCP Element

JavaScript affects LCP when it blocks the main thread, inserts the LCP element late, or controls whether the element is visible.

Common WordPress examples include:

• sliders that wait for JavaScript initialization;
• hero sections with entrance animations;
• page-builder effects that start with opacity: 0;
• A/B testing scripts that hide content while choosing a variant;
• large JavaScript bundles executing before the browser can paint;
• client-side components that generate the hero after page load.

For the critical above-the-fold section, prefer HTML that can render immediately. Delay non-essential interaction and marketing scripts where possible, and remove entrance effects from the actual LCP element if they postpone visibility.

9. Optimize Fonts When Text Is the LCP Element

Not every LCP problem is an image problem. A large hero heading can be the LCP element.

If that text depends on a web font, its render timing may be affected by font discovery and download.

For critical fonts:

• serve only the weights and styles you actually need above the fold;
• use modern compressed font formats such as WOFF2;
• preload only genuinely critical font files;
• avoid loading multiple font families before the hero renders;
• choose an appropriate font-display strategy for the design.

Check whether the custom font is actually responsible before adding preloads. Too many font preloads can compete with the LCP image and other critical resources.

10. Audit the Theme, Page Builder, and Plugins Around the Hero

The number of WordPress plugins does not determine LCP by itself. What matters is what runs on the affected request and what it adds above the fold.

Inspect components responsible for:

• hero sliders;
• popup initialization;
• animation libraries;
• consent interfaces;
• page-builder frontend assets;
• analytics and advertising scripts;
• image optimization and lazy-loading behavior;
• dynamic personalization.

Disable or replace a component only after testing it on staging. Tenfic’s guide on how many WordPress plugins are too many explains why plugin workload is more important than the raw plugin count.

11. Use a CDN When Network Distance Is Part of the Problem

A CDN can reduce transfer distance for images, CSS, JavaScript, fonts, and sometimes cached HTML. That can improve LCP for visitors far from the origin server.

But a CDN does not fix late discovery or render delay. If the LCP image waits 1.5 seconds before its request starts, moving the file closer to the user addresses the wrong subpart.

Measure the waterfall before and after enabling CDN delivery so you know whether resource-load duration or TTFB actually improved.

12. Retest the Same Template and Validate Field Data

After making a change, retest the same URL under comparable conditions.

Use:

• PageSpeed Insights for field Core Web Vitals plus a Lighthouse diagnostic run;
• Chrome DevTools Performance and Network panels to inspect the LCP element, request timing, priority, and render work;
• Search Console Core Web Vitals for groups of URLs with similar field-data problems;
• real-user monitoring if the site has enough traffic and you need page-level attribution.

Do not expect CrUX field data to update immediately after a deployment. It represents a rolling 28-day window, so lab improvements can appear before field status changes.

For a wider troubleshooting workflow, see Why Is My Website Slow? 12 Common Causes and How to Fix Them.

A Practical LCP Fix Order for WordPress

Use this order instead of enabling every optimization at once:

1. Identify the real LCP element.
2. Check TTFB.
3. Confirm the LCP resource is discoverable in initial HTML.
4. Remove lazy loading from the LCP image.
5. Check request priority and resource-load delay.
6. Optimize image or font transfer size.
7. Inspect render-blocking CSS and JavaScript.
8. Remove hero animations or scripts that delay visibility.
9. Audit theme, builder, and plugin output around the LCP element.
10. Retest and compare the LCP subparts again.

This order helps you find the bottleneck instead of changing multiple variables and guessing which one worked.

Related guides: Core Web Vitals guide and Google PageSpeed Insights guide.

Conclusion

Reducing LCP on WordPress is not mainly about installing a performance plugin or making every image smaller. It is about getting the largest above-the-fold element discovered early, loaded quickly, and rendered immediately.

Start by identifying the LCP element and its slowest subpart. Fix server response if TTFB is high. Fix discovery and priority if the resource starts late. Optimize the file if transfer time is high. Remove CSS, JavaScript, animation, or font delays if the resource is ready but the element still renders late.

That approach produces more reliable improvements than applying a generic optimization checklist to every WordPress site.