How to Improve LCP on WordPress

Largest Contentful Paint (LCP) measures when the largest image, text block, or video visible in the initial viewport is rendered. A good target is 2.5 seconds or less at the 75th percentile, separately for mobile and desktop.

Do not install another optimization plugin before identifying the LCP element and its delay. A plugin can reduce one bottleneck while creating another.

Measure the real page and element

Start with PageSpeed Insights field data, Search Console’s affected URL groups, and your own real-user monitoring if available. Then use a Lighthouse trace or Chrome DevTools Performance panel on representative templates:

• Homepage.
• Article or page.
• Product or category archive.
• Logged-out mobile visit.

The LCP element can differ by template, viewport, experiment, or visit. It may be a hero <img>, a CSS background, a heading, or a featured image inserted by a page builder.

The PageSpeed Insights versus Search Console guide explains why a fresh lab test can differ from field results.

Break LCP into four parts

Use this diagnostic model:

1. TTFB: navigation until the first HTML byte.
2. Resource load delay: TTFB until the browser starts the LCP resource.
3. Resource load duration: time spent transferring the resource.
4. Element render delay: resource completion until the element is painted.

If the LCP is text, there may be no separate image transfer, but CSS and font availability can still delay rendering.

Optimize the largest component first. Compressing the hero image will not solve a two-second uncached TTFB.

Reduce WordPress TTFB

Measure an anonymous, cacheable page from locations near your audience. For a public content page, a full-page cache should normally serve HTML without booting WordPress, every plugin, and the database on every visit.

Check:

• Page-cache hit and miss headers.
• PHP-FPM saturation and slow logs.
• Slow database queries and oversized autoloaded options.
• Remote API calls during page generation.
• Object cache effectiveness for dynamic workloads.
• Origin location and CDN edge-cache policy.

Do not cache personalized or authenticated responses as public HTML. Define bypass rules for sessions, carts, previews, and administrative paths.

Remove unnecessary plugins and measure expensive hooks. Faster hardware can help, but it should not hide unbounded queries or synchronous external calls.

Make the LCP image discoverable

The browser should discover the hero image in the initial HTML:

<img
  src="/uploads/hero-1280.webp"
  srcset="
    /uploads/hero-640.webp 640w,
    /uploads/hero-960.webp 960w,
    /uploads/hero-1280.webp 1280w
  "
  sizes="(max-width: 760px) 100vw, 1200px"
  width="1280"
  height="720"
  alt="Descriptive text"
  fetchpriority="high"
>

Do not lazy-load the current LCP image. WordPress may add responsive image attributes and loading optimizations automatically, while themes, builders, CDN plugins, and lazy-load plugins can rewrite them. Inspect the final generated HTML rather than the template alone.

Use fetchpriority="high" sparingly for the actual high-priority image. Too many high-priority resources compete with one another.

A CSS background image is discovered only after CSS arrives and is applied. Prefer semantic <img> or <picture> markup for meaningful hero content. If a background is unavoidable, a precise preload may help, but test that it does not download an unused desktop image on mobile.

Serve the right image bytes

Resize the source to the largest rendered requirement; do not send a 4000-pixel photograph into a 700-pixel slot. Use responsive srcset and an accurate sizes attribute so the browser chooses a suitable candidate.

Choose WebP or AVIF when supported by the workflow and compare visual quality. Aggressive conversion is not automatically smaller for every image. Keep explicit dimensions or an aspect-ratio so the page reserves space and avoids CLS.

Confirm CDN cache headers and cache hit status. Image optimization on every first request can add origin CPU spikes; pre-generate common sizes or use a well-sized image service.

Remove resource and render delay

The LCP request starts late when the browser must wait for JavaScript, a slider, or a stylesheet to reveal the resource. It paints late when overlays, animations, web fonts, or large render-blocking styles delay visibility.

Practical fixes:

• Render the initial hero in server HTML.
• Avoid carousel logic for the first above-the-fold image.
• Inline only genuinely critical CSS and keep it small.
• Defer noncritical scripts and remove unused page-builder assets.
• Load analytics and chat based on clear product needs.
• Use font-display deliberately and preload only the font files used above the fold.
• Avoid entrance animations that keep the LCP element transparent.

Optimize third-party code by removing it, delaying it, or limiting where it loads—not merely by bundling it differently.

Check WordPress-specific conflicts

Temporarily test on staging with one optimization layer at a time. Multiple cache, minification, lazy-load, and CDN tools can each rewrite the same markup.

Look for:

• The LCP image receiving loading="lazy".
• Duplicate preload tags.
• Mobile receiving the desktop hero.
• CSS aggregation delaying background discovery.
• A cookie banner becoming the LCP element.
• A slider replacing the image after load.
• Cache variation that creates a low hit ratio.

Purge only the affected cache layers after a controlled change, then retest cold and warm visits.

Verify in lab and field

After deployment:

1. Confirm the intended LCP element in several mobile lab runs.
2. Compare the four LCP subparts before and after.
3. Check the final HTML, request priority, cache status, and image candidate.
4. Watch real-user LCP by template and device.
5. Mark the release date and allow the 28-day CrUX window to roll forward.

Track regressions with a performance budget. LCP optimization is an operating discipline, not a one-time plugin configuration.

Common mistakes

The usual mistakes are lazy-loading the hero, preloading several competing images, optimizing bytes while ignoring TTFB, testing only the homepage, trusting a single Lighthouse run, and stacking plugins without inspecting final HTML.

If a backend failure appears while investigating slow PHP responses, use the Nginx and PHP-FPM 502 guide rather than masking it with longer timeouts.

Frequently asked questions

Should I preload the WordPress hero image?

Only after confirming it is the LCP resource and starts late. Correct HTML discovery and fetchpriority may be sufficient; an unnecessary preload can compete with CSS, fonts, or the actual mobile image.

Can one performance plugin fix LCP?

Only when its change targets the measured bottleneck. A cache plugin may improve TTFB, but it cannot by itself correct an oversized hero, late JavaScript discovery, or a render-blocking theme.

Official references

• Optimize Largest Contentful Paint
• WordPress performance optimization handbook

Have a question about this guide or an idea for a technical collaboration? Contact Bakry through the Dev Hub.