How to Reduce Image File Size for a Website

To reduce image file size for a website, first serve an image close to its rendered pixel dimensions. Then choose a suitable format, compress it while checking visual quality, provide responsive variants with srcset and sizes, and lazy-load images that are below the fold. These changes reduce transferred bytes without forcing browsers to display blurry or visibly damaged images.

Image dimensions and compression solve different problems. A 2,400 × 1,600 image displayed at 600 × 400 still transfers more pixels than the page needs, even if the file is well compressed.

1. Find the images costing the most bytes

Start with the page as users receive it, rather than an inventory of source files.

Run a current Lighthouse or PageSpeed Insights audit at representative desktop and mobile widths.
Open the browser Network panel and filter by Img. Record transferred size, intrinsic dimensions, rendered dimensions and the selected URL.
Prioritize images that are both large in bytes and displayed substantially smaller than their intrinsic dimensions.
Check whether mobile is downloading the same desktop candidate. A source file can look reasonable in a repository while the browser selects an unnecessarily large variant.

Lighthouse’s current guidance places these opportunities under the Improve image delivery insight; the older “Efficiently encode images” audit moved there in Lighthouse 13. The browser’s selected candidate and the live layout are the evidence you need.

2. Resize images to useful pixel dimensions

Do not upload a much larger raster image than any page layout needs. For a card that is 320 CSS pixels wide, a 640-pixel candidate may be enough for a 2× device-pixel ratio. For a full-width hero, generate wider candidates because its rendered width changes with the viewport.

Generate a practical width set

A small set such as 320, 640, 960, 1280 and 1920 pixels is often easier to maintain than dozens of nearly identical files. Choose widths from your actual layouts and traffic, then adjust after observing which candidates browsers request.

Use `srcset` and `sizes`

<img
  src="/images/hero-960.webp"
  srcset="
    /images/hero-320.webp 320w,
    /images/hero-640.webp 640w,
    /images/hero-960.webp 960w,
    /images/hero-1280.webp 1280w,
    /images/hero-1920.webp 1920w"
  sizes="(max-width: 700px) 100vw, 50vw"
  width="960"
  height="640"
  alt="Team reviewing a dashboard"
>

The width descriptors tell the browser each candidate’s intrinsic width. sizes describes the image’s expected CSS width: full viewport width up to 700 pixels, then half the viewport. The browser also accounts for device-pixel ratio when selecting a candidate.

Reserve layout space

Set width and height, or use a CSS aspect-ratio, so the browser can reserve space before the file arrives.

.card-image {
  width: 100%;
  aspect-ratio: 3 / 2;
  object-fit: cover;
}

This prevents layout shifts while images load. Keep the ratio consistent with the source or accept that object-fit: cover will crop it.

3. Select the format that matches the content

Content	Starting point	Inspect for
Photographs	Compare lossy WebP or AVIF with a well-compressed JPEG.	Blockiness, ringing, color shifts and loss of fine detail.
Logos, diagrams and icons	Use SVG when a vector source exists. Otherwise compare PNG with lossless WebP or AVIF.	Blurred edges, halos and colored fringes around text.
Screenshots and text-heavy graphics	Use lossless or conservative lossy settings.	Unreadable small text and smeared high-contrast edges.
Animated content	Evaluate a modern video or animated image approach when appropriate; retain the fallback required by your audience.	Autoplay behavior, accessibility and larger-than-expected files.

WebP and AVIF often compress raster images more efficiently than JPEG, PNG or GIF, but support depends on the browsers you serve. Use <picture> when you need explicit fallbacks:

<picture>
  <source type="image/avif" srcset="/images/product.avif">
  <source type="image/webp" srcset="/images/product.webp">
  <img src="/images/product.jpg" width="1200" height="800" alt="Product package">
</picture>

SVG is appropriate for vector artwork, not for photographic pixels. Exporting a raster image as SVG does not make it smaller or scalable.

4. Tune compression by visual inspection

There is no universal quality number. Export several settings, compare their byte sizes, and inspect them at the size readers actually see. Photos usually tolerate lossy compression better than screenshots, diagrams, logos and text.

Keep an original source outside the delivery directory.
Export a modern format and a required fallback.
Compare at 100% and at the rendered CSS size on a representative display.
Zoom into text, faces, foliage, gradients and sharp edges.
Keep the smallest version that passes your visual quality threshold.

Squoosh is useful for manual conversion and comparison. ImageOptim is another manual optimizer referenced by Chrome’s image guidance. For a small site, these tools and a build script may be sufficient.

5. Deliver only images that are needed now

Lazy-load images below the initial viewport with the native attribute:

<img
  src="/images/article-640.webp"
  width="640"
  height="427"
  loading="lazy"
  decoding="async"
  alt="A chart in the article"
>

Do not lazy-load the main image a visitor sees immediately unless you have checked the resulting experience. Keep dimensions or an aspect ratio declared for every image so delayed loading does not move surrounding content.

Also remove images that are hidden, duplicated or never used at a given breakpoint. CSS can hide an element visually while the browser still downloads its source, depending on how the markup is built.

6. Automate transformations when the library grows

Manual exports work for a small number of stable assets. An image CDN or build pipeline becomes useful when you need many widths, automatic format negotiation, quality rules or transformations. MDN lists Cloudinary, Image Engine, ImageKit and imgix as examples of image CDN services; compare current features, integration effort, terms and cost before choosing one.

Automation should preserve the same decisions you would make manually:

Constrain maximum dimensions before encoding.
Generate only widths your layouts request.
Negotiate AVIF or WebP with a fallback where required.
Keep quality settings specific to content types.
Cache transformed results and set long-lived immutable URLs when filenames are content-hashed.

7. Complete implementation example

The following example combines responsive candidates, a modern-format fallback, reserved space and lazy loading for a below-the-fold article image.

<picture>
  <source
    type="image/avif"
    srcset="
      /media/diagram-320.avif 320w,
      /media/diagram-640.avif 640w,
      /media/diagram-960.avif 960w"
    sizes="(max-width: 700px) 100vw, 720px"
  >
  <source
    type="image/webp"
    srcset="
      /media/diagram-320.webp 320w,
      /media/diagram-640.webp 640w,
      /media/diagram-960.webp 960w"
    sizes="(max-width: 700px) 100vw, 720px"
  >
  <img
    src="/media/diagram-640.jpg"
    srcset="
      /media/diagram-320.jpg 320w,
      /media/diagram-640.jpg 640w,
      /media/diagram-960.jpg 960w"
    sizes="(max-width: 700px) 100vw, 720px"
    width="960"
    height="640"
    loading="lazy"
    decoding="async"
    alt="Diagram showing the image delivery pipeline"
  >
</picture>

8. Verify after deployment

Test at representative mobile and desktop viewport widths.
Confirm the selected request in the Network panel matches the rendered width and device-pixel ratio.
Disable AVIF or WebP support in a test browser to verify the fallback.
Check that the first visible image is not delayed unnecessarily.
Look for layout movement before and after image responses.
Re-run Lighthouse and compare transferred bytes, image delivery opportunities and the live visual result.

Audit savings are estimates. A smaller file is useful only if the selected source, crop, quality and loading behavior still fit the page.

9. Troubleshooting

Symptom	Likely cause	Fix
Mobile downloads the desktop image	Missing or inaccurate `srcset`/`sizes`.	Add width candidates and describe the rendered CSS width in `sizes`.
Image looks blurry	Candidate is smaller than the rendered width or the compression is too aggressive.	Generate a larger candidate for that layout and use a more conservative setting.
Text in a screenshot has halos	Lossy compression is unsuitable for sharp edges.	Use lossless WebP/AVIF or PNG, then compare the resulting bytes.
Layout jumps when images load	No intrinsic dimensions or aspect ratio.	Set `width`/`height` or CSS `aspect-ratio`.
Modern format fails in an older browser	No compatible fallback.	Provide a JPEG or PNG source in `<picture>`.
Lighthouse still reports image opportunities	The live page selects an oversized candidate, or an image is loaded too early.	Inspect the actual request, revise `sizes`, and lazy-load only below-the-fold content.
Compression saves little	The source is already optimized, dimensions dominate the bytes, or the chosen format is a poor match.	Resize first, then compare formats and settings on the actual content.

10. Performance, reliability and cost notes

Resizing reduces bytes at the source. Responsive selection reduces bytes per request. Compression reduces bytes within each candidate. Lazy loading reduces initial transfer. Treat these as separate controls and measure them separately.

Keep originals so you can regenerate candidates when layouts change. Use deterministic filenames or versioned URLs so caches do not serve stale dimensions. If you adopt a hosted image CDN, include transformation fees, storage, bandwidth and cache behavior in the cost comparison. Basic compression does not require a subscription.

Or skip the browser setup

If you need screenshots of pages for documentation, QA or image workflows, ScreenshotNeo returns a PNG, JPEG, WebP or PDF from one GET request. Its capture steps can accept consent banners and remove more than 60 known consent platforms, newsletter popups and chat widgets before the shot; each step can be disabled. Bot checks, blank pages, timeouts, failed loads and cache hits are not billed, and response headers identify the page verdict and billing status.

See the ScreenshotNeo API documentation for all options, including full-page and element capture, device presets, retina scale, custom CSS and JavaScript, waits, request blocking, headers, cookies, geolocation, caching, signed links, async jobs, bulk capture and PDF output.

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,
)
r.raise_for_status()
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 failed: ${res.status}`);
const bytes = Buffer.from(await res.arrayBuffer());
await Bun.write('shot.webp', bytes);

ScreenshotNeo also provides an MCP server so Claude, Cursor and other MCP clients can take screenshots with take_screenshot, inspect pages with get_page_info and create PDFs with capture_pdf. The Free plan includes 1,000 shots per month with no card; paid plans start at $5 for 3,000 shots. Create a free ScreenshotNeo account.

FAQ

Should I always convert JPEGs to AVIF?

No. Compare AVIF with WebP and a well-compressed JPEG for the actual image and browser audience. Keep a fallback when required.

Is reducing dimensions better than increasing compression?

They address different waste. Correct dimensions prevent unnecessary pixels; compression reduces bytes within the required dimensions. Apply both and inspect quality.

Does `loading="lazy"` compress an image?

No. It changes when a below-the-fold image is requested. Resize and encode the file separately.

How many responsive widths should I create?

Create a limited set based on real layout widths and observed requests. Too few candidates can waste bytes; too many add maintenance without useful savings.

Can an image CDN replace responsive HTML?

It can automate transformations and format selection, but the page still needs correct layout information and loading behavior. Validate the selected result in the browser.