By Dik Raci · Creator of online tools · About the author
How to Fix a Slow LCP: The Image Optimization Playbook
When a page feels slow, users are not reacting to your total load time - they are reacting to how long it takes for the main thing on screen to appear. That is exactly what Largest Contentful Paint (LCP) measures: the render time of the biggest image or text block in the first viewport. Google classes an LCP of 2.5 seconds or less as good, anything above 4 seconds as poor, and scores your site on what three-quarters of your real visitors experience - not what your fast office connection sees.
Here is the pattern we see over and over: on content pages, blog posts and e-commerce product views, the LCP element is an image, and the causes are almost always the same short list of mistakes. This playbook walks through them in the order you should fix them - measure first, then the five fixes that do the work.
Step 1: find your actual LCP element
Do not guess. Run the page through PageSpeed Insights and open the "Diagnose" section: the report names the LCP element explicitly, splits the load into phases (time to first byte, resource load delay, resource load time, element render delay), and shows both lab and real-user data. Check Search Console's Core Web Vitals report too - it groups your URLs by their field LCP status, which tells you whether you are fixing one bad template or five hundred. The phase breakdown matters because it tells you which fix below is yours: a long "load delay" phase means discovery problems (fixes 1-2), while a long "load time" phase means the file itself is too big (fixes 3-5).
Fix 1: stop lazy-loading the hero
This is the most common self-inflicted wound we find, and the fix costs one attribute. loading="lazy" is excellent for images below the fold - it defers them until the user actually scrolls. But when someone pastes it onto every image including the main hero, the browser deliberately postpones downloading the exact element your LCP is measured on. The rule is simple: lazy-load everything except the LCP image. Audit your templates: WordPress themes, page builders and e-commerce platforms have all shipped this bug at some point, and some lazy-load by default on every image on the page.
Fix 2: tell the browser the image is important
Browsers used to discover images only after reading your HTML and CSS, which delays the download even when the file is first in line. Two mechanisms fix the discovery delay, and they work together:
<!-- In the <head>: start the download early -->
<link rel="preload" as="image"
href="/img/hero.avif" fetchpriority="high" />
<!-- On the element itself: skip the queue -->
<img src="/img/hero.avif" alt="..."
width="1200" height="630"
fetchpriority="high" decoding="async" />The fetchpriority="high" attribute is supported in all evergreen browsers and is usually enough on its own; the preload link helps most when the image is referenced in CSS or injected by JavaScript. Use one or the other on the hero - both at once on the same URL is harmless but redundant. The inverse matters too: give every other image on the page loading="lazy" and fetchpriority="low" is unnecessary - lazy already deprioritizes them.
Fix 3: serve the right pixels, not more
The second most common cause of slow LCP is dimensional oversizing: a hero rendered at 1100 CSS pixels on desktop, doubled for retina to 2200 device pixels, but shipped at 4000 pixels wide. The browser downloads and decodes every one of those wasted pixels. The fix is srcset with three or four sensible widths (say 640, 1080, 1600, 2200) and a sizes attribute that tells the browser how wide the image will actually render. Mobile devices - where your LCP is measured most often - then download the small file instead of the monster. If your hero is a JPEG exported straight from a camera or a stock download, this single change frequently halves its weight before compression even enters the picture.
Fix 4: make the hero file small
With dimensions right, format and quality decide the rest. A hero image belongs in WebP or AVIF at a visual quality of roughly 75-85 - our quality-vs-size measurements show the curve goes exponential above 85, and our WebP vs AVIF comparison covers which modern format to pick. The working target we recommend: hero image under 150-200 KB at desktop resolution. A photographic hero at 1200 pixels wide, correctly compressed, lands near 100 KB; if yours is 900 KB, the compressor - not the design - is the problem. Run it through our image compressor and compare at full-screen zoom; the difference you cannot see is the weight you should not ship. One caution: do not chase the number below quality where the image visibly degrades, because a fast ugly page loses to a slightly slower good one.
Fix 5: help the browser render it immediately
Three smaller items complete the playbook. Explicit width and height attributes prevent the layout shift that both hurts CLS and can delay the moment the browser commits to rendering the element. Avoid measuring LCP with CSS background images on your hero - they are discovered late and cannot use priority hints; an <img> element is measurably faster to start. And keep the hero out of client-side carousels if you can: if the first slide is rendered by JavaScript after hydration, your LCP waits for your JavaScript, which is the slowest dependency you have. If a carousel is mandatory, make slide one a plain image element and priority-hint it.
The ceiling check: your server time
One honest caveat closes the playbook: if the "time to first byte" phase of your LCP breakdown dominates, image work cannot save you. A 3-second server response makes every image optimization irrelevant, because the browser cannot even start downloading the hero until the HTML arrives. Check hosting, caching headers and CDN coverage first in that case, then apply the image fixes above - they will compound nicely on a fast origin. When you are done, re-run PageSpeed Insights and, crucially, wait a few days for the field data to refresh: lab improvements are instant, but Google's CWV score moves as real users' data accumulates. Our full image optimization guide extends this playbook to the rest of the page.
Try CompressoPanda Now
Practical image processing with an output you should review before publishing.
Related Articles
Optimize Images for Web
The complete performance guide: formats, sizing and delivery.
JPEG Quality 75 vs 85 vs 95
Exact sizes and PSNR for every quality setting.
WebP vs AVIF in 2026
Which format to ship, and the fallback that makes it safe.
Image Compression Checklist
The pre-publish checklist for every image you ship.