🖼️
Images Performance SEO

Image Compression for the Web: Cutting File Size Without Visible Quality Loss

✍️ ZeeSharp Team ·September 26, 2026 ·⏱ 6 min read ·1,239 words

Images usually account for more page weight than everything else combined. Most of that weight is invisible and removable — here is how to find it reliably instead of guessing.

Images are usually the largest thing on a web page by a wide margin. On a typical content site they account for more transferred bytes than the HTML, CSS, JavaScript and fonts combined. Which means that if a page feels slow, images are the first place to look — and usually the easiest thing to fix.

The good news is that most images on the web are far larger than they need to be, and the excess is invisible. You can often remove sixty to eighty per cent of a file's weight without any viewer noticing a difference. This article is about how to find that margin reliably instead of guessing.

Where the wasted bytes actually are

There are four separate sources of bloat, and they compound. People usually fix one and wonder why the page is still heavy.

1. The image is larger than it will ever be displayed

This is the biggest single win and the most commonly missed. A photo straight from a phone is often 4000 pixels wide. If it is displayed in a 800 pixel column, roughly 96% of the pixels are being downloaded, decoded and then thrown away.

Resizing to the size you actually need is not compression in the technical sense — it is removing data that serves no purpose. Do this before anything else, with Crop & Resize. Every later step then operates on a much smaller image.

A practical rule: find the widest the image will ever be displayed in your layout, double it for high-density screens, and cap it there. For an 800 pixel column, export at 1600 pixels.

2. The format is wrong for the content

Formats are not interchangeable. Each was designed around a different kind of image, and using the wrong one costs you dearly:

The classic expensive mistake is saving a photograph as PNG. A 2 MB PNG photo will often become a 180 KB JPEG that looks identical. Use Convert Image to move between formats and compare.

3. The quality setting is higher than necessary

JPEG and WebP quality is a dial, usually 0–100, and the relationship between quality and file size is not linear. Going from 100 to 90 typically removes a large fraction of the file size while producing a difference almost nobody can see. Going from 90 to 80 removes noticeably less and starts to become visible on detailed images.

For most photographic content on the web, quality 80–85 is the sweet spot. Below about 70 you start seeing blocking in skies and smooth gradients, which is where JPEG artefacts are most obvious.

4. Invisible metadata is riding along

Photographs carry EXIF data: camera model, lens, exposure settings, edit history, thumbnails, colour profiles and — often — GPS coordinates. This can be tens of kilobytes per image and serves no purpose on a web page.

It is also a genuine privacy issue. Photographs published straight from a phone have repeatedly revealed home addresses through embedded GPS tags. Stripping metadata is both a performance win and a sensible default.

A workflow that works

Order matters, because each step makes the next one cheaper:

  1. Resize to the maximum display size you need, with Crop & Resize.
  2. Choose the right format for the content type, using Convert Image.
  3. Compress with Image Compressor, and check the result at full size rather than as a thumbnail.
  4. Compare against the original at 100% zoom. If you cannot tell them apart, compress harder. If you can, step back.

That last step is the one that separates people who get good results from people who either over-compress and ship mush, or under-compress and ship 3 MB hero images.

Where compression genuinely hurts

Lossy compression is not free, and there are cases where you should be conservative:

Why this matters beyond page weight

Image weight is not just an abstract number. It shows up directly in the metrics search engines use to assess page experience.

Largest Contentful Paint measures how long the biggest visible element takes to render. On most pages that element is an image — usually the hero. A 2 MB hero image is very often the single reason a page fails its LCP target, and compressing it is the entire fix.

Cumulative Layout Shift measures unexpected movement as the page loads. This one is not about size at all: it happens when images have no dimensions in the HTML, so the browser does not reserve space and the text jumps once the image arrives. Always set width and height attributes, even when CSS controls the actual display size.

There is also the plain fact that a large share of visitors are on mobile connections and metered data. A page that loads in two seconds on office broadband can take fifteen on a weak mobile signal — and most people will not wait.

Three details that punch above their weight

Lazy-load everything below the fold

Adding loading="lazy" to images that are not visible on first paint tells the browser to defer them until the user scrolls near. On a long article with twenty images this can cut initial load dramatically. Do not lazy-load your hero image — deferring the thing the visitor came to see makes LCP worse, not better.

Serve different sizes to different screens

Using srcset lets a phone download a 600 pixel version while a desktop gets 1600. Without it, everyone downloads the desktop image, and the phone — on the slowest connection — pays the highest price.

Get your favicon right once

Favicons are small but requested on essentially every page, and a missing one produces a 404 on every single load. Favicon Generator produces the full set of sizes modern browsers and mobile platforms expect.

A quick audit you can run today

Open your busiest page, open your browser's developer tools, go to the Network tab, filter by images and sort by size. You are looking for three things:

Most sites find two or three images responsible for the majority of their page weight. Fixing those takes about ten minutes and produces a bigger improvement than almost anything else you could spend that time on.

The compressor, resizer and format converter all run in your browser on ZeeSharp — your images are processed on your own machine rather than uploaded to a server, which matters when you are working with client work or anything unpublished.


Z
ZeeSharp Team
Published on September 26, 2026 · The ZeeSharp team builds free tools for productivity and creativity.
← Back to Blog