Image Optimization: How to Make Images Load Faster

To make images load faster, reduce the bytes each visitor downloads: serve dimensions close to the displayed size, provide responsive alternatives for different screens, choose a suitable format and compression level, and defer images below the fold. Keep the main hero image easy to discover, and reserve space for every image so the page does not jump while it loads.

There is no universally best image format or compression setting. The right choice depends on the image, the browsers you support, and whether you need transparency or animation. Optimize one image at a time, then check both its appearance and its downloaded size.

1. Find the images that cost the most

Start with the page’s image requests. Look for files with large byte sizes and images whose pixel dimensions are far larger than their rendered dimensions. A large image can be particularly important when it is the page’s main visible content and affects Largest Contentful Paint (LCP). Reducing its bytes or sending a better-sized version can reduce download time, though the result depends on the page and visitor’s connection. web.dev’s image performance guide explains why images can make up a substantial share of page resources.

Record the image URL, file size, pixel dimensions, and approximate rendered size.
Identify oversized originals, repeated images, and images that load before they are needed.
Note whether each image is a photograph, illustration, logo, screenshot, or animation. Their quality requirements differ.
Change a small group of images, then compare downloaded bytes and visible quality.

Do not optimize only for the smallest file. A photo with visible blockiness or text with colored fringes is not an improvement for readers.

2. Resize images and offer responsive candidates

If a page displays an image at 400 CSS pixels wide, sending a 2400-pixel-wide source to every visitor may waste bandwidth. Create appropriately sized variants and let the browser choose from them. The web.dev responsive images guide covers candidate selection with srcset and sizes.

<img
  src="/images/product-800.jpg"
  srcset="/images/product-400.jpg 400w,
          /images/product-800.jpg 800w,
          /images/product-1200.jpg 1200w"
  sizes="(max-width: 600px) 100vw, (max-width: 1000px) 80vw, 800px"
  width="800"
  height="600"
  alt="A blue ceramic coffee mug on a wooden table">

The w descriptors tell the browser the intrinsic width of each candidate. The sizes value describes the image’s expected layout width at different viewport sizes, allowing the browser to select a suitable source. Adjust sizes to match your actual layout; inaccurate values can lead to an unnecessarily large choice. See MDN’s <img> reference for markup details.

When to use `srcset` and `picture`

Use srcset and sizes when the same image is shown at different sizes or pixel densities.
Use <picture> when you want to offer different formats or art-directed images for conditions such as viewport width. Keep an <img> inside it as the fallback and provide its alternative text there.
Keep candidate sets practical. Every extra variant takes storage and adds work to generate and maintain.

<picture>
  <source
    type="image/avif"
    srcset="/images/landscape-640.avif 640w,
            /images/landscape-1280.avif 1280w"
    sizes="(max-width: 700px) 100vw, 700px">
  <source
    type="image/webp"
    srcset="/images/landscape-640.webp 640w,
            /images/landscape-1280.webp 1280w"
    sizes="(max-width: 700px) 100vw, 700px">
  <img
    src="/images/landscape-1280.jpg"
    width="1280"
    height="853"
    alt="Mountain peaks reflected in a lake at sunrise">
</picture>

Use real files in each source set and test the fallback path as well as modern formats. For art direction, use distinct sources for the viewport conditions rather than treating differently composed images as interchangeable size candidates.

3. Choose a format and compression level for each image

WebP and AVIF can compress more efficiently than older formats in suitable cases, but neither is automatically best for every asset. Browser support, transparency, animation, and quality requirements all matter. MDN’s image format guide describes those tradeoffs. If your delivery method needs format alternatives, use <picture> with an <img> fallback.

Image or requirement	What to try	What to inspect
Detailed photograph	Compare a lossy WebP or AVIF version with the existing image.	Look for texture loss, banding, and artifacts in faces, gradients, and fine detail.
Logo, diagram, or image with text	Compare formats and compression carefully; retain a lossless option where artifacts are visible.	Inspect letter edges, thin lines, and areas of flat color at the size users see.
Transparency required	Use a format and delivery path that preserve transparency.	Check transparent edges against both light and dark backgrounds.
Animation required	Choose a format and browser delivery path that support the animation you need.	Verify playback, quality, and fallback behavior.

Lossy compression discards some image information and often suits photographs when the artifacts remain acceptable. Lossless compression preserves image data but may result in a larger file. High-contrast colored text on a flat background can reveal chroma-subsampling artifacts. Inspect the actual output; there is no compression setting that works for every image. web.dev’s guidance reports savings greater than 50% compared with JPEG in some tests, but that is not a promise for a particular image or workflow.

4. Load images when they are needed

Images below the initial viewport are often candidates for native lazy loading. Do not lazy-load the important hero image: delaying the image that forms the main visible content can postpone its discovery. An important image can use fetchpriority="high" to communicate its priority. See web.dev’s responsive image guidance and MDN’s image reference.

<!-- Prominent hero: eager/default loading; consider high priority if it is important. -->
<img
  src="/images/hero-1200.webp"
  width="1200"
  height="675"
  fetchpriority="high"
  alt="A runner crossing a bridge at sunrise">

<!-- Below-the-fold image: let the browser defer it until it is near view. -->
<img
  src="/images/article-detail-800.webp"
  width="800"
  height="600"
  loading="lazy"
  alt="Close-up detail of the bridge surface">

Use lazy loading selectively for content that is genuinely below the fold. Applying it to visible images can delay them; applying it to every image can also defer content that matters early. Browser-native lazy loading is a hint about when to fetch, not a guarantee of an exact fetch time.

5. Reserve image space to prevent layout shifts

Provide the image’s intrinsic width and height, or otherwise reserve its aspect ratio in layout. The browser can then allocate space before the file arrives, reducing layout shifts. For responsive CSS layouts, dimensions still describe the source ratio while CSS controls the rendered size:

.article-image {
  display: block;
  width: 100%;
  height: auto;
}

For a cropped container with a known ratio, reserve that ratio explicitly and use an appropriate crop rule:

.thumbnail {
  width: 100%;
  aspect-ratio: 4 / 3;
  object-fit: cover;
}

Choose dimensions and aspect ratio that match the image as displayed. MDN explains how reserved dimensions help avoid layout shifts in its image element reference.

6. Recheck bytes, appearance, and loading behavior

After making changes, inspect the page again at a narrow and wide viewport. Confirm that the browser selects an appropriate candidate, the hero is not accidentally lazy-loaded, below-the-fold images can be deferred, and space is reserved while each image loads. Compare resource bytes and visual output rather than relying on a single score.

Check photographs for banding, blur, or loss of texture.
Check logos, diagrams, and screenshots for jagged edges or colored halos around text.
Check transparent assets over more than one background.
Confirm the intended format and responsive candidate are actually served.
Revisit pages using the same asset so a change does not create inconsistent quality or sizing.

Image changes may improve download time and may help LCP when the image is the main visible content. The actual effect depends on the image, page, and delivery conditions; do not assume a fixed score or percentage improvement.

Or skip the browser setup

If you need to inspect how optimized images render across a site, ScreenshotNeo is a website screenshot API and MCP server. A screenshot can help review a page’s visible rendering after image changes; it does not replace checking downloaded bytes or browser performance data. See the ScreenshotNeo API documentation for request options.

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}`);
if (!res.ok) throw new Error(`Screenshot request failed: ${res.status}`);
const image = Buffer.from(await res.arrayBuffer());
await import('node:fs/promises').then(fs => fs.writeFile('shot.webp', image));

Cookie banners, newsletter popups, and chat widgets are removed before the shot. Bot checks, blank pages, and failed loads are never billed. Its MCP server lets AI agents take screenshots. The free plan includes 1,000 screenshots a month with no card; paid plans start at $5 for 3,000. Sign up for free and capture 1,000 screenshots a month with no card.

Troubleshooting image loading

Symptom	Likely cause	Fix
A mobile visitor downloads a very large image.	The page has only one source, or `sizes` describes a wider layout than the real one.	Provide width candidates in `srcset` and make `sizes` match the rendered layout.
A modern format does not appear in some browsers.	The image is served without a supported fallback or the format alternative is not selected.	Use `<picture>` with format sources and a valid `<img>` fallback; check the delivered file.
Text or edges look smeared or colored.	Lossy compression is too aggressive for sharp edges or high-contrast text.	Use a less lossy or lossless version for that asset, then inspect it at its rendered size.
The hero image appears late.	It may be marked lazy, oversized, or not given suitable priority.	Remove lazy loading from the hero, provide an appropriate source size, and consider `fetchpriority="high"` for a genuinely important image.
Content jumps when an image loads.	The browser has no reserved space because dimensions or aspect ratio are missing or wrong.	Set intrinsic `width` and `height` or reserve the correct CSS aspect ratio.
A lazy image is missing in a capture or seems delayed.	It is below the fold and has not been brought near the viewport yet.	Scroll it into view when reviewing, or test the page in a normal browser session. Do not remove lazy loading from all images just to accommodate one capture workflow.
A smaller file looks worse than the original.	Compression damaged details important to that image type.	Choose a different format or quality level for that asset; use visual quality as a constraint.

Performance, reliability, and cost considerations

Responsive variants and format alternatives use extra storage and require a reliable way to generate and serve the files. Lazy loading can avoid fetching below-the-fold resources until they are likely to be needed, but should not postpone important initial content. Declared dimensions make layout more stable even when an image takes time to arrive. These techniques reduce unnecessary work; they cannot guarantee a particular page speed because network, caching, server response, and other page resources also matter.

For a small site, a manual workflow using an image editor or a tool such as Squoosh or ImageOptim may be enough. For a large image library, an image optimization service can automate resizing and format delivery, but its cost and terms need to fit the project. The research does not establish a universal cost advantage. Compare service fees and operational effort with the storage and maintenance cost of generating variants yourself. Keep source originals so you can regenerate outputs when requirements change.

Frequently asked questions

Should I convert every image to AVIF?

No. Compare formats for each kind of asset, check browser support and required features, and provide a fallback when your delivery path calls for one.

Should I lazy-load every image?

No. Lazy loading is suited to images below the fold. Keep the important hero image eager or default-loaded so it can be discovered promptly.

What is the best compression quality?

There is no universal setting. Choose based on the image’s visible quality at its actual display size, especially for text, thin lines, and sharp edges.

Do image optimizations guarantee a better LCP?

No. Smaller, appropriately sized images can reduce image download time and may help when an image is the LCP element, but the result depends on the page and delivery conditions.