Largest Contentful Paint measures how long it takes for the biggest visible piece of content, usually a hero image or a large heading, to appear on screen. Google considers anything under 2.5 seconds good. In my audits, LCP is the Core Web Vital that WordPress sites fail most often, especially on mobile.
The usual reaction is to install a performance plugin and turn everything on. Sometimes that helps. Often it doesn’t, because the actual cause wasn’t something those settings address. LCP is easier to fix when you break it into parts and deal with each one deliberately.
Step one: find the LCP element
You can’t fix LCP without knowing what the LCP element is. It differs between pages and between mobile and desktop.
The quickest way is PageSpeed Insights. Run a test and scroll to the diagnostics. It shows the “Largest Contentful Paint element” with a snippet of its HTML.
For more detail, use Chrome DevTools. Open the Performance panel, record a page load and look for the LCP marker in the timings track. Clicking it highlights the element on the page.
Common LCP elements on WordPress sites:
- A hero or banner image at the top of the homepage
- The featured image on a blog post
- A product image on WooCommerce product pages
- A large heading or paragraph, on text-heavy pages
- A background image set in CSS, often by page builders
- A slider’s first slide
Write down the LCP element for your most important page types: homepage, a typical post, a service page and, for stores, a product page. They often have different causes.
Step two: break LCP into its four parts
Google describes LCP as the sum of four sub-parts. Thinking about them separately is the most useful idea in LCP optimisation.
- Time to first byte (TTFB). How long until the browser receives the first byte of HTML.
- Resource load delay. Time between TTFB and when the browser starts downloading the LCP resource, usually an image.
- Resource load duration. How long the image itself takes to download.
- Element render delay. Time between the image finishing and it actually appearing on screen.
For text LCP elements, there’s no resource to load, so it’s just TTFB plus render delay.
PageSpeed Insights shows this breakdown in its LCP diagnostics. Whichever part is largest is where to start.
Fixing TTFB
If TTFB alone is more than 800 milliseconds, you have a server problem, and no front-end trick will fix it.
Common causes and fixes:
- No page caching. Every visit runs PHP and queries the database. A page cache, at the server, plugin or CDN level, is the single biggest fix for most WordPress sites.
- Slow hosting. Overcrowded shared hosting can make even cached pages slow. If cached TTFB is still high, the host may be the bottleneck.
- Heavy uncached pages. Pages that bypass the cache, like those with query strings or for logged-in users, need efficient PHP. Look for slow plugins and database queries using Query Monitor.
- Distance. If your audience is in India and your server is in the US, every request crosses the world. A CDN with HTML caching, or hosting closer to your audience, helps a lot.
- Redirect chains. HTTP to HTTPS to www to a trailing slash version adds a round trip each time. Link directly to the final URL.
Fixing resource load delay
This is often the biggest and most overlooked part. The browser can’t start downloading the hero image until it discovers it. If the image is buried in CSS, loaded by JavaScript or marked for lazy loading, discovery happens late.
Don’t lazy load the LCP image
WordPress adds loading=”lazy” to images automatically. Since version 5.9, it tries to skip the first content image, and since 6.3 it adds fetchpriority=”high” to the image it thinks is the LCP element. But themes, page builders and optimisation plugins often override this and lazy load everything, including the hero.
Check the LCP image’s HTML. If it has loading=”lazy”, or a data-src attribute used by a JavaScript lazy loader, that’s a problem. Exclude it from lazy loading in your optimisation plugin, or adjust the theme template.
Add fetchpriority
The fetchpriority=”high” attribute tells the browser to download this image before other resources. If WordPress hasn’t added it, add it in the template:
Only use it on the one image that’s actually the LCP element. Marking several images as high priority defeats the purpose.
Preload CSS background images
When the hero image is a CSS background, the browser only discovers it after downloading and parsing the stylesheet. Preloading lets it start immediately:
If the background differs between mobile and desktop, use imagesrcset and imagesizes, or media attributes, so each device preloads only the right file.
Better still, where possible, use a real img element for the hero instead of a CSS background. It’s discoverable, it supports srcset and it’s easier to optimise.
Avoid JavaScript sliders for the hero
Sliders that build their markup with JavaScript can’t show anything until the script loads and runs. If you must use a slider, choose one that outputs the first slide as plain HTML, or replace it with a static hero. In my experience, the static version usually converts better anyway.
Fixing resource load duration
Once the image download starts, its size and the network determine how long it takes.
- Serve the right size. A 2400-pixel-wide image on a 400-pixel-wide phone screen wastes most of its bytes. WordPress generates multiple sizes and uses srcset, but only if the theme uses proper image functions and the sizes attribute is accurate.
- Use modern formats. WebP is well supported and much smaller than JPEG at similar quality. AVIF is smaller still. WordPress supports both, and optimisation plugins can convert existing images.
- Compress sensibly. Quality around 75 to 82 is usually indistinguishable from higher settings for photos.
- Use a CDN. Images served from a nearby edge location download faster.
A hero image under 150 KB on mobile is a good target. Many sites I audit start at well over 1 MB.
Fixing element render delay
Sometimes the image arrives quickly but doesn’t appear. That’s render delay, usually caused by something blocking the browser from painting.
- Render-blocking CSS. Large stylesheets must download and parse before anything renders. Inlining critical CSS and deferring the rest helps, but test carefully, because poorly generated critical CSS causes flashes of unstyled content.
- Render-blocking JavaScript in the head. Scripts without defer or async block rendering. Defer non-essential scripts.
- Anti-flicker snippets. A/B testing tools sometimes hide the whole page until their script loads. That can add seconds to LCP.
- Fade-in animations. If the hero fades in with CSS or JavaScript, LCP is recorded when it becomes visible, not when it loads. Remove entrance animations from the LCP element.
- Web fonts for text LCP. If the LCP element is text and the font is still loading, the text may be invisible. Use font-display: swap or optional, and preload the main font file.
Measure with real users
Lab tools like Lighthouse use a simulated slow phone on a single test. Real users vary a lot. Google uses field data from real Chrome users, shown at the top of PageSpeed Insights and in Search Console’s Core Web Vitals report.
After making changes, lab scores update immediately, but field data takes up to 28 days to reflect improvements, because it’s a rolling average. Don’t panic if Search Console doesn’t change straight away.
A practical order of work
For most WordPress sites, this sequence fixes LCP:
- Confirm page caching works and TTFB is under about 600 milliseconds for cached pages.
- Identify the LCP element for each key template.
- Make sure it isn’t lazy loaded and has fetchpriority=”high”.
- Make it a real image element if possible, or preload it if it’s a background.
- Resize and compress it, and serve WebP or AVIF.
- Remove render-blocking scripts and entrance animations affecting it.
Work through those in order, measuring after each change, and most sites move from failing to passing without any exotic techniques.
Frequently asked questions
Why is my LCP fine on desktop but poor on mobile?
Mobile tests simulate a slower device and network. Large images, heavy CSS and JavaScript hurt much more on mobile. The LCP element may also differ, for example a different hero image on smaller screens.
Does a page builder make good LCP impossible?
No, but it makes it harder. Builders often use CSS backgrounds, extra wrapper elements and heavy scripts. Most now offer settings to improve this, and careful configuration can pass LCP.
Should I preload my LCP image on every page?
Only where the LCP element is the same image on every load and isn’t discoverable early. Preloading the wrong image wastes bandwidth and can slow down the real LCP.
How much does LCP affect rankings?
Core Web Vitals are one of many ranking signals and rarely decisive on their own. The bigger benefit is user experience: faster pages keep more visitors and convert better.
