Fixing Oversized Image Files

What an oversized file finding means

This finding is about bytes: how many kilobytes or megabytes the browser downloads for an image. It is related to, but not the same as, the image's pixel dimensions or its format, which have their own findings and guides. A 1200 pixel wide JPEG can weigh 90 KB or 900 KB depending on how it was saved, and both look much the same on screen.

The weight matters for three reasons:

• Loading speed. The main image near the top of the page is often the Largest Contentful Paint element. A good LCP is 2.5 seconds or less at the 75th percentile, and a heavy hero image on a mobile connection can use most of that budget on its own.
• Data costs. Visitors on limited mobile plans pay for every megabyte. So do you, if your host or CDN charges for bandwidth.
• Competition for the connection. Several heavy images downloading together slow down each other and the fonts, scripts and styles the page also needs.

There is no single correct size for an image, and Google has no file-size rule. The right weight depends on how large the image is shown and what it contains. What the audit looks for is images clearly heavier than their job requires.

Where the wasted bytes hide

Usually two or three of these combine. A typical oversized product photo is a phone original with too many pixels, saved at high quality, carrying its EXIF block. Fixing all three together is where the big savings come from.

Finding the heaviest images

On a single page

Run the Image Optimisation audit on your busiest templates first. To check a page by hand, open developer tools, go to the Network panel, tick "Disable cache", reload and filter by images. Sort the Size column from largest to smallest. Chrome shows two figures when you hover: the transferred size, which is what came over the network, and the resource size, which is the file after decoding any transfer compression. For images these are usually close, because image formats are already compressed.

Lighthouse also reports images it thinks could be smaller. In recent versions this appears as an image delivery insight; older versions split it into separate audits for encoding, sizing and format.

Across the whole site

If you have server access, list the largest files in the uploads folder. This finds heavy images that are not on the pages you happened to test.

# The 50 largest JPEG, PNG and WebP files over 300 KB
find /var/www/example/uploads -type f \
  \( -iname '*.jpg' -o -iname '*.jpeg' -o -iname '*.png' -o -iname '*.webp' \) \
  -size +300k -printf '%s %p\n' | sort -rn | head -50

A crawler that records image sizes will give you the same list by URL, with the pages each image appears on, which helps you prioritise images used on popular pages.

Choosing a quality setting

Lossy formats trade file size against visual accuracy with a quality number. The relationship is not straight: going from the highest settings down to the upper middle of the range usually removes a lot of bytes with no difference most people can see, while going lower starts to show blocky areas, halos around edges and banding in smooth gradients such as skies.

Do not copy a quality number from another site or another tool. A given number means different things in different encoders and formats. Instead:

1. Pick five or six typical images: a product shot, a photo with sky, a portrait, one with fine texture such as fabric.
2. Open each in Squoosh or a similar tool and lower the quality while comparing side by side at the size it is shown on your site.
3. Note the lowest setting where you cannot see a difference without zooming in. Use the highest of those across your sample as your standard.
4. Apply that setting in your export presets, plugin or build script.

For JPEG, the mozjpeg encoder, available in Squoosh, sharp and as cjpeg, usually gives smaller files than the default encoder at similar quality. Progressive JPEGs, which load as a rough version that sharpens, are often slightly smaller for larger photos too.

Tools and commands that do the work

Desktop tools such as Squoosh in the browser and ImageOptim on macOS are fine for a handful of images. For hundreds or thousands, command-line tools are faster and repeatable. Test on copies first.

# Resize to fit within 2400 px, strip metadata, JPEG quality 80,
# 4:2:0 colour subsampling and progressive output (ImageMagick 7)
magick original.jpg -auto-orient -colorspace sRGB -resize "2400x2400>" \
  -strip -quality 80 -sampling-factor 4:2:0 -interlace JPEG web.jpg

# Recompress existing JPEGs in place: cap quality, strip metadata, progressive
jpegoptim --max=80 --strip-all --all-progressive *.jpg

# PNG: lossless optimisation
oxipng -o 4 --strip safe *.png

# PNG graphics: reduce to a palette, keep the original if the result is bigger
pngquant --quality=65-85 --skip-if-larger --ext .png --force *.png

# Remove all metadata from a JPEG, keeping the file otherwise unchanged
exiftool -all= -overwrite_original photo.jpg

The > after the size in the ImageMagick command means only shrink, never enlarge. Converting to sRGB before stripping matters: removing an embedded colour profile from an image saved in a different colour space can shift its colours in the browser.

In a Node.js pipeline

import sharp from 'sharp';

await sharp('uploads/original.jpg')
  .rotate()                                  // apply camera orientation
  .resize({ width: 2400, height: 2400, fit: 'inside', withoutEnlargement: true })
  .jpeg({ quality: 80, mozjpeg: true })      // metadata is dropped by default
  .toFile('public/img/web.jpg');

The fix, step by step

Cases that need a lighter touch

• Photography portfolios and zoom images. Where the picture is the product, visitors may expect fine detail. Keep a higher quality for the full-size view opened on demand, and compress the thumbnails and gallery views harder.
• Gradients, skies and dark scenes. These show banding first when compressed. Give them a slightly higher quality, or try WebP or AVIF, which often handle smooth areas better.
• Screenshots with small text. Lossy compression blurs text. Keep them lossless, or use lossless WebP.
• Privacy. Photos taken on phones may carry the exact location where they were taken. Stripping metadata protects staff and customers as well as saving bytes, which matters for photos of homes and private premises.
• Images from suppliers. Manufacturer photos are often supplied as very large files. Run them through the same pipeline as your own uploads instead of publishing them as delivered.
• Images in CSS. Background images in stylesheets do not show in the media library. Check the theme folder as well as uploads.

Keeping files light

• Optimise on upload, through the CMS, a plugin, an image CDN or a build step, so nobody has to remember.
• Set a maximum upload size in the CMS so extremely large originals are resized or refused.
• Give editors a simple rule: export at the largest size needed, not the camera size, and never upload screenshots of photos.
• Keep the budget visible in your release checks, and treat an image over budget like any other failed test.
• Review supplier and marketing assets before they go live, since they bypass the usual upload route.

For a wider view of how image weight fits into loading speed, see the Core Web Vitals Guide.