Two Approaches to Image Optimization: Which Should You Choose?

Image optimization has two complementary approaches: compress and choose an efficient format to reduce the bytes in each image, and serve responsive variants so each browser can download dimensions suited to its display. They solve different parts of the transfer problem; for most responsive sites, combine them.

Start by choosing an encoding that preserves the image’s required quality and features. Then create a small set of useful widths and let the browser choose among them with srcset and sizes. Use <picture> when you need alternate formats or art-directed crops. These approaches follow the guidance in web.dev’s image performance guide and MDN’s guides to image formats and responsive images.

1. What the two approaches change

Approach	What changes	What it helps with	Tradeoff
Compression and format selection	How the pixels are encoded into a file	Fewer bytes for the selected image	Quality, transparency, animation, browser requirements, and encoder behavior vary
Responsive image delivery	Which dimensions are downloaded	Avoiding unnecessarily large files for small rendered slots	Requires generating variants and describing the layout accurately

They can be combined: encode each useful size efficiently, then make those sizes available to the browser. Neither technique guarantees a fixed page-speed improvement. The result depends on source imagery, encoding settings, dimensions, layout, and the candidate the browser selects.

2. Choose a format and compression level

Choose based on the content and required features, not a format name alone. Photographs, logos, transparent artwork, animation, and images that need lossless fidelity can call for different formats. WebP supports lossy and lossless compression and transparency. MDN reports lossy WebP averages 25–35% smaller than JPEG at visually similar compression levels, and lossless WebP is typically 26% smaller than the same images in PNG. These are averages, not guaranteed savings for an individual image or site; see MDN’s format guide.

Photographs: compare suitable lossy encodings at the actual display size. Keep increasing compression only while visible quality remains acceptable.
Logos and diagrams: decide whether sharp edges, transparency, or lossless detail matter more than file size. Compare the result at the sizes where the asset appears.
Transparency or animation: check that the chosen format and delivery path preserve the feature you need.
Compatibility: provide a fallback when your supported browsers or delivery environment require one. MDN discusses browser support and fallbacks in its format guide.

There is no universal quality setting. Inspect representative images after encoding, including fine textures, gradients, text within graphics, and transparency edges. Compare visual quality and byte size together. web.dev recommends trying compression levels to find an acceptable size and quality compromise.

3. Serve responsive image variants with HTML

For an image whose rendered size changes with the layout, provide width candidates in srcset and describe the expected rendered slot with sizes. The browser uses this information to select a suitable candidate. The following example assumes the site generates three versions of the same image at 480, 960, and 1600 pixels wide:

<img
  src="/images/product-960.webp"
  srcset="/images/product-480.webp 480w,
          /images/product-960.webp 960w,
          /images/product-1600.webp 1600w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1100px) 50vw,
         560px"
  width="1600"
  height="1067"
  alt="A ceramic table lamp on a desk">

The candidate widths must match the actual files. The sizes value should reflect your layout: this example says the image fills the viewport below 600 pixels, takes half the viewport up to 1100 pixels, and is 560 CSS pixels wide on larger screens. Adjust it when the real slot differs. MDN explains the browser-selection model and these attributes in Using responsive images in HTML.

Use picture for format alternatives or art direction

Use <picture> when you need the browser to select among format sources or when a narrow layout needs a different crop. Keep an <img> element as the fallback and accessible image:

<picture>
  <source
    type="image/webp"
    srcset="/images/landscape-800.webp 800w,
            /images/landscape-1600.webp 1600w"
    sizes="(max-width: 700px) 100vw, 700px">
  <img
    src="/images/landscape-800.jpg"
    srcset="/images/landscape-800.jpg 800w,
            /images/landscape-1600.jpg 1600w"
    sizes="(max-width: 700px) 100vw, 700px"
    width="1600"
    height="1067"
    alt="A mountain lake at sunrise">
</picture>

For art direction, use a media condition on a <source> to select a separately cropped asset at a breakpoint, then retain the fallback <img>. Do not use separate crops merely to shrink a file if the same composition works at all sizes. Refer to MDN’s picture element reference.

4. A practical implementation workflow

Inventory image roles. Separate photographs, icons, logos, illustrations, and images requiring transparency or animation. Identify which images materially vary in rendered size.
Pick representative source images. Include large photos, detailed images, gradients, and transparent edges. One image rarely represents every encoding result.
Choose candidate encodings. Generate appropriate formats and compression settings for each role. Keep a fallback where compatibility calls for it.
Inspect quality and bytes. Compare each output at the size readers will see. Reject settings that visibly damage important detail, even when the file is smaller.
Generate useful widths. Create a modest set of dimensions that covers the real layout slots. Avoid producing many nearly identical variants without a use case.
Write accurate markup. Use width descriptors in srcset, realistic sizes, and <picture> for format alternatives or alternate crops.
Check actual pages. Verify that file paths resolve, the image has the right crop and quality at relevant viewport widths, and the browser is offered candidates appropriate to the slot.

5. Edge cases and common mistakes

Incorrect sizes: if the declared slot is much wider than the rendered image, the browser may choose an unnecessarily large candidate. If it is too narrow, the selected source may look soft. Match the CSS layout.
Missing or inaccurate width descriptors: each 480w descriptor must describe the corresponding file’s intrinsic width. Correct mismatches when regenerating variants.
Only one source size: using srcset is useful only when there are genuinely different candidates available. Generate variants for the relevant range of slots.
Over-compressed images: small files can still be poor assets. Revisit the quality setting and compare at the intended display size.
Feature loss: a conversion can remove transparency, animation, or detail required by the original. Check those requirements before replacing source assets.
Fallback omitted: if the target environment needs a fallback, include a usable <img> source and verify the delivered formats.
Unneeded art direction: alternate crops add assets and markup. Use them when the composition needs to change, not as a substitute for responsive sizing.

6. Performance, reliability, and cost

Compression reduces the encoded bytes of each candidate; responsive delivery reduces the chance that a device downloads a candidate far larger than its slot. Combining them addresses both. Savings depend on the image content, chosen settings, dimensions, and browser choice, so evaluate a representative set rather than assuming a percentage from a format label.

Variant generation adds files to maintain and markup to keep accurate. Use a repeatable asset pipeline or managed image transformation service when the number of images and sizes makes manual maintenance burdensome; verify any service’s current capabilities and pricing before adopting it. Keep source assets so you can regenerate variants if quality requirements, formats, or layouts change. Correct dimensions and stable paths also make failures easier to diagnose.

For cost, compare storage and transformation work against the transfer bytes and maintenance effort saved. The research sources provide no universal cost or performance benchmark. Measure your own representative pages and hosting setup.

7. Troubleshooting

Symptom	Likely cause	Fix
Image appears soft on a wide or high-density display	The available candidate is too small, or `sizes` understates the slot	Provide a larger width candidate and correct the slot estimate.
Large image downloads in a narrow layout	`sizes` overstates the rendered width, or only large candidates are available	Match `sizes` to the CSS layout and generate smaller width candidates.
Browser reports a missing image	A variant path is wrong or the build did not emit that file	Check every URL in `srcset` and ensure the deployment includes the generated assets.
Unexpected crop or composition	A picture source selects an art-directed crop at the current media condition	Review the media conditions and use the intended crop at that breakpoint.
Transparency or animation disappeared	The conversion or fallback does not preserve a required feature	Choose a compatible encoding and verify both source and fallback behavior.
File size barely changes after conversion	The image is already efficiently encoded, dimensions dominate, or the content does not compress well with the selected settings	Compare other suitable settings and formats, and check whether a smaller responsive candidate is the larger opportunity.

8. Or skip the browser setup

When the task is capturing a page as an image or PDF, ScreenshotNeo provides a website screenshot API and MCP server. A single GET request returns a screenshot or PDF. See the ScreenshotNeo documentation.

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}`);

Cookie banners, 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 get 1,000 screenshots a month with no card.

9. FAQ

Should I optimize the original file or only the delivered variants?

Keep a suitable source asset, then generate and inspect the versions your site delivers. This makes it possible to regenerate outputs when quality, layout, or format needs change.

Do I need both srcset and picture?

No. Use srcset and sizes for resolution choices. Add <picture> when format alternatives or art direction are needed.

Which approach should I implement first?

Start with the largest images and the images shown at many different slot widths. Pick efficient encodings, then add responsive candidates where the layout makes oversized downloads likely. Combine both where it helps.

Will WebP always be smaller than JPEG?

No. MDN’s figures are averages for the stated comparisons. Results vary by image and encoding settings, so compare actual outputs.