June 24, 2026 · 7 min read

I Audited 15 Production Sites for Core Web Vitals. Images Were the #1 Problem.

Every quarter I run PageSpeed audits on a batch of live sites as part of a performance monitoring engagement. This quarter, I looked at 15 e-commerce and SaaS sites — medium traffic, real production, not demo pages. I tracked every Lighthouse opportunity flagged in the "Opportunities" section and grouped them by type.

Images accounted for 64% of all flagged opportunities. Not JavaScript bundles, not third-party scripts, not render-blocking CSS. Images. And within images, three specific mistakes showed up repeatedly.

The Three Image Mistakes That Keep Showing Up

Every site had at least one of these. Most had all three. The worst offender — a fashion retailer — had a 4.3MB PNG hero image loading above the fold on their homepage. That single image was 94% of their LCP time.

Mistake 1: Wrong Format — JPEG in 2026

Twelve out of fifteen sites were serving JPEGs to browsers that fully support WebP and AVIF. Not as a fallback — as the only format. That's leaving 25-35% file size reduction on the table for every image, free, with no quality loss.

One site had a product grid with 24 thumbnail images, all JPEG. Total transfer: 2.8MB. Converting those same images to WebP at quality 80 — visually identical on a product card — brought the total to 1.1MB. That's 1.7MB saved on a page that loads every time someone browses a category. Over a month with 50,000 category page views, that's 85GB of unnecessary transfer.

The fix is straightforward: serve WebP with a JPEG fallback using the <picture> element. Or better, use compress2png.com to batch-convert your entire product image library to WebP in one session — drag all your images, set quality, download a ZIP. All processing stays in your browser.

Mistake 2: CLS From Missing Image Dimensions

Cumulative Layout Shift is the most annoying Core Web Vital because it affects real users in a visible way — the page jumps while they're trying to tap something. Eleven of the fifteen sites had images without explicit width and height attributes, causing the browser to reserve zero space until the image loaded.

The fix is two CSS properties that work together: width and height attributes on the <img> tag, plus aspect-ratio in CSS as a safety net. Browsers since Chrome 90 use the width/height attributes to compute the aspect ratio before the image loads, reserving the correct space. Adding dimensions to all above-fold images eliminated CLS entirely for two sites in my audit.

Mistake 3: The 4MB Hero Image

Eight sites had hero or banner images over 500KB — and four had images over 2MB. The worst was the 4.3MB PNG on the fashion site. Their designers export at maximum quality from Figma and the images go straight to production. Nobody in between is running compression.

For a hero image, the sweet spot is 150-300KB for desktop and 80-150KB for mobile. At those sizes, the visual difference from the uncompressed version is invisible to a user scrolling at normal speed. Use Squoosh for single images to dial in the exact quality-vs-size tradeoff, or compress2png.com for batch processing entire folders.

The Audit That Pays for Itself

I ran the before-and-after PageSpeed scores for three of the sites that fixed all three mistakes:

The fashion site went from a failing LCP to passing — and the fix was entirely mechanical. No architecture changes, no CDN migration, no framework rewrite. Just format conversion, compression, and image dimensions. They did it in a single afternoon.

If you haven't audited your images in the last six months, run PageSpeed Insights on your homepage and your top three landing pages. The "Opportunities" section will tell you exactly which images are the problem. Then fix them in order of file size — largest first gives the biggest return.

Written by Maria Rodriguez — DevOps engineer who audits websites for a living. Data doesn't lie. More about me →