Largest Contentful Paint is the single hardest Core Web Vital to fix on WordPress, and it's the one most likely to keep your page out of the "good" bucket. LCP measures how long it takes the biggest visible element above the fold — usually a hero image, a headline, or a background — to finish rendering. Google's threshold is 2.5 seconds or less at the 75th percentile of real visits. Plenty of WordPress sites that feel fast on a wired connection in your office are sitting at 4 or 5 seconds for actual mobile visitors.

The reason LCP is stubborn is that it's not one problem. It's a chain of four delays stacked end to end, and a slow LCP can come from any link in that chain. Fixing it means finding which link is broken for your page, not blindly installing a cache plugin and hoping.

First: find out what your LCP element actually is

Don't guess. Open Chrome DevTools, go to the Performance panel, and record a page load with mobile CPU and network throttling turned on (4x CPU slowdown, "Slow 4G"). In the timeline, the LCP marker tells you the exact element and its timestamp. Alternatively, run the page through PageSpeed Insights — the diagnostics section names the LCP element and breaks the time down into four sub-parts: time to first byte, resource load delay, resource load time, and element render delay.

Those four sub-parts are the chain. Whichever one is largest is where your effort should go. A site bottlenecked on TTFB needs a completely different fix from one bottlenecked on render delay, and treating them the same is why so many "speed up WordPress" checklists fail.

Link 1: Time to First Byte (your host and your cache)

If TTFB alone is over 600–800ms, nothing downstream can save you. This is almost always WordPress generating the page fresh on every request — running PHP, hitting MySQL, loading every active plugin — because there's no page cache.

Add full-page caching. On shared hosting, a plugin like WP Rocket, LiteSpeed Cache (free, if your host runs LiteSpeed), or W3 Total Cache turns a 700ms dynamic response into a 50–150ms static one.
Consider your host. Managed hosts like Kinsta, WP Engine, and Cloudways run server-level caching (NGINX FastCGI or Varnish) that beats any plugin. Budget shared hosting with an overloaded server will give you a slow TTFB no plugin can fully rescue.
Put a CDN in front. Cloudflare's APO for WordPress, or any CDN that caches HTML, serves the cached page from an edge node physically close to the visitor. This matters enormously for geographically distant traffic, where round-trip latency alone can add hundreds of milliseconds.

Get TTFB under roughly 200ms for cached pages and this link of the chain effectively disappears.

Link 2: Resource load delay (let the browser discover the image early)

This is the most common WordPress-specific LCP killer, and it's invisible unless you look for it. If your LCP element is an image, the browser can't start downloading it until it discovers the <img> tag in the HTML and decides it's worth fetching. Three WordPress defaults sabotage this:

Lazy-loading the hero image. WordPress adds loading="lazy" to images automatically. That's great for below-the-fold images and catastrophic for your LCP image, because the browser deliberately delays it. Your above-the-fold hero must not be lazy-loaded. Most performance plugins (WP Rocket, Perfmatters) let you exclude the first image, or you can add it to a "skip lazy load" list by class or filename.
No fetchpriority hint. Add fetchpriority="high" to the LCP image so the browser pulls it ahead of other downloads. WordPress 6.3+ tries to do this automatically for the first large image, but page builders and custom hero sections frequently break the detection, so verify it's actually on the right element.
The image is a CSS background. Backgrounds set in CSS are discovered late, only after the stylesheet parses. If your hero is a background-image, add a <link rel="preload" as="image"> in the <head> so the browser starts fetching it immediately.

Link 3: Resource load time (make the image smaller)

Once the browser starts downloading, the file size and format decide how long it takes. WordPress sites routinely ship 400KB–1.5MB hero JPEGs that should be 40–80KB.

Serve modern formats. WebP is roughly 25–35% smaller than JPEG at the same quality; AVIF is smaller still. Plugins like ShortPixel, Imagify, or Converter for Media convert and serve these automatically with a fallback.
Stop serving oversized images. A hero displayed at 800px wide should not be a 2400px file. Use responsive srcset (WordPress generates this, but page builders often override it with a single huge source) so phones get a phone-sized image.
Use an image CDN for on-the-fly resizing. Cloudflare Images, Bunny Optimizer, or Jetpack's free Site Accelerator resize and reformat per device without you regenerating thumbnails.

Link 4: Render delay (clear the render-blocking pile-up)

If the image downloads quickly but still paints late, the browser is blocked from rendering by CSS and fonts. This link dominates on bloated theme-and-page-builder stacks.

Eliminate render-blocking CSS. Generate "critical CSS" — the minimal styles needed for the above-the-fold view — inline it, and load the rest asynchronously. WP Rocket, LiteSpeed Cache, and Perfmatters all do this. Be aware it can cause a flash of unstyled content if misconfigured, so test the result visually.
Fix web fonts. Custom fonts loaded from Google's CDN add a DNS lookup, a connection, and a download before text can paint with the right typeface. Self-host your fonts, add font-display: swap so text shows immediately in a fallback, and preload the one or two font files used above the fold.
Trim the plugin and builder bloat. Elementor and Divi inject sizeable CSS and JavaScript. Use a tool like Perfmatters or Asset CleanUp to dequeue assets on pages that don't need them. Fewer render-blocking requests means an earlier paint.

Measure where it counts

Lab tools like PageSpeed Insights are for diagnosis, but Google ranks on field data — the Chrome User Experience Report, gathered from real visitors over a rolling 28-day window. That means two things. First, after you ship a fix, the score in Search Console's Core Web Vitals report can take three to four weeks to reflect it. Second, a perfect lab score with a poor field score usually points to a slow database, a heavy third-party script (chat widgets, ad networks, analytics), or real-world mobile devices struggling — none of which throttled lab tests fully capture.

Work the chain in order: fix TTFB with caching, make sure the hero image is eagerly discovered and prioritized, shrink and modernize it, then clear render-blocking CSS and fonts. Re-measure after each change so you know which link you actually moved. Done in that sequence, getting a WordPress page under the 2.5-second LCP threshold is a methodical job, not a lucky one.

Largest Contentful Paint: Fixing LCP on WordPress