How to Analyze Images on a Web Page

Images are usually the largest thing a page downloads, and image problems are usually the cheapest performance wins available. They're also invisible on a fast connection and a good screen, which is why they survive so long.

An image audit answers five questions per image: how much does it weigh, is it bigger than the space it fills, is it in a sensible format, does it reserve its layout space, and does it have alt text that means something.

Get the inventory first

Before judging anything, list what's actually there. In the Network panel, filter by Img and sort by size. That gives you the transferred bytes per image and immediately shows the top offenders.

The Console version, which also catches the rendered-vs-intrinsic mismatch:

console.table([...document.images].map(img => ({
  src: (img.currentSrc || img.src).split('/').pop(),
  intrinsic: img.naturalWidth + '×' + img.naturalHeight,
  rendered: img.width + '×' + img.height,
  ratio: (img.naturalWidth / (img.width * devicePixelRatio)).toFixed(1) + '×',
  lazy: img.loading,
  alt: img.alt === '' ? '(empty)' : img.alt || 'MISSING',
})));

Web Developer Tools produces the same inventory without pasting anything. View Image Information reports every image with its size, type and alt in a searchable table; Display Image Dimensions overlays the rendered size onto each image on the page; Show Resource Sizes stamps transfer sizes onto images and scripts so you can see the weight where it sits.

1. Oversized images

This is the single most common image problem: a 2400×1600 photograph displayed in a 400×267 card. The browser downloads all of it, decodes all of it, and throws most of it away.

The rule of thumb: an image should be no more than about 2× its rendered CSS size, to cover retina displays. Beyond that you're paying for pixels nobody sees.

WDT has two tools aimed at exactly this: Outline Images With Oversized Dimensions outlines images loaded larger than they're displayed, and Outline Images With Adjusted Dimensions catches images rendered at a size different from their intrinsic one, which also causes soft, wrong-looking scaling. Largest Images ranks by file size when you want the top ten to fix first.

2. Formats

The single worst common case is an animated GIF. A five-second GIF is routinely 3–5MB where the same clip as an MP4 or WebM is under 300KB.

Serve modern formats with a fallback:

<picture>
  <source srcset="/hero.avif" type="image/avif">
  <source srcset="/hero.webp" type="image/webp">
  <img src="/hero.jpg" alt="…" width="1200" height="630">
</picture>

To see where you currently stand, the WebP / AVIF Usage Report breaks down how much of the page is already on modern formats, and Image Compression Report estimates the savings available from compressing what's there.

3. Layout stability

Every <img> needs width and height attributes. Not CSS dimensions — the HTML attributes. Modern browsers use them to compute an aspect ratio and reserve the space before the image arrives, which is the difference between a page that loads calmly and one that jumps.

<!-- Reserves space, no layout shift -->
<img src="/photo.jpg" alt="…" width="800" height="600">

/* Let CSS take over the sizing without losing the ratio */
img { max-width: 100%; height: auto; }

Missing Width/Height Attributes lists the offenders, and Outline Images Without Dimensions marks them on the page. This is the cheapest CLS fix available and it's usually a one-line template change. More on layout shift in the performance testing checklist.

4. Loading strategy

Three attributes, and getting them the wrong way round is worse than not using them:

• loading="lazy" on everything below the fold
• Never loading="lazy" on the LCP image — it delays the exact thing being measured
• fetchpriority="high" on the LCP image so it jumps the queue
• decoding="async" on non-critical images to keep decode off the critical path

The Lazy Loaded Resource Detector lists which images and iframes carry loading="lazy". That's how you catch a hero that was lazily loaded by a well-meaning blanket rule in the CMS.

5. Responsive sources

One image for all screen sizes means either mobile users download a desktop image or desktop users get a blurry one.

<img
  src="/card-800.jpg"
  srcset="/card-400.jpg 400w, /card-800.jpg 800w, /card-1600.jpg 1600w"
  sizes="(max-width: 600px) 100vw, 33vw"
  width="800" height="600"
  alt="…">

sizes is where this goes wrong. It tells the browser how wide the image will render *before* layout happens, so a lazy sizes="100vw" on an image that actually renders at a third of the viewport makes the browser pick a file three times too large. Get sizes right and srcset does its job.

Between them, View srcset Attributes, View <picture> Elements and Responsive Image Audit show what's declared against what's actually being selected, which is the comparison you need. There's more on the viewport side of this in the responsive testing guide.

6. Alt text

Alt text serves two audiences: people using screen readers, and search engines trying to understand the image. Both are badly served by alt="image".

• Informative images — describe what matters about the image in this context
• Decorative images — alt="", empty but present, so it's skipped rather than announced as a filename
• Images inside links — the alt text becomes the link's accessible name, so describe the destination
• Charts and diagrams — a short alt plus a longer description in the surrounding text
• Don't start with "image of" or "picture of", and don't stuff keywords

WDT's Display Alt Attributes shows every image's alt text inline on the page, which makes bad alt text obvious in a way that reading the HTML doesn't. Outline Images Without Alt and Highlight Missing ALT mark the ones with none, and Replace Images with Alt hides the images entirely and shows only their alt text, which is the closest quick approximation of the screen reader experience. This connects directly to the accessibility testing checklist.

The things a quick audit usually turns up

1. 1Duplicate images loaded from two different URLs, so both are downloaded and neither is cached usefully — WDT's Duplicate Images finds these
2. 2A logo shipped as a 200KB PNG that should be a 4KB SVG
3. 3Favicons that are missing, wrong-sized, or 404ing — Favicon Inspector covers the whole declared set
4. 4Inline SVGs with editor metadata making them ten times larger than necessary — SVG Inspector lists them
5. 5Background images in CSS that nothing checks and nobody has audited
6. 6An OG image that's the wrong aspect ratio, so social previews crop the logo in half

A repeatable pass

1. 1List every image with its transferred size and rendered size
2. 2Fix anything more than 2× its display size
3. 3Convert photographs to WebP or AVIF with a fallback
4. 4Replace any animated GIF with a video
5. 5Add width and height everywhere
6. 6Lazy-load below the fold, prioritise the LCP image
7. 7Check srcset and sizes on anything that changes size across breakpoints
8. 8Read every alt attribute out loud once

On a typical content site this pass cuts image weight by half or more, and it takes about an hour. There aren't many performance interventions with that ratio.

Image work pays into three places at once: performance, SEO and accessibility. If some images aren't loading at all, start with finding broken links and missing images.