Images That Are Killing Your Page Weight

Attributes do not resize anything

A 2816 × 2112 photo displayed at 640 pixels wide is still a 2816 × 2112 photo. The browser downloads the whole file, decodes it at full size in memory, then scales it down for display. You pay the bandwidth, the decode time and the memory, and you get a worse result than an image resized properly — browsers downscale acceptably, not beautifully.

Resize before upload. Every other step below assumes the pixel dimensions are already sensible.

Match the format to the picture

The old advice was JPEG for photographs, GIF for diagrams. Half of that still holds, and the GIF half has been comprehensively replaced.

• Photographs — AVIF where you can, WebP as the practical default, JPEG as the fallback. WebP typically lands 25-35 percent below a JPEG of comparable quality.
• Diagrams, charts, screenshots of text — SVG if you have the vector source, PNG if you do not. These are exactly the images that JPEG handles worst: sharp edges and flat colour are where its artefacts are most visible, and text goes fuzzy.
• Screenshots of interfaces — PNG or WebP. Not JPEG, for the same reason.
• GIF — only for the animations nobody has replaced with video yet. As a still-image format it is beaten on every axis.

Find the quality knee

Compression is not linear. On a typical photograph, going from quality 90 to 40 removes most of the file size and very little of what a reader notices; below about 30, artefacts appear around edges and in flat areas, and the savings get small. That knee is where you want to sit, and it moves per image — a portrait tolerates more compression than a landscape full of fine texture.

Automatic bulk compressors are a reasonable default and a poor final answer. They give you an excellent result on one photo and a visibly mushy one on the next, because they cannot see which detail matters.

Serve the size that is needed

One file for every screen wastes bandwidth on phones and looks soft on large displays. Let the browser choose:

<img src="/images/photo-800.jpg" srcset="/images/photo-400.jpg 400w,
             /images/photo-800.jpg 800w,
             /images/photo-1600.jpg 1600w"
     sizes="(max-width: 700px) 100vw, 700px"
     width="800" height="600"
     alt="Description of the picture"
     loading="lazy">

Two attributes there do more than they look. width and height let the browser reserve space before the image arrives, which prevents the page jumping as it loads — a layout shift that search engines measure and readers hate. And loading="lazy" defers everything below the fold.

One exception: never lazy-load the main image at the top of an article. It is the one image you want fetched immediately, and deferring it makes the page feel slower than doing nothing at all.

Alt text is not optional

Describe what the image shows, for readers who cannot see it and for the case where the file fails to load. If the image is purely decorative, use an empty alt="" — that tells a screen reader to skip it, which is different from leaving the attribute out entirely.

The rules that have not changed

• If the content can be text, make it text. A scanned price list as a JPEG is unreadable on a phone, unsearchable, uncopyable and heavier than the table it replaced.
• A bad photograph does not get better with processing. Cut it.
• Check the page weight after you publish, not before. What you uploaded and what the site serves are different things — a gallery extension or a template may be generating its own copies at sizes you did not choose.