The Image Performance Audit: A Step-by-Step Workflow for 2026

Why a Workflow Beats a Checklist

You’ve seen the usual advice. Use WebP. Add lazy loading. Set width and height. Fine as a starting point, but it tells you nothing about where to start on your specific site or how much each fix actually matters.

An image performance audit flips the script. You measure first, find the biggest bottlenecks, fix them in order of impact, and verify the results. This article walks through that exact process, tool by tool.

Step 1: Establish Your Baseline

Before changing anything, measure where you stand. You need three data points.

Total Image Weight

Open Chrome DevTools, go to the Network panel, filter by “Img”, and reload the page with cache disabled (Ctrl+Shift+R). Look at the total transferred size at the bottom of the panel.

For context, the median webpage transfers about 1 MB of images (HTTP Archive, February 2026). If your page is well above that, images are your biggest performance lever.

Largest Contentful Paint (LCP)

Run a Lighthouse audit in Chrome DevTools (or at PageSpeed Insights). LCP measures how long it takes for the largest visible element to render. On most pages, that’s an image.

Google’s thresholds:

Good: 2.5 seconds or less
Needs Improvement: 2.5 to 4.0 seconds
Poor: over 4.0 seconds

Note which element Lighthouse identifies as the LCP element. If it’s an image, that’s your #1 optimization target.

Image-Specific Lighthouse Flags

Lighthouse surfaces specific image issues in the “Opportunities” and “Diagnostics” sections:

Lighthouse Flag	What It Means	Typical Impact
Properly size images	Images are larger (in pixels) than their rendered size	20 to 80% size reduction per image
Serve images in next-gen formats	JPEG/PNG images that could be WebP or AVIF	25 to 50% size reduction
Efficiently encode images	Quality is higher than needed for the rendered size	10 to 30% size reduction
Defer offscreen images	Below-fold images load eagerly	Faster initial page load
Image elements do not have explicit width and height	Missing dimensions cause layout shift	CLS improvement

Write down every flag. You’ll address them in priority order.

Step 2: Find Your LCP Image

The single highest-impact fix on most sites? Optimizing the LCP image. Here’s how to find it in Chrome DevTools:

Open the Performance panel
Record a page load
Look for the LCP marker in the timeline
Click it. DevTools shows which element triggered LCP

If it’s a hero image, product photo, or banner, focus here first. Three things go wrong most often:

Lazy loading the LCP image. Surprisingly common. If your hero image has loading="lazy", the browser won’t start downloading it until the layout is calculated. That adds hundreds of milliseconds for no reason. Fix it:

<img
  src="hero.jpg"
  alt="Hero"
  width="1200"
  height="600"
  fetchpriority="high"
/>

Use fetchpriority="high" and either omit loading (defaults to eager) or set loading="eager" explicitly. Never lazy-load the LCP element.

No preload hint. Even with eager loading, the browser only discovers the image when it parses the HTML. You can kick off the download earlier with a preload link in <head>:

<link
  rel="preload"
  as="image"
  href="hero.jpg?w=1200"
  imagesrcset="hero.jpg?w=800 800w, hero.jpg?w=1200 1200w, hero.jpg?w=1600 1600w"
  imagesizes="100vw"
/>

Oversized file. If the hero image is 3000px wide but renders at 1200px on the largest screen, you’re transferring 6x more pixels than needed (area scales quadratically). Use an image CDN to serve the right size:

https://demo.sirv.com/hero.jpg?w=1200

Step 3: Fix “Properly Size Images”

This is almost always the biggest win. For each image Lighthouse flags:

Note the rendered size (DevTools, hover over the image, see “Rendered size”)
Note the intrinsic size (the actual pixel dimensions of the file)
Calculate the waste: if an image renders at 400x300 but the file is 1600x1200, you’re sending 16x more pixels than needed

The manual fix: Generate resized variants at each breakpoint and use srcset:

<img
  src="product.jpg?w=800"
  srcset="product.jpg?w=400 400w, product.jpg?w=800 800w, product.jpg?w=1200 1200w"
  sizes="(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw"
  alt="Product"
  width="800"
  height="600"
/>

The CDN fix: With an image CDN like Sirv, you don’t maintain multiple files. Append ?w=400 or ?w=800 to the URL and the CDN generates and caches each size on the fly. Your srcset points to different URL parameters, not different files.

The fully automated fix: Sirv’s JavaScript handles this entirely. Add class="Sirv" and data-src to your images, include the Sirv script, and it automatically requests the right dimensions based on the image’s rendered size. No srcset or sizes needed:

<img class="Sirv" data-src="https://demo.sirv.com/product.jpg" alt="Product">

Step 4: Fix Format Issues

Lighthouse flagging “Serve images in next-gen formats”? Your images are being served as JPEG or PNG when WebP or AVIF would be much smaller.

How much does format matter? Here’s a real-world comparison for a typical 800x600 product photo at quality 80:

Format	File Size	vs. JPEG
JPEG	120 KB	baseline
WebP	78 KB	35% smaller
AVIF	58 KB	52% smaller

That’s per image. Multiply across a product listing page with 40 thumbnails and the savings are massive.

The <picture> approach:

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

This works but requires maintaining 3 files per image per size.

The CDN approach: An image CDN like Sirv checks the browser’s Accept header and automatically serves AVIF, WebP, or JPEG. No <picture> element needed. You reference one URL and the CDN handles format negotiation:

<img src="https://demo.sirv.com/product.jpg?w=800" alt="Product" />

A Chrome user gets AVIF. A Safari 14+ user gets WebP. An older browser gets JPEG. Same URL, different response.

Step 5: Add Lazy Loading (Correctly)

Lighthouse flags “Defer offscreen images” when below-fold images load immediately. The fix is native lazy loading:

<img src="product.jpg" loading="lazy" alt="Product" width="400" height="300" />

The rules are simple:

Do lazy-load images below the fold (product grids, secondary content, footer images)
Don’t lazy-load the LCP image or any above-fold content
Do include width and height so the browser reserves space before the image loads (prevents layout shift)

For pages with tons of images (product listings, galleries), lazy loading can cut initial page weight by 60 to 80% because only visible images load right away.

Step 6: Fix Layout Shift (CLS)

Lighthouse flagging missing dimensions? Add explicit width and height to every <img> tag. Modern browsers use these to calculate the aspect ratio and reserve space before the image loads:

<img src="photo.jpg" alt="Photo" width="800" height="600" />

In your CSS, make images responsive without breaking the aspect ratio:

img {
  max-width: 100%;
  height: auto;
}

The browser knows the image is 4:3 from the attributes, reserves the right amount of vertical space, and the image slots in without shifting anything around.

Step 7: Verify with WebPageTest

Lighthouse runs on your local machine with simulated throttling. For real-world validation, use WebPageTest:

Run a test from a mobile device on a 4G connection (e.g., “Moto G Power, Dulles, VA, 4G”)
Look at the waterfall chart and check that the LCP image starts downloading early and finishes before 2.5s
Check the filmstrip. You should see content appearing progressively, not a blank screen for 3 seconds
Compare “before” and “after” runs to quantify the impact of your changes

WebPageTest also shows the actual format and size of each image request, so you can verify that your CDN is serving WebP/AVIF correctly.

The Full Audit Checklist

Run through this after making changes:

Automating the Whole Thing

Got hundreds or thousands of images? Doing this manually for each one isn’t practical. An image CDN automates the entire pipeline:

Upload one master image in high resolution, original format
Request any variant via URL: ?w=400, ?w=800, ?q=85
Format conversion happens automatically. The CDN checks the browser’s Accept header
Responsive sizing is built in, either via standard srcset or Sirv’s automatic detection
Caching at the edge. After the first request, each variant is served from the nearest CDN node in about 25ms

For a catalog of 5,000 product images with 5 size variants and 3 formats, that’s 75,000 file variants you’d need to manage by hand. With a CDN, it’s 5,000 uploads and zero variant management.

That’s the real reason most high-traffic e-commerce sites use an image CDN. The individual optimizations aren’t hard. Doing them at scale without automation is.