How to reduce image file size for faster websites
Images are the heaviest thing on most web pages. Here's how to compress them properly - without destroying quality - and why it matters for SEO.
On a typical web page, images account for 50-70% of the total page weight. If your site feels sluggish, your images are almost certainly part of the problem. And since Google officially factors page speed (specifically Core Web Vitals) into search rankings, slow images directly cost you traffic.
The good news: most websites can cut their image payload in half with five minutes of work per image and no visible quality loss.
Why image size matters more than most developers think
Modern broadband is fast, so why does a few hundred kilobytes still matter? Three reasons.
Mobile users. Globally, more than half of web traffic is on mobile, often on patchy 4G or even 3G. A 2 MB image that loads instantly on your office Wi-Fi can take 8+ seconds on a commuter train.
Core Web Vitals. Google measures and publishes how fast your page feels. Two of the three metrics — Largest Contentful Paint and Cumulative Layout Shift — are directly driven by image behaviour.
Bandwidth costs. If you serve a million visitors a month and each downloads 3 MB of images, that’s 3 TB/month of egress. On most hosts that’s not free.
Cutting image weight in half typically produces measurable business outcomes: faster page loads, better bounce rates, improved search rankings, and lower hosting bills.
The four levers for reducing image size
In order of impact:
- Dimensions (how many pixels)
- Format (JPG vs PNG vs WebP vs AVIF)
- Compression / quality setting
- Metadata and colour profiles
Lever 1: dimensions
This is the single biggest win people miss. A 4000×3000 photograph displayed at 800×600 on your website is carrying twenty-five times more pixels than the browser needs.
Check the final display size of each image. A product image shown in a 600×600 box? Resize the source to 1200×1200 (double for retina displays) before upload. A full-width hero on a 1440 px-wide layout? Resize to 1920 px wide. Don’t ship 4K images to display at 800 px — it’s pure waste.
Lever 2: format choice
Each format compresses different content best:
- Photographs → JPG or WebP (lossy). WebP typically beats JPG by 25-35%.
- Graphics with flat colours and sharp edges (logos, UI, diagrams) → PNG or WebP (lossless PNG is often smaller than JPG for this content)
- Photographs where every byte counts and your audience is on modern browsers → AVIF (another 30-50% smaller than WebP, but slower to encode)
You can’t just rename a file from .jpg to .webp — you have to re-encode it. Tools like the Image Compressor handle this automatically while keeping the original format (JPG→JPG, PNG→PNG, WebP→WebP). For format conversion specifically, use a dedicated converter.
Lever 3: compression / quality setting
Every lossy format has a quality dial. Most editors default to 80-85%, which is a reasonable middle ground but usually overkill for web images.
A practical rule of thumb for photographs:
- Quality 90-95: Barely distinguishable from original, but 40%+ larger than quality 75
- Quality 80-85: Excellent — visually indistinguishable to most viewers at normal viewing distance
- Quality 70-75: Very good — use this for web by default
- Quality 60-65: Noticeable softening in fine detail; acceptable for thumbnails
- Quality below 55: Visible artefacts, use only for heavily blurred backgrounds
For most websites, quality 75 is the sweet spot. The difference between 75 and 90 is invisible on the web but doubles the file size.
Lever 4: metadata and colour profiles
A typical camera JPG includes a fat EXIF metadata blob: GPS coordinates, camera make and model, capture settings, a thumbnail, sometimes even a full-size preview. Strip it and you save 30-300 KB per image with no visible difference.
Images sometimes embed unnecessarily large colour profiles too — a 500 KB ProPhoto RGB profile on a web image that should just use sRGB. Convert to sRGB and strip the embedded profile. Most image compression tools strip metadata automatically.
A practical workflow
For a new image arriving in your workflow:
- Check the dimensions. Resize to no more than 2× the largest display size.
- Pick the format. Photograph → JPG/WebP. Graphic → PNG/WebP.
- Set quality to 75 for photos, or use lossless for graphics.
- Compress. The Image Compressor runs in your browser with a quality slider so you can see the trade-off live.
- Verify. Eyeball the result at the intended display size. If it still looks good, ship it.
Total time per image: about 30 seconds. Typical saving: 40-70% vs the raw source.
Expected savings by content type
Rough numbers for typical sources:
| Source | Typical raw size | After web-optimised compression | Saving |
|---|---|---|---|
| iPhone photo (12 MP JPG) | 3-4 MB | 300-500 KB | ~85% |
| Mirrorless camera JPG (24 MP) | 8-12 MB | 500-800 KB | ~90% |
| Screenshot (PNG) | 500 KB-2 MB | 80-200 KB | ~80% |
| Logo (PNG with transparency) | 30-100 KB | 10-40 KB | ~60% |
| Icon set PNG | 20-80 KB | 5-20 KB | ~70% |
| Already-compressed web JPG | 300-500 KB | 120-200 KB | ~50% |
If you’re seeing less than 30% saving, the image was probably already optimised. If you’re seeing 80%+, the source was over-spec for web use.
What to check with developer tools
Open your site in Chrome and press F12 to open DevTools. Switch to the Network tab, filter by Img, and reload. You’ll see every image the page loads along with its size. Sort by size. Anything above 200 KB is a candidate for compression. Anything above 500 KB probably needs compression. Anything above 1 MB is almost certainly wrong.
Also run the Lighthouse audit. Under “Performance”, look for:
- “Properly size images” — flags images served larger than displayed
- “Efficiently encode images” — flags images that could compress better
- “Serve images in next-gen formats” — suggests WebP/AVIF where JPG/PNG is used
Each recommendation has a concrete KB saving attached. Knock them down in order of size.
Mistakes to avoid
Compressing the same image twice. JPG is lossy — compressing an already-compressed JPG at quality 75 again compounds the loss. If you compress, start from the original source.
Using PNG for photographs. A PNG photograph can be 5-10× larger than the equivalent JPG with no visible quality benefit. PNG is for graphics, not photos.
Forgetting about responsive images. Even after compression, serving a 1920 px image to a phone that displays it at 375 px is wasteful. Use the HTML <picture> element or srcset attribute to serve different sizes to different devices.
Optimising once and never again. Image compression gets better every year. AVIF didn’t exist a few years ago; it’s now widely supported. Re-run compression on your oldest images every 12-18 months.
Smaller images → faster pages → better rankings → happier users. It’s one of the simplest wins in web performance, and you can get most of the way there with a quality slider and 30 seconds per image. Drop images into the Image Compressor — it runs entirely in your browser, no uploads — and see how much you can save.