1. Why Images Are Most Likely to Become a Performance Black Hole#

On a typical page, images are often the largest category of resources by size: HTML is a dozen or so KB, CSS is a few dozen KB, JS is a few hundred KB after bundling, while an unprocessed phone photo is easily 3–5 MB.

What’s worse, the size problem of images directly propagates to LCP (Largest Contentful Paint)—the LCP element on the vast majority of pages is an image. All the code splitting and CSS minification you painstakingly did can easily be wiped out by a single uncompressed PNG.

Image optimization looks simple—“just compress it”—but in reality it consists of three mutually independent problems:

All three must be solved separately. Doing only format conversion is like swapping a more fuel-efficient engine into a 4000px-wide giant image—you save fuel, but the car is still that big.

NOTE

There’s a fourth problem: stability. Images without reserved dimensions cause layout shifts—that’s a CLS problem, not an LCP problem, and it’s covered separately in section 6.

2. Format: How to Choose Between JPEG, WebP, and AVIF#

Let’s start with a comparison table. “Support” here refers to the version in which each browser began supporting it; specific version numbers can be verified at any time on caniuse or Web Platform Features Explorer:

Regarding encoding efficiency, the common industry conclusion is roughly: at equivalent subjective quality, WebP is typically 25%–35% smaller than JPEG, and AVIF is another 20%–30% smaller than WebP. The exact numbers depend on image content—images with many lines and gradient color blocks show more pronounced differences, while noisy photos show smaller differences. Don’t copy any percentage blindly; running a comparison with your own images is the only meaningful approach.

3. Size: The Selection Algorithm for srcset and sizes#

Format determines “how to encode”; next we need to solve “how big to send.”

The core contradiction is: the server, when sending the HTML, doesn’t know what size image the client needs. Screen width, DPR, and the actual width of this image in the layout are all known only to the browser itself. So the standard’s solution is not “the server guesses” but the server provides a set of candidates, and the browser picks. This is srcset + sizes.

1
<img
2
  src="/img/cover-960.jpg"
3
  srcset="/img/cover-480.jpg   480w,
4
          /img/cover-960.jpg   960w,
5
          /img/cover-1440.jpg 1440w"
6
  sizes="(min-width: 1024px) 720px, 100vw"
7
  width="1440" height="960"
8
  alt="Sample cover"
9
  loading="lazy"
10
  decoding="async"
11
>

In these few lines, the division of labor between the two attributes is completely different:

• srcset uses the w descriptor to declare the true pixel width of each candidate file—note it’s “how wide the file is,” not “how wide it will be displayed”;
• sizes declares how wide this image will occupy in the layout—it’s a set of media conditions + CSS lengths, describing the slot, independent of specific files.

The browser’s selection process is roughly three steps:

1. Parse sizes to get the slot width (CSS pixels) of this image under the current viewport;
2. Slot width × current devicePixelRatio to get the required physical pixel width;
3. In srcset, pick the first candidate not smaller than that width; if all are smaller, pick the largest one.

A concrete example: viewport 1440px, matches (min-width: 1024px) 720px, slot is 720px; device DPR = 2, so 1440 physical pixels are needed, and the browser selects cover-1440.jpg. If the same device has DPR = 1, only 720px is needed, and it selects cover-960.jpg.

1
<img src="thumb.jpg" srcset="thumb-240.jpg 240w, thumb-480.jpg 480w"
2
     sizes="auto, 100vw" loading="lazy" alt="Thumbnail">

4. <picture>: When “same image, different sizes” isn’t enough#

srcset can only do one thing: the same composition at different resolutions. But there are two types of needs it can’t express:

1. Art direction: on narrow screens you need to swap in an image with a different composition—for example, a 16:9 banner on wide screens, switched to a centered square crop on mobile. This isn’t scaling, it’s a different file;
2. Format fallback: provide AVIF / WebP / JPEG versions of the same image, and let the browser pick based on what it supports.

<picture> unifies these two things into “a set of candidate sources + one fallback <img>”:

1
<picture>
2
  <!-- 1. Narrow-screen art direction: square-cropped AVIF -->
3
  <source
4
    media="(max-width: 640px)"
5
    type="image/avif"
6
    srcset="/img/hero-square-480.avif 480w,
7
            /img/hero-square-960.avif 960w"
8
    sizes="100vw">
9

10
  <!-- 2. Wide-screen AVIF -->
11
  <source
12
    type="image/avif"
13
    srcset="/img/hero-wide-960.avif 960w,
14
            /img/hero-wide-1920.avif 1920w"
15
    sizes="100vw">
16

17
  <!-- 3. Wide-screen WebP fallback -->
18
  <source
19
    type="image/webp"
20
    srcset="/img/hero-wide-960.webp 960w,
21
            /img/hero-wide-1920.webp 1920w"
22
    sizes="100vw">
23

24
  <!-- 4. Fallback: required -->
25
  <img
26
    src="/img/hero-wide-1920.jpg"
27
    width="1920" height="1080"
28
    alt="Homepage hero"
29
    fetchpriority="high"
30
    decoding="async">
31
</picture>

The selection rule is simple: the browser scans from top to bottom, picks the first media that matches and whose type is supported <source>, then runs the srcset/sizes algorithm from section 3 again inside that <source>. If none match, it uses the final <img>.

A few easy pitfalls:

• <img> is required, not optional decoration. It carries two responsibilities at once: “final fallback” and “semantics and accessibility”—alt can only be written on it;
• width/height must also be written on <img>. Writing them on <source> has no effect, and the placeholder is wasted (see section 6);
• sizes is independent within each <source>. In the example above, the square crop and the wide banner have different layout widths, so their sizes values differ too;
• Don’t write media backwards. Narrow-screen conditions must come first, otherwise the wide-screen condition will swallow all viewports first.

WARNING

Do not add srcset to <img> inside <picture>. This makes “which attribute is actually in effect” hard to reason about; format fallback and size selection should both be expressed in <source>, leaving only one src in <img> as a fallback.

5. Timing: loading, fetchpriority, and preload#

Format and size solve “how much to download”; next we solve “when to download it.”

1
<img src="/img/hero-1920.jpg" fetchpriority="high" alt="Homepage hero">

1
<link rel="preload" as="image"
2
      type="image/avif"
3
      imagesrcset="/img/hero-960.avif 960w, /img/hero-1920.avif 1920w"
4
      imagesizes="100vw"
5
      fetchpriority="high">

6. Stability: Don’t let images push the page around#

An image has a height of 0 before it finishes loading, then suddenly expands once loaded—if there’s content above it, that content gets pushed down. This is the most common source of CLS (Cumulative Layout Shift).

The solution itself is extremely simple: let the browser know how much space the image will occupy before it finishes downloading.

1
<img src="/img/cover.jpg" width="1440" height="960" alt="Cover">

As long as you write both width and height, the browser can compute the aspect ratio and reserve the space before the image arrives. These two values don’t need to match the actual display size; they’re only used to derive the ratio.

There’s one easily missed companion CSS rule:

1
img {
2
  max-width: 100%;
3
  height: auto;  /* Key: otherwise the height attribute wins and the image gets squashed */
4
}

height: auto is required. Omit it, and the height="960" on the HTML will take effect rigidly, stretching and distorting the image inside a narrow container.

For images with unknown intrinsic dimensions (user uploads, remote URLs), declare the ratio explicitly with CSS:

1
.thumb {
2
  width: 100%;
3
  aspect-ratio: 4 / 3;
4
  object-fit: cover;      /* Crop proportionally, don't stretch */
5
  background: #f3f4f6;    /* Placeholder background color to avoid white-block flicker */
6
}

aspect-ratio combined with object-fit: cover lets you produce stable, proportional thumbnails without knowing the original image’s dimensions—this is standard for list pages and card feeds.

7. Implementation: Generating Multiple Sizes and Formats at Build Time#

Now that the rules above are covered, in a real project, nobody hand-writes these srcset. The right approach is to let the build pipeline automatically generate variants from the source image, with the template only responsible for output.

Write a minimal viable generator with sharp:

1
import sharp from 'sharp'
2
import { mkdir } from 'node:fs/promises'
3

4
const WIDTHS = [480, 960, 1440, 1920]
5

6
// The lower the effort, the faster the encoding and the slightly larger the size — tune this first when build time is a concern
7
const FORMATS = {
8
  avif: { quality: 50, effort: 4 },
9
  webp: { quality: 72 },
10
  jpeg: { quality: 80, mozjpeg: true },
11
}
12

13
export async function buildVariants(input, outDir, basename) {
14
  const { width: sourceWidth } = await sharp(input).metadata()
15
  await mkdir(outDir, { recursive: true })
16

17
  const variants = {}
18

19
  for (const width of WIDTHS) {
20
    // Don't upscale: skip if the original image is narrower than the target, otherwise it just adds size for nothing
21
    if (sourceWidth < width) continue
22

23
    for (const [ext, options] of Object.entries(FORMATS)) {
24
      const file = `${outDir}/${basename}-${width}.${ext}`
25
      await sharp(input)
26
        .resize({ width, withoutEnlargement: true })
27
        [ext](options)          // avif() / webp() / jpeg()
28
        .toFile(file)
29
      ;(variants[ext] ??= []).push({ width, file })
30
    }
31
  }
32

33
  return variants
34
}

A few implementation details worth noting:

• withoutEnlargement: true cannot be omitted. When the source image is only 600px wide, “upscaling” it to 1440px only produces a blurrier, larger file;
• The explicit skip of sourceWidth < width is a double safeguard alongside the previous point. The former’s benefit is generating fewer wasted files, while the latter ensures that even if resize is called, it won’t upscale;
• AVIF’s effort is the biggest variable in build time. The default value pursues maximum compression, which on large batches of images can make builds unbearably slow; lower it first to get things working, then raise it as needed;
• Output filenames include a content hash, and combined with Cache-Control: public, max-age=31536000, immutable, images can be cached long-term on CDNs and in browsers, never running into problems from “the image changed but the URL didn’t” — for details on this, see The Complete Guide to HTTP Caching Strategies: From Browser to CDN.

After generation, feed the results to the template. With astro:assets, this step is built in — the <Image> and <Picture> components handle multi-size generation at build time (multi-format is only supported by <Picture>, see the pitfalls below), outputting the correct srcset. This site’s images are handled exactly this way (see Browser Support and Cross-Device Compatibility Report for measured data: banner images provide eleven tiers from 360 to 2560, and card covers are generated based on actual display dimensions). The point of writing your own build script is: you know exactly where every byte comes from, and when something goes wrong, you know where to look.

1
const avif = await getImage({ src, format: "avif", quality: 50, widths, sizes })
2
const webp = await getImage({ src, format: "webp", quality: 72, widths, sizes })

1
<picture>
2
  <source srcset={avif.srcSet.attribute} type="image/avif" sizes={sizes} />
3
  <img src={webp.src} srcset={webp.srcSet.attribute} width={...} height={...} ... />
4
</picture>

8. Pre-Launch Image Checklist#

Item 9 is the most worth building as a habit. It turns all the previous reasoning about “theoretically such-and-such should be selected” into an observable verification: open DevTools, select <img>, and check the currently used candidate source in the tooltip next to the Elements panel; then switch the device emulator’s DPR and see whether the candidate changes accordingly. If DPR switches from 1 to 2 and the selected file doesn’t change, you can basically conclude that sizes was written incorrectly.

References#

• MDN: <img> element
• MDN: Image formats and browser support
• MDN: <picture> element
• MDN: fetchpriority attribute
• Web Platform Features Explorer: AVIF
• Web Platform Features Explorer: fetch-priority
• sharp: Output options and encoding parameters