Fixing Largest Contentful Paint (LCP) Issues on Marketing Sites
Google's four LCP subparts explained, with the specific fix for each — and why compressing images alone often doesn't move your score.
Largest Contentful Paint (LCP) measures how long it takes the biggest visible element on a page — usually a hero image or headline — to actually render. Google treats 2.5 seconds or less, for at least 75% of visits, as the threshold for a "good" score.
Most marketing sites miss that target for one of four specific reasons, not because performance is generally mysterious. Google's own web.dev documentation breaks LCP into four measurable subparts, and fixing a slow score starts with figuring out which one is actually the problem before changing anything.
Key Takeaways
- LCP splits into four subparts: Time to First Byte (~40% of the total), resource load delay (<10%), resource load duration (~40%), and element render delay (<10%) — per web.dev.
- The single most common marketing-site mistake is hiding the LCP image behind JavaScript or lazy-loading, which adds load delay that a good score can't absorb.
- Compressing images and switching to WebP/AVIF addresses load duration, but it's only one of the four subparts — it won't fix a slow server response or render-blocking CSS/JS.
- Never apply loading="lazy" to the image that is actually your LCP element — it directly works against the metric.
- Fixing LCP is a process of elimination across TTFB, load delay, load duration, and render delay — not a single universal fix.
What Actually Counts as the LCP Element
On most marketing pages, the LCP element is the hero image, a large heading, or a background image with text over it — whichever single element is the biggest thing painted in the visible viewport during initial load. That's the one to optimize; spending time on smaller images below the fold doesn't move this specific metric.
The Four Subparts, and What Slows Each One Down
Time to First Byte (TTFB) — About 40% of LCP
TTFB is the time from navigation start until the first byte of HTML arrives. It's dominated by server response time, redirect chains, and DNS/connection overhead. A slow host, an unnecessary redirect on your homepage URL, or a bloated server-side process before the page even starts sending HTML all show up here — and no front-end optimization fixes a slow TTFB.
Resource Load Delay — Usually Under 10%, But Easy to Create by Accident
This is the gap between TTFB and when the browser actually starts downloading the LCP resource. It should be close to zero if the LCP image is referenced directly in the initial HTML. It balloons when the image is only discoverable after JavaScript runs, or when it's marked loading="lazy" — both very common on marketing sites built with heavy client-side component libraries.
Resource Load Duration — About 40% of LCP
Once the browser starts downloading the LCP resource, this is how long that download actually takes. Large, uncompressed images are the most common cause on marketing sites. Modern formats (WebP, AVIF), reasonable compression, and serving from a CDN close to the visitor all reduce this directly.
Element Render Delay — Usually Under 10%, But a Common Blind Spot
This is the gap between the resource finishing its download and the browser actually painting it. Render-blocking CSS, synchronous JavaScript in the `<head>`, and long JavaScript tasks monopolizing the main thread all show up here — the image can be fully downloaded and still not appear until the browser finishes other work first.
Fixes That Address Each Subpart
- Reduce TTFB: fix slow server response times, remove unnecessary redirects, and make sure DNS/connection setup isn't adding avoidable overhead.
- Eliminate load delay: put the LCP image directly in the initial HTML (not injected by JavaScript), add fetchpriority="high", and preload it with <link rel="preload">.
- Never lazy-load the LCP image — loading="lazy" is built for below-the-fold images, and applying it to your LCP element actively works against the metric.
- Reduce load duration: compress images, switch to WebP or AVIF, and serve from a CDN — but treat this as one of four levers, not the whole fix.
- Reduce render delay: inline or minimize critical CSS, defer non-critical JavaScript, and avoid long JavaScript tasks that block the main thread right when the LCP element is ready to paint.
Why "Just Compress the Images" Usually Isn't Enough
Image compression addresses exactly one of the four subparts — load duration — which is why it sometimes barely moves the needle. If the real problem is a slow server response or a render-blocking script, a perfectly optimized image still arrives late or sits fully downloaded while the browser finishes other work. Diagnosing which subpart is actually the bottleneck comes before deciding on a fix — see our guide on image optimization for faster page loads for the load-duration piece specifically, once you've confirmed that's actually where your time is going.
WordPress sites carry a specific version of this problem — see why WordPress sites struggle with Core Web Vitals for how plugin-driven render-blocking scripts commonly show up in the render-delay subpart specifically.
Frequently Asked Questions
What is a good LCP score?
2.5 seconds or less, for at least 75% of page visits, per Google's web.dev documentation. Between 2.5 and 4 seconds needs improvement; above 4 seconds is considered poor.
Is LCP the same as page load time?
No. LCP specifically measures when the largest visible element finishes rendering, not when every resource on the page has finished loading. A page can have a fast LCP and still be downloading other resources in the background.
Should I lazy-load my hero image?
No — if the hero image is your LCP element, loading="lazy" delays it and directly hurts the metric. Lazy-loading is meant for images below the fold that aren't part of the initial viewport.
Will compressing images fix a slow LCP score?
It can help, but only if slow resource load duration is actually your bottleneck. LCP has three other subparts — TTFB, load delay, and render delay — and image compression doesn't touch any of them.
Does a CDN improve LCP?
Yes, primarily by reducing resource load duration (serving files from a location closer to the visitor) and sometimes TTFB, if the CDN also caches the HTML response itself.
Sources and Further Reading
web.dev — Optimize Largest Contentful Paint
web.dev — Largest Contentful Paint (LCP)
Want Your Site's Core Web Vitals Actually Diagnosed?
A technical SEO and speed review checks all four LCP subparts against your real site — not a generic checklist — before recommending what to actually fix.
Written by
Rafael Arceo
Rafael Arceo is a digital marketing and web technology specialist focused on Google Ads conversion tracking, GTM, GA4, SEO, WordPress, Payload CMS, and website conversion setup.
Related Posts
What actually moves the needle on image-driven page speed — correct sizing, modern formats, and lazy loading — and what doesn't matter as much.
What LocalBusiness structured data actually does in Google Search and Maps, which fields matter most, and when a service business genuinely needs it.
What structured data actually does for SEO, which schema types are worth adding, and why FAQ rich results don’t work the way they used to.
Need Cleaner Tracking or a Better Website Setup?
Send your website URL and I can help identify what needs to be checked, fixed, or improved.