Search Console flags your pages with “LCP issue: longer than 2.5s” — real visitors are waiting too long to see your main content. The LCP issue Core Web Vitals fix starts with understanding what LCP measures: the time from a visitor requesting the page until the largest visible element (usually the hero image or main headline) finishes rendering. Google’s line is 2.5 seconds at the 75th percentile of real Chrome visits. This 2026 guide shows you how to find what is slowing LCP down and fix it in order of impact.
First, an important distinction. The LCP row in Search Console is field data — a rolling 28-day average of real users on real devices and networks — not a lab test. Your Lighthouse score can look fine while field LCP fails, because lab tests run on fast connections with warm caches. Trust the field data: it is what Google’s page experience signal actually uses. Each example URL in the report represents a group of similar pages, so you usually fix the template once and clear the whole group.
What Causes Slow LCP
- Oversized hero image: a 1.5–2 MB hero is the single most common cause — often lazy-loaded by the theme, which is exactly backwards.
- Slow server response (TTFB): if the server takes 2 seconds to answer, LCP cannot possibly beat 2.5 seconds.
- Render-blocking CSS and JavaScript: stylesheets and head scripts the browser must download before it can paint anything.
- No preload on the LCP image: the browser discovers the hero image late, after parsing CSS and fonts.
- Web fonts blocking text: the LCP element is often a headline, and slow fonts delay it.
- Client-side rendering: JavaScript frameworks that build the page in the browser push LCP late.
How to Fix the LCP Issue: 8 Steps
Step 1: Identify the LCP element
Run the failing URL through PageSpeed Insights and read the Diagnostics section — it names the exact LCP element (usually an <img>). Knowing whether your LCP is an image or a text block decides everything that follows. Do this on mobile first: mobile field data fails far more often than desktop.
Step 2: Optimise the hero image
Resize the image to the largest size it actually displays at (rarely more than 1600px wide), compress it, and serve it as WebP or AVIF — typically 25–35% smaller than JPEG at equal quality. Aim for under 200 KB for a hero. Use responsive srcset so phones do not download desktop-sized images.
Step 3: Never lazy-load the LCP image
Remove loading="lazy" from the hero image and add fetchpriority="high". Lazy-loading the LCP element is one of the most common theme mistakes — it tells the browser to deprioritise the very thing LCP measures. Below-the-fold images should stay lazy; the hero must load eagerly.
Step 4: Preload the LCP image
Add a preload hint in the <head> so the browser fetches the hero immediately, before it finishes parsing CSS:
<link rel="preload" as="image" href="/hero.webp" fetchpriority="high">
On WordPress, caching plugins like WP Rocket and LiteSpeed Cache can add this automatically — but verify it targets the actual LCP image.
Step 5: Fix slow server response (TTFB)
TTFB is the floor under LCP: Google rates 800 ms or less as good. Enable full-page caching so repeat visits skip PHP entirely, add Redis object caching for the requests that must run PHP, and check Query Monitor for slow plugins — one bad plugin can add seconds. Our slow server response fix covers this in depth.
Step 6: Eliminate render-blocking resources
Inline your critical CSS (the styles for above-the-fold content) and defer the rest. Defer non-critical JavaScript with defer or delay it until user interaction. In PageSpeed Insights this appears as “Render-blocking requests” — work through them in order of estimated savings.
Step 7: Optimise web fonts
Self-host your fonts (faster than Google Fonts for many sites), preload the ones used in the headline with <link rel="preload" as="font">, and use font-display: swap so text renders immediately in a fallback font instead of waiting invisibly.
Step 8: Re-test and wait for field data
After deploying, purge all caches and run PageSpeed Insights 2–3 times — the lab score updates immediately and confirms the fix worked. The Search Console row clears only when the 28-day field window rolls forward, so expect 4–8 weeks before the “LCP issue” label disappears. Click Validate fix in Search Console to have Google monitor the group.
How to Prevent LCP Regressions
Set a performance budget: hero images under 200 KB, TTFB under 800 ms, and no new render-blocking scripts without review. New plugins, hero videos, and marketing tags are the usual regression vectors — audit them before they ship. Monitor the Core Web Vitals report monthly; catching a template change early beats fixing 500 URLs later. A periodic pass with a free website speed tool keeps the numbers honest.
Conclusion
Slow LCP is almost always a hero-image problem stacked on a server-response problem: optimise and preload the image, stop lazy-loading it, fix TTFB with caching, and clear render-blocking resources. Do that on the template and the whole URL group clears. For more Core Web Vitals fixes that actually move the field data, follow the KamiWeb blog.