The headline appears, but the product image arrives noticeably later. Compressing the image might help, yet the delay can start before the browser even requests the file.
First confirm what is slow. Largest Contentful Paint, or LCP, can be an image or a text block; the hero image is not automatically the measured element. Use the page's actual loading evidence to choose the first change.
- Find
- The LCP element and the stage causing its delay.
- Fix
- Improve discovery, transfer size, or rendering as evidence requires.
- Verify
- Repeat comparable measurements and inspect image quality.
Start with these checks
Identify the measured element
Record the LCP element on mobile and desktop; they can differ.
Read the request timing
Check when the image is discovered, requested, downloaded, and displayed.
Inspect the delivered asset
Compare its dimensions and bytes with the visible image and device.
Separate a late request from a large download
Use a performance trace or PageSpeed Insights diagnostic to identify the LCP element. Inspect the network waterfall for its resource. A request that starts late suggests discovery or prioritization work; a prompt request with a long transfer points toward delivery or file size.
A downloaded image can also wait before appearing because rendering is blocked. web.dev separates LCP into server response, resource load delay, resource load duration, and element render delay. Optimizing the wrong part can leave the visible wait unchanged.
Make the important image discoverable and appropriately sized
For an image confirmed as LCP, remove lazy loading and make its resource discoverable early. A fetchpriority hint can help the browser prioritize it. Do not mark every image high priority. If CSS or JavaScript hides the resource until late, address that discovery path and check any preload for duplicate downloads.
If the file is oversized, supply responsive image candidates and a sizes value matching the layout. The browser uses these hints to select a suitable resource. Compare the chosen file and visual quality on a phone and a high-density desktop screen; do not trade a readable product screenshot for a blurred rectangle.
Illustrative above-the-fold screenshot
Before
The confirmed LCP screenshot uses loading="lazy" and one large source for every viewport.
Suggested change
The image loads eagerly, has a targeted priority hint, and offers appropriately sized sources for the layout.
Original worked example, capped at 640 CSS pixels. Adjust sizes for your actual container and padding. Confirm the important image before changing its priority.
<style>
.hero-preview {
display: block;
width: 100%;
max-width: 640px;
height: auto;
}
</style>
<img class="hero-preview" src="/hero-1280.webp"
srcset="/hero-640.webp 640w, /hero-1280.webp 1280w"
sizes="(max-width: 640px) 100vw, 640px"
width="1280" height="800"
loading="eager" fetchpriority="high"
alt="Project board with tasks organized by owner">Compare the same page under the same conditions
Repeat checks with the same viewport, network settings, and cache state. Confirm the request starts as expected, the correct candidate loads, and no duplicate request appears. Inspect image quality, mobile crop, and alternative text.
Keep lab measurements separate from real-user data. A local improvement does not establish every visitor's experience. If the bottleneck is server response, a blocking script, or text rendering, work on that finding before recompressing the hero again.
Turn the diagnosis into a change
Take the next step
Inspect loading performance for [page URL]. Identify the actual mobile and desktop LCP elements and the dominant delay. If the hero image is responsible, fix its discovery, loading priority, or delivered size as the evidence requires. Preserve image quality, layout, and alternative text. Avoid duplicate preloads or prioritizing every image. Compare repeated measurements under matching conditions and report unresolved bottlenecks.
Use these instructions with your developer or coding assistant.
Questions before you change it
Should I lazy-load the hero image?
Do not lazy-load an image that is the LCP element. Establish its role first; images well below the initial viewport may have different loading needs.
Should I preload every large image?
No. Target the important resource after checking discovery and request timing. Extra preloads can compete with the resource you are trying to improve.
Will converting the image to WebP fix LCP?
It can reduce file size, but the delay may come from discovery, server response, or rendering. Measure the limiting stage before choosing a fix.
Make the next fix about your page.
Paste one public page to get a free audit preview. See the priorities, then decide whether to unlock the full report and implementation brief.