Image Performance Playbook: LCP, CLS, and INP—What to Fix First
About the Author
Quick Image Tools Editorial — Practical image workflows for the modern web. This article, “Image Performance Playbook: LCP, CLS, and INP—What to Fix First,” was prepared by our in‑house team and peer‑reviewed for accuracy.
Questions? Contact us.
Published: 2025-11-07 • Last updated: 2025-11-07
TL;DR
Optimize LCP by right-sizing and preloading your hero image, prevent CLS by reserving width/height, and reduce INP by avoiding heavy JS in image carousels.
Key Priorities
- Right-size heroes: Export at target width (1600–2000w) then compress.
- Reserve space: Add
widthandheightto<img>to prevent layout shifts. - Preload critical image: Use
<link rel="preload" as="image">for the LCP element. - Lazy-load the rest:
loading="lazy"for below-the-fold media.
Implementation Checklist
Measuring Wins
Open Lighthouse in Chrome DevTools. Compare LCP before/after swapping the hero image. Track CLS from 0.25 → < 0.1 and reduce INP spikes by removing heavy blocking scripts from image widgets.
FAQ
What’s a “good” LCP?
Target under 2.5s on mobile.
Do I need AVIF?
Optional. WebP already offers big wins; you can add AVIF later if your stack supports it.
Should I preload all images?
No—only the hero/LCP image.
Last updated: 2025-11-07
Performance wins you can apply today
Most speed improvements come from reducing the largest image on the page and making its dimensions match the layout. If your hero image is oversized, resize it first, then compress it. This reduces download time and improves Largest Contentful Paint (LCP).
- Set explicit width/height to reduce layout shift (CLS).
- Lazy-load below-the-fold images to reduce initial work.
- Use modern formats where supported to cut bytes.
Performance fixes tied to images
Images commonly dominate page weight and rendering time. The fastest improvement is shrinking the largest above-the-fold image and making its dimensions match the layout so the browser doesn’t waste time decoding oversized files.
- Set width/height attributes to reduce layout shift (CLS).
- Lazy-load images below the fold to cut initial work.
- Compress and convert your heaviest images to reduce bytes.
After changes, re-check performance in a real mobile network profile; the wins are most visible on slower connections.
A simple performance test that actually works
Pick your largest above-the-fold image and optimize only that one first. Measure page speed before and after. If the improvement is big, repeat the process with the next-largest image.
This “largest-first” method beats random optimization because it targets the files that dominate download time and rendering cost.
Measure what changed, not what you hope changed
After optimizing images, confirm the impact with a before/after comparison: page load time on mobile, total transferred bytes, and whether the largest above-the-fold image loads sooner.
If you see little improvement, the bottleneck may be elsewhere (scripts, fonts). But for most sites, images are still the largest byte contributor—so start there.
Image optimization that users actually feel
Users feel speed improvements most when the main image appears quickly and the page stops jumping. Resize your hero image to the layout, compress it, and make sure dimensions are declared so the browser can reserve space.
After that, optimize the next-largest images. This “largest-first” strategy usually beats random optimization.
Photographer angle: fast galleries feel premium
A portfolio that loads instantly is part of the experience. Optimize the first visible gallery images so they appear quickly on mobile. That single change can make your work feel higher-end before anyone even zooms in.
Largest-image-first optimization
If you only optimize one thing, optimize the first big image users see. Reducing the weight of that single file often improves perceived speed more than dozens of tiny tweaks elsewhere.
The performance checklist that matters
If you want one measurable win, optimize the first big image users see. Resize it to the layout, compress it, and declare its dimensions so the page doesn’t jump.
After that, optimize the next-largest images. This “largest-first” approach usually outperforms scattered tweaks.
What to optimize first on a page
Optimize what users see first. The hero image and above-the-fold gallery thumbnails dominate perceived speed. Resize them to the actual layout and compress to a sensible weight.
Then ensure dimensions are set so the page doesn’t shift while loading—that’s a major “quality feel” upgrade.
| Metric | What it measures | Image causes | Fix |
|---|---|---|---|
| LCP | Largest element render time | Large file, no preload, lazy loading | Compress, preload, CDN |
| CLS | Layout shift | Missing width/height attributes | Always set dimensions |
| INP | Interaction responsiveness | Heavy JS for image processing | Defer non-critical image JS |
| FCP | First paint time | Render-blocking image resources | Preload critical images |
| TTFB | Server response time | Unoptimized origin server | CDN, image optimization service |
Frequently Asked Questions
What is LCP and how do images affect it?
LCP (Largest Contentful Paint) measures the time until the largest visible content element is rendered. Images are the LCP element on 70%+ of pages. A good LCP score is under 2.5 seconds. Images hurt LCP when they are large files that take long to download, not preloaded when they are the LCP element, loaded with lazy loading which delays the critical image, or not in a CDN causing high latency. Fix: compress the LCP image aggressively, add rel="preload" in the head for the LCP image, and ensure it's hosted on a fast CDN.
What causes image-related CLS (layout shift)?
CLS (Cumulative Layout Shift) measures unexpected layout movement. Images cause CLS when they load without reserved space, pushing content down as they appear. The fix is to always specify width and height attributes on img tags — this lets the browser reserve the correct space before the image loads. Also set aspect-ratio in CSS. A CLS score under 0.1 is good. Images without dimensions are one of the most common and easily-fixed causes of poor CLS.
Should I lazy load all images?
No — never lazy load the LCP image (the first large image visible on the page) or any above-the-fold images. Lazy loading delays loading until the user scrolls near the image, which is appropriate for below-the-fold images but actively harms LCP for critical images. Rule of thumb: the first 1–3 images visible on page load should have loading="eager" (or omit the loading attribute entirely). All images below the fold should have loading="lazy".
What image format gives the best performance?
WebP is the best overall format for web performance: 25–35% smaller than JPEG at equivalent quality, supports both lossy and lossless compression, and has 97%+ browser support. AVIF is even more efficient (30–50% smaller than JPEG) but has slightly lower browser support (~93%) and slower encoding. For practical use in 2025: use WebP as your default, consider AVIF for very high-traffic pages where the encoding cost is worth the savings, and keep JPEG/PNG as fallbacks for older browsers using the HTML picture element.
How do I use srcset to serve different image sizes?
The srcset attribute tells the browser which image to use at different viewport widths and pixel densities. Basic syntax: 
. The sizes attribute tells the browser how wide the image will be displayed at each breakpoint, allowing it to choose the most efficient source. Always generate multiple sizes when images are displayed at different sizes on mobile vs desktop.