How to Improve Image Performance: A Practical Guide

To improve image performance, first identify the page’s likely Largest Contentful Paint (LCP) element and find out when its image request starts. Then serve an image sized for its rendered layout, choose a format and compression level that preserve the required quality, defer below-the-fold images, and measure again. Smaller image files help only when image download is the bottleneck: LCP can also be delayed by late discovery, low request priority, render-blocking resources, or main-thread work.

Use this workflow on a representative page, checking mobile and desktop separately. Keep the likely LCP image discoverable in the initial HTML and do not lazy-load it. For other images, responsive candidates and native lazy loading can reduce unnecessary downloads.

1. Find the image that matters

Start with the user experience rather than a site-wide image-byte target. Identify the page’s likely LCP element, then inspect the image request and the LCP timeline in browser developer tools. The LCP target cited in Google’s archived Web Vitals guidance is 2.5 seconds; check current official guidance when publishing metric targets. [web.dev: Optimize LCP] [web.dev: Web Vitals]

Open a representative page in browser developer tools and record the LCP element and its resource URL.
Check when the image is discovered, its request priority, and how long it takes to download.
Inspect whether the element is delayed after download by CSS, JavaScript, visibility changes, or long main-thread work.
Repeat on mobile and desktop. The selected image and bottleneck may differ by viewport.

Break the delay into time to first byte, resource load delay, resource load duration, and element render delay. If the request starts late, expose the image earlier. If it downloads slowly, investigate its dimensions, format, compression, and delivery. If it finishes early but renders late, investigate stylesheets, scripts, and main-thread work.

2. Serve an image that fits its layout

Use the rendered CSS size as a starting point, then account for the device pixel ratio when sharpness requires it. A 500-pixel-wide layout slot does not automatically need a 1,000-pixel-wide source, but a high-density display may benefit from a larger candidate. Responsive image markup lets the browser choose among the candidates you provide.

In srcset, width descriptors describe candidate intrinsic widths. Pair them with sizes, which tells the browser the image’s expected rendered width under the page’s layout conditions. If sizes overstates the slot, the browser may choose an unnecessarily large file.

<img
  src="/images/article-800.jpg"
  srcset="/images/article-400.jpg 400w,
          /images/article-800.jpg 800w,
          /images/article-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, (max-width: 1000px) 80vw, 800px"
  width="800"
  height="533"
  alt="A descriptive alternative text">

This example assumes the image spans the viewport on small screens, uses 80% of the viewport in the middle layout, and is capped at 800 CSS pixels on wider screens. Adjust the conditions to match the actual layout, and provide a sensible number of candidates rather than generating an unbounded set of variants.

3. Choose formats and compression for the content

Newer formats such as AVIF and WebP can produce smaller files than older formats, but the result depends on image content, quality settings, and browser support. Use a fallback when needed, and compare the rendered outputs before shipping. The <picture> element lets a browser select the first supported source:

<picture>
  <source type="image/avif" srcset="/images/hero.avif">
  <source type="image/webp" srcset="/images/hero.webp">
  <img src="/images/hero.jpg"
       width="1600" height="900"
       alt="A team working around a table">
</picture>

Lossy compression often suits detailed photographs, where small artifacts can be less noticeable. Text, line art, sharp edges, and high-contrast colored text on flat backgrounds can reveal artifacts more clearly. Lossless compression preserves image data, though its file-size savings vary. There is no single quality setting that works for every image: inspect likely problem areas at the size people will see.

WebP supports lossy and lossless compression and transparency; AVIF also supports both lossy and lossless compression. Avoid assuming a format conversion alone will improve LCP: delivery timing, image discovery, request priority, and rendering still matter. Optional tools mentioned in the web.dev image guidance include Squoosh and ImageOptim; image optimization services and image CDNs can help manage delivery and format selection across many assets. [web.dev: Serve images in modern formats]

4. Load visible content first

Native lazy loading can defer images that are below the fold, leaving bandwidth available for visible content. Do not apply loading="lazy" to the likely LCP image. When that image is an <img>, keep its src or srcset in the initial HTML so the browser can discover it early.

<!-- Likely LCP image: discover it early; do not lazy-load it. -->
<img src="/images/hero-1600.webp"
     width="1600" height="900"
     fetchpriority="high"
     alt="A mountain range at sunrise">

<!-- Below-the-fold content image. -->
<img src="/images/details-800.webp"
     width="800" height="600"
     loading="lazy"
     alt="A close view of the product details">

fetchpriority="high" can hint that a likely LCP image matters. Use it sparingly: marking many images high priority weakens the distinction and can compete for bandwidth. Check actual request priority in developer tools after changing markup. If the critical image is inserted only after JavaScript runs or hidden until a script executes, reducing its file size may not address the main delay.

5. Measure whether the change helped

Record the baseline before changing assets. After each meaningful change, compare the LCP element and its timing breakdown, image request start and duration, selected responsive candidate, and visual quality. Use both lab measurements for controlled iteration and field data for how pages perform for real users. Evaluate the 75th percentile separately for mobile and desktop when using the LCP threshold guidance. [web.dev: Optimize LCP] [web.dev: Web Vitals]

Confirm the browser selected the expected srcset candidate for each viewport.
Check that the LCP image request begins early and has appropriate priority.
Compare download duration as well as total LCP; a smaller file is not proof that the page improved.
Review the image at its rendered size for compression artifacts, blur, or unexpected cropping.
Repeat measurements because a single lab run can vary.

6. Practical trade-offs

Choice	Useful when	Trade-off to watch
More responsive candidates	Layouts span meaningfully different widths or device densities.	More variants add asset and cache management work; avoid an unbounded set.
AVIF or WebP with fallback	A format produces smaller acceptable output for the image and supported clients.	Inspect browser support needs and visual quality; do not assume a universal size reduction.
Lossy compression	Detailed photos tolerate the chosen level of artifacts.	Text, line art, and crisp edges may show defects.
Lazy loading	Images are below the fold and not needed for initial rendering.	Applying it to the LCP image can delay its request and harm LCP.
Image service or CDN	Many assets or delivery variants make manual optimization cumbersome.	Evaluate operational complexity and measure its effect; no service guarantees an LCP improvement by itself.

For reliability, retain a usable fallback where format support requires one, keep dimensions and alternative text in markup, and validate that responsive URLs exist. For cost, compare the ongoing work of producing and caching variants with the value of lower transfer size and simpler delivery. The research does not establish vendor pricing or a universal performance return.

7. Troubleshooting common problems

Symptom	Likely cause	Fix
The browser downloads a much larger image than the visible slot.	`sizes` does not reflect the layout, or candidates are too widely spaced.	Correct the `sizes` conditions and inspect the selected candidate at each viewport.
The hero image starts downloading late.	It is discovered after JavaScript runs, is absent from initial HTML, or is delayed by loading behavior.	Expose its `src` or `srcset` early and remove lazy loading from the likely LCP image.
The image downloads quickly, but LCP remains slow.	Element render delay, stylesheets, scripts, or main-thread work dominate.	Inspect the LCP breakdown and rendering path; optimize the actual blocker rather than only compressing the asset.
A compressed image looks poor.	The quality setting is too aggressive for text, edges, or the image’s visual role.	Raise quality, choose lossless compression where appropriate, or use a better-suited source; compare at display size.
The new format does not load for some visitors.	The chosen delivery path lacks a suitable fallback or has an incorrect asset URL.	Use ordered sources with a fallback in `<picture>` and verify each URL and content type.
Lazy images appear blank during testing.	The test or capture did not scroll them into the loading range, or the URL failed.	Scroll to the image, inspect the network request, and distinguish deferred loading from an actual failed request.
High priority does not improve the hero image.	Other high-priority resources compete, or another stage of LCP dominates.	Use the hint only for the likely LCP image and verify request priority and the full timing breakdown.

8. Capture pages while diagnosing image changes

When a visual comparison helps, capture the same page before and after an optimization at the same viewport and device scale. A screenshot can reveal layout shifts, missing assets, or quality changes, but it does not replace network timing or field performance measurements. For repeatable checks, keep the URL, viewport, and capture conditions consistent.

ScreenshotNeo is a website screenshot API and MCP server from ScreenshotNeo. Its one-call API can capture a URL as PNG, JPEG, WebP, or PDF. Documentation: ScreenshotNeo API docs.

Or skip the browser setup

curl -G "https://api.screenshotneo.com/v1/shot" -d access_key=YOUR_API_KEY --data-urlencode url=https://stripe.com -o shot.webp

import requests
r = requests.get("https://api.screenshotneo.com/v1/shot", params={"access_key": "YOUR_API_KEY", "url": "https://stripe.com"}, timeout=90)
open("shot.webp", "wb").write(r.content)

const q = new URLSearchParams({ access_key: 'YOUR_API_KEY', url: 'https://stripe.com' });
const res = await fetch(`https://api.screenshotneo.com/v1/shot?${q}`);

ScreenshotNeo accepts cookie and consent banners and removes more than 60 known consent platforms, newsletter popups, and chat widgets before capture; each step can be turned off. Bot checks, blank pages, timeouts, failed loads, and cache hits are not billed, and response headers report the page verdict and billing status. Its MCP server provides take_screenshot, get_page_info, and capture_pdf for AI agents. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000 shots.

FAQ

How do I make images load faster?

Find whether the delay is discovery, download, or rendering. Serve an appropriately sized responsive candidate, choose compression that passes visual review, and defer only images that are offscreen.

Should I convert every image to AVIF?

No. Compare the actual output and quality for each kind of image, account for supported browsers, and keep a fallback where needed.

Does lazy loading improve LCP?

It can help below-the-fold images by deferring their requests. Lazy-loading the likely LCP image can instead delay its discovery and hurt LCP.

Can a screenshot prove that performance improved?

No. It can show visual differences, while request timing, LCP measurements, and field data show performance changes.