If you want to fix LCP on WordPress, do not start by installing another optimization plugin and hoping the score changes. LCP usually improves when you find the exact element Google measures, then remove the delay in front of that element.
That sounds obvious, but it is where many WordPress speed projects go sideways. A homepage may have a large hero image, a slider, a background video, a featured product, or a heading block above the fold. PageSpeed Insights will pick one of those as the Largest Contentful Paint element. If you optimize the wrong asset, the report may barely move.
When we review a slow WordPress page at Webless, we split LCP into a few practical questions. What is the LCP element? How long does the server wait before sending the page? Can the browser discover the hero asset early? Is CSS or JavaScript hiding the element? Does the page builder add work before the main content can appear?
This article walks through that process without turning it into a checklist of random plugin settings.
What LCP actually measures
Largest Contentful Paint measures how quickly the largest visible piece of main content appears in the viewport. Google’s Core Web Vitals documentation says a good LCP should happen within 2.5 seconds from when the page starts loading. The same threshold appears in the web.dev LCP guide, measured at the 75th percentile of visits.
For WordPress sites, the LCP element is often one of these:
- A hero image or banner at the top of a service page.
- Large featured images on blog posts.
- Heading blocks when the page has no large image above the fold.
- WooCommerce product images on product pages.
- Slider images or background images loaded by a page builder.
The browser does not care which plugin you use. It cares how quickly it can request, download, decode, and paint that visible element.
Start by finding the real LCP element
Open PageSpeed Insights, Chrome DevTools, or a Lighthouse report and look for the LCP element preview. Do this before changing cache settings. If the report shows a hero image, your work will look different from a page where the LCP element is a heading.
Here is the quick decision table I use before touching a WordPress site:
| LCP element | Likely problem | First fix to test |
|---|---|---|
| Hero image | Image loads too late or too large | Compress, resize, serve WebP/AVIF, preload only that image, and avoid lazy-loading it |
| Background image | CSS hides the image from early discovery | Move the image into HTML when possible or preload it carefully |
| Heading text | Fonts or render-blocking CSS delay paint | Use font-display, reduce font files, and inline critical CSS |
| Product image | Heavy image, gallery script, or theme layout delay | Optimize the first product image and defer non-critical gallery scripts |
| Slider | JavaScript must run before content appears | Replace the first slide with static HTML or remove the slider from the first viewport |
This table prevents the most common mistake: treating every poor LCP as an image compression issue. Images matter, but they are not the whole story.
Fix server delay before polishing the front end
LCP cannot be fast if the server responds slowly. If Time to First Byte takes one or two seconds, your hero image starts late no matter how well you compress it.
On WordPress, server delay often comes from uncached pages, overloaded hosting, slow database queries, heavy plugin bootstrapping, or a page builder that does too much before the response leaves the server. A cache plugin can hide part of the problem for visitors, but logged-in users, cart pages, search pages, and personalized content may still feel slow.
If the report points to slow server response time, read our guide on how to fix slow server response time in WordPress before spending hours on minor image settings. You may need full-page caching, object cache, cleaner autoloaded options, better hosting, or custom development work that removes expensive logic from the first request.
A simple rule helps here: fix delivery order before decoration. The first byte starts the whole page load. If it arrives late, every later optimization has less room to help.
Do not lazy-load the LCP image
Lazy loading helps below-the-fold images. It hurts when you apply it to the image visitors need to see first.
Many WordPress themes and optimization plugins add lazy loading automatically. That is usually fine for gallery images, blog body images, and product thumbnails lower on the page. The hero image needs different treatment. It should be discoverable early in the HTML, it should not wait for a JavaScript lazy-load library, and it should not sit behind a slider that needs scripts before the first slide appears.
The web.dev Core Web Vitals recommendations make this point clearly: if the LCP element is an image, the browser should be able to discover that URL in the initial HTML response. In WordPress terms, that means the first image should not hide inside late JavaScript, shortcode output, or CSS that only loads after the main stylesheet.
For a hero image, check these details:
- Use the correct image dimensions for the real layout, not the original upload size.
- Serve a modern format such as WebP or AVIF when your image plugin supports it.
- Keep the image out of lazy loading when it appears above the fold.
- Use a preload only for the actual LCP image, not every large image on the page.
- Add width and height so the browser can reserve space before the image paints.
If your site uses ShortPixel, our article on optimizing images properly with ShortPixel covers the image side in more detail. LCP work goes further, but image delivery still matters.
Use preload and fetch priority carefully
Preloading the right image can improve LCP. Preloading the wrong assets can make the page slower because the browser spends bandwidth on files that do not help the first viewport.
Use preload when the browser would otherwise discover the LCP image too late. This often happens with background images, sliders, or complex template output. Use it with restraint. A service page usually needs one main hero asset prioritized, not five banners and three fonts competing at once.
Fetch priority can also help when the LCP image is present in the HTML. In custom theme work, we may add fetchpriority="high" to the main image and keep lazy loading off that specific asset. In a plugin-only setup, the same result depends on what your performance plugin or theme exposes.
The point is not to memorize every attribute. The point is to make the browser do the obvious thing first: request the main visible asset early.
Clean up render-blocking CSS and JavaScript
Sometimes the LCP resource downloads quickly, but it still does not appear. The web.dev article on LCP misconceptions calls this render delay. The file may be ready, while CSS, JavaScript, animation, or a hidden state keeps it off screen.
This problem appears a lot on WordPress sites with large page builders. The visible hero section may depend on several CSS files, animation libraries, icon packs, font files, tracking scripts, and builder scripts. Each one can add friction before the main content paints.
Useful fixes include:
- Remove above-the-fold animations that delay the first paint.
- Inline critical CSS for the first viewport when your setup supports it.
- Delay non-essential JavaScript, but test menus, forms, and tracking after each change.
- Reduce unused builder widgets and global add-ons.
- Load fewer font weights and avoid heavy icon libraries when plain SVG icons would work.
If Elementor powers the page, also read our Elementor speed optimization guide. Elementor can produce fast pages, but it rewards clean sections, fewer add-ons, and disciplined template design.
Do not fix LCP by breaking the page
A poor LCP score can push people into risky settings. They delay too much JavaScript, remove fonts without checking brand impact, hide sections on mobile, or switch off scripts that forms and checkout pages need.
That is not optimization. That is moving the problem somewhere else.
Good LCP work protects the page goal. Lead-generation pages still need the form to work. WooCommerce pages still need variation selectors, cart fragments, payment scripts, and trust elements. Service pages still need the hero to explain the offer clearly.
This is why we test the public page after every meaningful change. We check the fast path and the conversion path. A green score has little value if the visitor cannot submit the form or understand the offer.
When a plugin is enough and when development is needed
A good caching and optimization plugin can handle many LCP problems. It can cache HTML, minify assets, delay scripts, generate critical CSS, preload key files, and improve image formats. For many small WordPress sites, that gets the page close to the target.
However, some sites need deeper work. A plugin cannot always fix a bloated theme template, slow custom query, overloaded WooCommerce layout, poor hero markup, or builder setup that ships too much code to every page. In those cases, the cleanest fix is code-level work, not another checkbox.
That is where WordPress speed optimization and performance-focused WordPress development overlap. The best fix may be a lighter template, a cleaner image component, a narrower script loading rule, or a custom section that replaces a heavy builder block.
If you are comparing options, our guide to WordPress speed optimization cost explains when a plugin setup, audit, or developer-led fix makes sense.
How to fix LCP on WordPress: the practical workflow
Here is the order I would follow to fix LCP on WordPress on a real site:
- Run PageSpeed Insights and confirm the LCP element.
- Check whether field data and lab data tell the same story.
- Look at TTFB before changing front-end settings.
- Confirm that the LCP image or heading appears in the initial HTML.
- Remove lazy loading from the above-the-fold image.
- Resize and compress the asset that actually becomes the LCP element.
- Prioritize only the critical hero asset and font files.
- Reduce render-blocking CSS and scripts that affect the first viewport.
- Retest the page in mobile and desktop views.
- Check forms, menus, consent banners, and checkout behavior after optimization.
That order keeps the work grounded. You do not need to guess. You need to follow the path the browser takes before it paints the main content.
How this connects to SEO
Core Web Vitals are not a magic ranking switch. Relevance, quality, intent, links, brand signals, and helpful content still matter. However, page experience can make the difference when multiple results answer a search well.
Google’s page experience guidance says its systems generally evaluate page experience on a page-specific basis. That matters for WordPress sites because one slow landing page can underperform even if the rest of the site feels fine.
For business pages, LCP also affects human behavior. If the first useful content appears late, visitors hesitate. Some leave before they understand the offer. Others wait, but the delay makes the site feel less trustworthy. A faster hero section gives the page a better chance to earn the click, the read, and the enquiry.
Final thought
To fix LCP on WordPress, start with evidence. Find the element. Check the server. Make the main asset discoverable. Remove the render delay. Then retest the page as a visitor, not only as a score report.
If the page still struggles after the obvious plugin settings, the problem may sit in the theme, builder, hosting, or template logic. Webless can review that path through a Core Web Vitals report or a focused speed optimization project, then fix the part that actually slows down the page.