Largest Contentful Paint is the Core Web Vital that fails most often on WordPress sites, and it is the one visitors feel most directly. LCP measures when the main content of the page becomes visible: the hero image, the headline block, the product photo. When it is slow, your site feels slow, whatever the other metrics say.
Google’s threshold: under 2.5 seconds is good, over 4 seconds is poor. If PageSpeed Insights is flagging your LCP, do not start toggling random optimization settings. Follow this four-stage checklist in order. Each stage builds on the last, and skipping ahead is why most LCP fixes fail.
The short answer: 1) Identify exactly which element is your LCP. 2) Make the browser discover and download it first (preload, eager-load, fetchpriority). 3) Make the file itself smaller (right size, WebP/AVIF). 4) Remove whatever is blocking it from rendering (slow server response, render-blocking CSS/JS). Measure after each stage.
Stage 1: Identify the LCP Element (Do Not Skip This)
Most failed LCP fixes fail here: people optimize the wrong thing. Before changing anything:
- Run PageSpeed Insights on the affected page.
- In the results, find the “Largest Contentful Paint element” in Diagnostics. PSI names the exact element (an image URL, a heading, a div).
- Note two things: what the element is (image? text block? background?) and when it renders (the LCP timing breakdown shows how much time went to server response vs. resource loading vs. render delay).
Common WordPress LCP elements and what they tell you:
– Hero image → the image pipeline needs work (Stages 2–3).
– Headline text block → the text is waiting on something: usually render-blocking CSS or web fonts (Stage 4).
– Background image on a div → backgrounds cannot be prioritized like <img> tags; consider converting to a real image or preloading (Stage 2).
– Slider/carousel first slide → sliders are LCP killers; the first slide’s image needs eager loading and the slider script must not block it.
Write down your LCP element. Every step below targets it specifically.
Stage 2: Preload It and Load It Eagerly
The browser cannot render what it has not discovered. A huge share of WordPress LCP problems is simply late discovery: the LCP image is buried in markup, injected by JavaScript, or just lazy-loaded, the classic case.
If the LCP element is an image:
– It must have fetchpriority="high" and loading="eager" (never lazy). WordPress 6.3+ adds fetchpriority automatically to the likely LCP image, but page builders and custom themes often bypass this.
– If your optimization plugin lazy-loads it anyway, exclude it (by CSS class, filename, or URL) in your plugin’s lazy-load exclusion settings. We cover the exact settings for LiteSpeed, WP Rocket, and Perfmatters in our guide to fix “LCP image was lazily loaded.”
– Verify in DevTools: the Network tab’s Priority column should show High for this image.
If the LCP element is hard to discover (background image, JS-injected):
– Add a preload hint to your <head>:
html
<link rel="preload" as="image" href="/wp-content/uploads/hero.avif" fetchpriority="high">
– Only preload the actual LCP resource. Preloading five things is the same as prioritizing nothing.
If the LCP element is text: the “resource” blocking it is usually CSS or fonts (Stage 4). But also check: is the text inside content that a script reveals (animations, fade-ins)? Disable entrance animations on above-the-fold content. They delay LCP by definition.
Stage 3: Make the File Smaller (Size and Format)
Once the browser discovers the LCP resource early, the next question is how fast it downloads. For images:
- Serve the right size. A 2400px-wide hero displayed at 800px wastes most of its bytes. Use responsive images (
srcset; WordPress generates these automatically for content images) and pick the correct registered size in your builder. - Use modern formats. WebP is typically 25–35% smaller than JPEG at similar quality; AVIF goes further still. Your caching plugin’s image optimizer or your CDN’s image service can generate these automatically — serve AVIF/WebP with JPEG fallback.
- Compress sensibly. Quality 80–85 for JPEG/WebP is visually identical to 100 for photographic content at a fraction of the size. Do not chase extreme compression on the LCP image itself. Artifacts on the hero are the most visible on the page.
- For text LCP: the “file” is your CSS and fonts. Subset fonts to the character sets you use, limit weights (each weight is a file), use
font-display: swap, and consider hosting fonts locally instead of pulling from Google on every visit.
A note on honesty: image optimization has real but bounded returns. If your LCP is 6 seconds because of a 3-second server response, no image format will save you. Which brings us to Stage 4.
Stage 4: Kill Whatever Is Blocking It
LCP has four sub-parts, and WordPress sites commonly bleed time in two: Time to First Byte (server too slow) and render delay (something blocking the browser from painting).
Fix slow TTFB:
– TTFB is hosting + uncached dynamic work. Enable page caching so repeat visits skip PHP entirely.
– Set up Redis object caching to cut database time on the requests that must run PHP. Our Redis setup guide walks through it.
– Check for slow plugins with Query Monitor; one bad plugin can add seconds to every uncached response.
Fix render-blocking resources:
– CSS: the browser will not paint until stylesheets load. Inline critical CSS (the styles for above-the-fold content) and defer the rest. Caching plugins generate critical CSS automatically — test it, because bad critical CSS breaks layouts visibly.
– JavaScript: scripts in the <head> without defer or async block rendering. Defer non-critical JS; delay third-party scripts (chat widgets, trackers) until user interaction. But test everything. Delaying the wrong script breaks menus and sliders.
– Third-party embeds: that social feed, review widget, or video embed above the fold is render-blocking by nature. Move embeds below the fold, facade them (click-to-load), or remove them.
The order matters within Stage 4 too: fix TTFB first. Shaving render-blocking resources on a page with a 3-second server response is polishing a slow foundation.
Measure After Each Stage
Do not apply all four stages and then test once. After each stage:
- Purge all caches (plugin, CDN, browser).
- Run PageSpeed Insights 2–3 times and take the median — single runs vary.
- Check the LCP element and timing breakdown again. Did the element change? Did the bottleneck move from “resource load” to “server response”?
If LCP improved but is still over 2.5s, the breakdown tells you which stage to revisit. LCP optimization is iterative, not one-shot.
Frequently Asked Questions
What is a good LCP score for WordPress?
Under 2.5 seconds on mobile (which is what Google grades) is “good.” Between 2.5 and 4 seconds “needs improvement”; over 4 seconds is “poor.” Aim for good on your key templates — homepage, top landing pages, top posts — rather than every archive page.
Why is my LCP different on every test?
LCP varies with server load, cache state (warm vs. cold), network conditions, and even the test location. Always compare medians of multiple runs with the same cache state. A single bad run after purging caches is expected — the first visitor rebuilds the cache.
Can a caching plugin fix LCP by itself?
Partially. Page caching fixes the TTFB portion, and file optimization features help with render-blocking resources. But no plugin can identify your LCP element, choose the right image size, or decide your slider is the problem. The checklist above is the thinking the plugin cannot do for you.
My LCP element is a slider. What should I do?
Sliders are among the worst LCP offenders: heavy scripts, multiple large images, animations. The honest fixes, in order of effectiveness: replace the slider with a single static hero image (best); if you must keep it, eager-load only the first slide’s image, lazy-load the rest, and make sure the slider script does not block rendering.
Does lazy loading hurt LCP?
Lazy loading below-the-fold images helps performance. Lazy loading the LCP image hurts it badly — the browser deliberately delays the most important element. This is the single most common WordPress LCP mistake, and it takes minutes to fix once identified.
The Bottom Line
LCP issues feel mysterious until you work the checklist: identify the element, prioritize its discovery, shrink the file, unblock its rendering. In that order, measuring as you go. Most WordPress LCP failures trace to one of a handful of causes: a lazy-loaded hero, a slow server response, or render-blocking bloat. All of them are fixable without exotic tooling. Pair this checklist with our 20-step WordPress performance checklist and your Core Web Vitals will stop being a source of dread.
