How to Compress Large Images to Boost Google PageSpeed Insights

What the report is actually pointing at

PageSpeed flags images in several separate ways, and they mean different things. "Properly size images" means the file you sent is larger in pixels than the space it was displayed in. "Efficiently encode images" means the quality setting was higher than the picture needed. "Serve images in next-gen formats" means the same picture would be smaller as WebP or AVIF. The first is almost always the expensive one, and it is the one people skip, because on screen the page looks fine.

There is a timing side too. On most article and product pages the largest thing on screen is an image, so the browser cannot finish painting the main content until that file has arrived. Shrinking it moves the whole loading measurement, not just one row in the report.

Dimensions first, quality second

Start with pixel dimensions, because the saving there is geometric. A phone photo is commonly around 4000 pixels on its long edge. Bring that down to 1280 and you are keeping roughly a tenth of the pixels, since width and height both fall by the same factor. No quality slider gives you a reduction on that scale.

Pick the width from your layout rather than from the file. If the image sits in a 700 pixel column, 1280 covers high-density screens comfortably. Serving 4000 is paying to transfer detail nobody will ever see. The only images that deserve their full resolution are ones a visitor can click to open full screen, and even those rarely need the whole camera original.

What the quality slider is doing

JPEG works by discarding detail the eye is bad at noticing, and the quality number decides how aggressive that is. Push it low enough and the failures show up in predictable places: soft halos around hard edges such as text or a roofline, and blotchy patches in smooth gradients like a clear sky or a studio backdrop. Photographs with a lot of texture hide compression well. Flat colour and fine text do not.

Judge the result at the size it will be displayed, in the layout it will sit in. Zooming to 300 percent to hunt for artifacts will talk you into keeping a quality far higher than the page needs, and you will ship the bloat for nothing.

Where compression will not help

Some files have nothing left to give, and pushing them harder only costs you quality:

• A JPEG that has already been compressed once. Re-encoding stacks a fresh round of artifacts on top of the existing ones, and the saving is usually small. If a photo is already a couple of hundred kilobytes at web dimensions, leave it alone.
• Photographs saved as PNG. The compressor keeps a PNG as a PNG and shrinks it by reducing its colour palette, which suits screenshots and flat graphics but shows up as banding on a photo. Convert those to JPG or WebP first and compress that instead.
• Icons, logos and small interface graphics. A few kilobytes each is not what failed your audit. Find the hero image instead.

Using the compressor here

The quality slider runs from 10 to 95. For JPEG it sets the encoder's quality. Browsers ignore that value when they write PNG, so for PNG it sets how many colours survive instead, from 256 near the top of the range down to 16 at the bottom, with transparency kept. The maximum dimension control offers the original size, 1920, 1280 or 800 pixels on the longest edge, scaling proportionally so nothing gets stretched. Drop in a folder of images, compress the lot in one pass, and take them back as a ZIP.

A few things it deliberately does not do. It will not hit a file size target for you, so you pick a quality, look at the result and adjust. It does not keep metadata on the files it re-encodes: the image is decoded, drawn onto a canvas and written out fresh, so camera settings, timestamps and any GPS coordinates are gone. And it will not hand back a bigger file than you gave it. If re-encoding would make an already well-compressed image larger, and you have not asked for a smaller size, you get the original file back unchanged.

Why this runs in your browser

The images people compress before a launch are often ones they would rather not hand to a stranger: unreleased product shots, client photography, screenshots with internal data in them. Nothing here is uploaded. The file is read off your disk, decoded and re-encoded inside the tab, and written back to your downloads folder. Open the Network tab in developer tools while you compress and you will see no request carrying your file, because none is made.

When a build step is the better answer

If you publish images continuously, this work belongs in your pipeline, not in a browser tab. A build plugin or an image CDN can produce several widths and formats for every image, serve the right one per device, and never forget to do it. Doing that by hand each week does not scale, and it is the kind of job humans quietly stop doing after a month. A browser tool is the right size for the handful of files you are about to upload, or for the three heavy images an audit actually complained about.