If your WordPress site is failing LCP, you're not alone. Largest Contentful Paint is the Core Web Vitals metric that trips up more sites than any other — and WordPress makes it surprisingly easy to get wrong, even on sites that look fast in everyday use.
LCP measures how long it takes for the largest visible element on the page to load. For most sites, that's a hero image, a headline, or a banner. Google wants it under 2.5 seconds. Anything over 4 seconds is considered poor — and that's where most WordPress sites end up after a few years of plugins, theme updates, and good intentions.
Here's what's actually causing it, and what to do about it.
Slider Revolution is probably hurting you
If your site uses Slider Revolution — or any full-featured slider plugin — there's a reasonable chance it's your biggest LCP problem.
Slider Revolution loads a significant amount of JavaScript and CSS before the page renders anything visible. On a typical WordPress install, it's not uncommon to see 400-600KB of slider assets loading before your hero content appears. That alone can push LCP past 4 seconds on mobile.
Version 7 makes this significantly worse. Slider Revolution v7 switched its rendering engine to canvas-based output, which means the slider content is drawn programmatically by JavaScript rather than rendered as standard HTML elements. The practical consequence: the entire JavaScript bundle has to download, parse, and execute before anything in the slider appears on screen. There is no way to defer this loading. Unlike older versions where you could lean on the "Plugin Load Method" setting to restrict scripts to pages that use the slider, v7's canvas architecture means the initialization is blocking by design. If you're on v7 and your slider is your hero element, your LCP will suffer regardless of what your caching plugin is doing.
The fix depends on how much you're actually using it:
If the slider is purely decorative and you could replace it with a static image, do that. A well-optimized WebP image at the right dimensions will load in a fraction of the time and deliver the same visual impact for most visitors. For most marketing sites, this is the right call — sliders have poor conversion rates anyway.
If you're on an older version of Slider Revolution and genuinely need to keep it, make sure it's set to load its assets only on pages where it's actually used. In the plugin settings, look for "Plugin Load Method" and switch it to "On pages with Slider." This won't help you on v7, but on earlier versions it prevents the plugin from injecting scripts on every page of your site.
If you're on v7 and the slider is non-negotiable, the most realistic path is to replace the above-the-fold area with a static image or CSS animation and push the Slider Revolution instance below the fold where it no longer competes for LCP. It's a workaround rather than a fix, but it's the only lever available given how v7 loads.
Lazy loading your hero image is actively making things worse
This is the counterintuitive one that trips up a lot of developers.
Lazy loading tells the browser: don't load this image until it's near the viewport. That's a smart optimization for images below the fold. For your hero image — the one that's almost certainly your LCP element — it's the opposite of what you want.
WordPress added loading="lazy" as a default on images starting in version 5.5. For most images, that's a good thing. But the browser applies it indiscriminately, which means your hero image often gets lazy loaded even though it's the first thing visible on the page.
To fix this, find your hero image in your theme or page builder and explicitly add loading="eager" and fetchpriority="high" to the image tag:
<img src="your-hero-image.webp" alt="Your hero alt text" loading="eager" fetchpriority="high" width="1200" height="600" />
If you're using a page builder like Elementor or Divi, look for the image settings in the hero section — many builders now expose a "lazy load" toggle that you can disable per-element. Turn it off for anything above the fold.
For themes that hardcode the hero image through PHP, you'll need to filter the image output or edit the template directly. The key attribute is fetchpriority="high" — this tells the browser to prioritize fetching this image in the earliest possible render pass.
Your LCP image isn't preloaded
Even with fetchpriority="high" on the image tag, the browser still has to discover the image by parsing the HTML. If your hero image is set as a CSS background rather than an <img> tag, the browser won't discover it until CSS is parsed — which is even later.
The solution is a preload hint in the <head>:
<link rel="preload" as="image" href="/your-hero-image.webp" type="image/webp" />
This tells the browser about the image before it even starts parsing the page body. For sites where the hero is a CSS background image, this can shave a full second off LCP.
In WordPress, you can add preload hints through your theme's functions.php using wp_head, or through a performance plugin that supports resource hints. If you're using a caching plugin like WP Rocket or LiteSpeed Cache, check whether they have a "preload key requests" or "critical images" setting — many do.
Render-blocking resources are delaying everything
LCP doesn't just measure when the image loads — it measures when it's painted to the screen. If there are render-blocking scripts or stylesheets in your <head>, the browser can't paint anything until they finish loading and executing.
The most common culprits on WordPress sites:
Google Fonts loaded synchronously. If your theme loads Google Fonts with a standard <link> tag, it's blocking render. Switch to font-display: swap and load the font stylesheet with rel="preconnect" rather than a blocking link. Better yet, self-host your fonts using a plugin like OMGF.
Theme or plugin CSS loaded in the <head> without media attributes. A stylesheet loaded without a media attribute is assumed to be render-critical and blocks painting. Most WordPress themes load everything in the head regardless of whether it's needed above the fold.
JavaScript not marked as defer or async. Any script in the <head> without defer or async blocks parsing entirely. Check your theme's functions.php and any plugins that enqueue scripts — everything non-critical should be deferred.
A fast way to identify render-blocking resources: run your URL through PageSpeed Insights and look at the "Eliminate render-blocking resources" opportunity. It will list exactly which files are blocking render and how much time each one is costing you.
Your server is slow before any of this matters
If your Time to First Byte (TTFB) is over 600ms, fixing lazy loading and preloading will help at the margins, but your LCP will still struggle. The browser can't paint your LCP element until it receives the HTML from the server.
Common causes of slow TTFB on WordPress:
- No page caching, so every request hits PHP and the database
- Hosting on a shared server with limited resources
- WooCommerce or heavy plugins running on every page request
- No object caching (Memcached or Redis) for database queries
The quickest fix is a page caching plugin if you don't already have one. WP Rocket, W3 Total Cache, and LiteSpeed Cache all work well depending on your host. If you're on managed WordPress hosting (WP Engine, Kinsta, Flywheel), caching is usually handled at the server level — in that case, slow TTFB is more likely a hosting tier or plugin problem.
After you fix it, verify the fix actually landed
This is where most optimization workflows fall apart. You make a change, check PageSpeed Insights an hour later, and either the score improved or it didn't — and you're not sure why.
A few things make verification unreliable on its own:
PageSpeed Insights pulls from a cache, so a freshly deployed change may not be reflected immediately. CDN caching can mean your change is live on the origin server but not yet propagated. And sometimes a fix addresses one LCP bottleneck but reveals a second one that was previously hidden behind it.
This is exactly what we built Evalta AI to handle. After you make a change, Evalta re-scans the page and checks whether the specific issue you addressed has actually resolved. If LCP is still failing, it diagnoses why the change didn't move the needle — whether that's a caching issue, a second bottleneck that emerged, or a fix that was applied to the wrong element. You get a specific answer rather than another round of guessing.
If you're managing performance across multiple client sites, having that verification step built into the workflow makes client reporting a lot cleaner. You're not just saying "I made some changes" — you're showing exactly what was fixed and confirming it worked.
LCP is one of the more satisfying Core Web Vitals to improve because the fixes are usually concrete and the results show up clearly in the data. The hard part is knowing which fix to make first and confirming it stuck. Start with the hero image — that's where most of the time goes — and work down from there.