Automated Image Audits: How to Find and Fix Every Performance-Killing Image on Your Site

Every performance review I've done on a production website has the same pattern: a few engineers who know images matter deeply, and a codebase with hundreds of images that nobody has looked at in months. The gap between intention and reality isn't laziness—it's the absence of a systematic process.

Manual audits don't scale. Clicking through a 500-page site, opening DevTools on every image-heavy page, and comparing file sizes by eye is a process that produces diminishing returns after the first hour and breaks down entirely when the site grows.

Automated image auditing does what manual review can't: it finds the problems you don't know you have.

---

What a Real Audit Actually Discovers

Before you build a process, it helps to know what you're looking for. In most production sites I've analyzed, the same categories of problems appear repeatedly.

Serving JPEG on pages that could serve AVIF. The savings here are typically 40–60% per image. On a landing page with a 400KB hero and 12 product thumbnails, you're looking at potentially 2–3 seconds shaved from LCP without changing a single line of layout code.

Background images in CSS that never got optimized. Your build pipeline knows about <img> tags. It doesn't know about background-image: url(...) declarations. Neither does Lighthouse, usually. Custom tooling is required to catch these.

Images served at desktop dimensions on mobile. A 2400px-wide banner being downloaded in full on a 390px iPhone screen. It happens constantly, especially on pages that were built "mobile-first" in layout but not in asset serving.

Third-party assets loaded from CDNs outside your control. Review product embeds, blog platform images, and social feeds. You won't be able to optimize them directly, but you can often replace the embed with a local asset or lazy-load the entire third-party component.

Uncompressed uploads in CMSes. Every time a marketing manager uploads a raw photo from a phone or DSLR, a 6MB file hits your production server. Without an automated transform layer, it gets served to users at full resolution and full size.

---

The Automation Stack

There's no single tool that catches everything. A complete audit system layers multiple approaches.

Layer 1: Lighthouse CI in Your Pipeline

Lighthouse's image audit flags oversized images, missing modern format support, and images without explicit dimensions (which cause CLS). Running it in CI on representative pages—homepage, product pages, key landing pages—catches regressions before they reach production.

# Install the CLI
npm install -g @lhci/cli

# Run against your staging environment
lhci autorun --collect.url=https://staging.yoursite.com

The key Lighthouse audits for images are uses-optimized-images, uses-webp-images, uses-responsive-images, and offscreen-images. Each report links directly to the offending asset.

Layer 2: URL-Based Scanning With TinyImage

Where Lighthouse analyzes a handful of representative pages, TinyImage's Website Optimizer crawls your actual domain, parses the HTML and CSS of every reachable page, and builds a complete inventory of your image assets—including ones not reachable from the homepage.

The output is an actionable report: for each image, you see its current size, its theoretical minimum size using AVIF or WebP, and the potential savings. This is where you find the long tail of underperforming images that automated CI coverage misses.

Layer 3: CMS-Level Upload Hooks

If your content management system supports webhooks or plugin hooks on file upload, this is where you enforce policy rather than track violations. Every image upload can trigger a check: does it exceed a maximum dimension? Is it in a non-web format like TIFF or BMP? If so, reject the upload or transform it before it lands in the media library.

WordPress users can configure this with Imagify or ShortPixel. Contentful, Sanity, and modern headless CMSes expose these hooks via their upload APIs.

---

Prioritizing What You Fix First

A complete audit of a mature site can surface hundreds of issues. Not all of them are worth the same effort.

Use this framework to prioritize:

1. Top 10 pages by traffic. Fix images on these first—the LCP improvement will register immediately in your Core Web Vitals report.

2. Hero and above-the-fold images. These are the direct inputs into LCP scores. A single 400KB unoptimized hero converting to a 90KB AVIF moves the needle more than 50 optimized footer icons.

3. Highest file-size images by absolute bytes. Sort your inventory by file size, not by percentage savings. Dropping a 2MB image to 200KB is better than dropping a 40KB image to 30KB.

4. Images on pages with high bounce rates. Cross-reference with your analytics. Slow pages have high bounce rates. Image optimization on those pages has a measurable revenue impact, not just a performance score impact.

---

From Audit to Action: The Frictionless Fix

The value of an audit is zero if the findings sit in a spreadsheet. The best automated pipelines move directly from "found" to "fixed."

With TinyImage's approach, the audit report and the optimizer are the same interface. You see an underperforming image, click to compress it locally in your browser—using AVIF or WebP encoding via WASM—and download the optimized version immediately. The original is never uploaded to any server. You replace the file in your repository and open a pull request.

This tight loop—find, compress, deploy—is what makes recurring audits sustainable. When the process takes 20 minutes instead of two days, teams actually follow through.

---

Setting Up Automated Monitoring

An audit is a point-in-time snapshot. Monitoring is what prevents backsliding.

Schedule a weekly Lighthouse CI run against your five most important pages. Set a performance budget—say, no image over 200KB on initial page load—and configure the CI build to fail if any page exceeds it. This isn't punitive; it's a forcing function that makes image optimization everyone's responsibility, not a periodic project.

For the long tail, run a full TinyImage domain scan monthly. Export the report, diff it against the previous month, and triage anything new that broke the threshold.

---

Image auditing done right is not a project with a completion date. It's maintenance, like dependency updates or security patches. Build the process once, and it runs itself.

Run your first audit now — it takes under two minutes for most sites, and you'll see exactly where you're losing speed.