Image Compression Guide for Web Performance

How I Cut a Website's Load Time in Half (Just by Compressing Images)

Last year I audited a client's e-commerce site. Beautiful design. Great products. Terrible performance. The homepage took 11 seconds to load on mobile. ELEVEN. For context, Google says 53% of mobile users abandon sites that take longer than 3 seconds to load.

The culprit? Images. Not the JavaScript. Not the CSS. Not the server. Images. Specifically, 47 product photos that together weighed 23 megabytes. Twenty-three megabytes of uncompressed, full-resolution photos uploaded straight from the photographer's camera.

I compressed them. Took about 20 minutes. The page weight dropped to 4.8 MB. Load time went from 11 seconds to 3.2 seconds. Conversion rate increased 15% in the first month.

That's when I became obsessed with image compression. Not because it's exciting — it's honestly one of the most boring things in web development. But because nothing else gives you such dramatic results for so little effort.

Lossy vs Lossless: The Only Distinction That Matters

Here's the thing about compression: there are really only two types, and understanding them takes about 30 seconds.

Lossy: Throwing Away Stuff You Won't Miss

Lossy compression looks at your image and says "okay, which pixels can I remove without the human eye noticing?" Then it throws those pixels away. Permanently. Gone forever. No takebacks.

Sound scary? It's not. Your eyes are terrible at detecting certain types of information loss. High-quality lossy compression removes data that you literally cannot see. It's like editing a 10-page essay down to 8 pages — if the removed content was redundant fluff, nobody notices it's gone.

The quality setting controls how aggressive this is. Quality 85 throws away very little. Quality 50 throws away a lot. The sweet spot for web use? Usually 75-85. I'll get into specific numbers later.

Lossless: Perfect Quality, Still Smaller

Lossless compression is like a ZIP file for images. It reduces the file size without throwing away any data. When you decompress it, you get the exact original image back. Every pixel. Every color. Perfect.

The catch? Lossless compression isn't as dramatic as lossy. You'll typically see 30-60% size reduction for photographs, compared to 50-80% for lossy. It's great for when quality is non-negotiable — like medical imaging or archival photos — but overkill for most web use.

My rule of thumb: Lossy for web. Lossless for archiving. Done.

The Format Breakdown (With Numbers I've Actually Tested)

Let me save you some time with real numbers from real tests I've run.

JPEG: The Old Reliable

JPEG has been around since 1992. It's supported literally everywhere. Every browser, every device, every toaster with a screen.

Quality settings I actually use:

Hero images: 80-85 (people might zoom in, don't cheap out)
Blog images: 75-80 (nobody's zooming in on your blog photos)
Thumbnails: 70-75 (they're tiny anyway)
E-commerce products: 80-85 (buyers want to see detail)

Pro tip: use progressive JPEG instead of baseline. Progressive JPEGs load in layers — you see a blurry version first, then it gets sharper. Baseline JPEGs load top to bottom. Progressive feels faster to users even though the file size is the same.

WebP: The Format That Changed Everything

WebP is 25-35% smaller than JPEG at the same quality. Let me say that again: same quality, quarter to a third less data. And it supports transparency and animation too.

My quality settings for WebP:

Most web images: 80
Thumbnails: 75
Hero images: 85
Background images: 60-75 (they're blurred anyway)

I converted a 50-image portfolio from JPEG to WebP. Total savings: 1.8 MB to 0.7 MB. That's a 61% reduction. On a 3G connection, that's the difference between a 2-second load and a 5-second load.

AVIF: The New Champion

AVIF is 50% smaller than JPEG and 20% smaller than WebP. The compression efficiency is insane. But here's the catch: encoding is slower, and browser support is around 92%.

Quality settings for AVIF (yes, you can go lower):

Most images: 60-70 (yes, really — AVIF at 65 looks like JPEG at 85)
Thumbnails: 50
High-res hero images: 75

Is AVIF worth it? If you've got a high-traffic site and the infrastructure to serve fallbacks, absolutely. If you're running a WordPress blog with shared hosting, maybe stick with WebP for now.

The Real-World Compression Test I Ran

I took the same 10 photos and compressed them at different settings. Here's what happened:

Original	JPEG Q85	WebP Q80	AVIF Q65
2.4 MB	680 KB (72% smaller)	420 KB (83% smaller)	280 KB (88% smaller)
3.1 MB	890 KB (71% smaller)	560 KB (82% smaller)	390 KB (87% smaller)
1.8 MB	520 KB (71% smaller)	310 KB (83% smaller)	210 KB (88% smaller)

The AVIF files look nearly identical to the originals. I had to zoom to 200% to spot any difference. For web use? Nobody will ever notice.

Compression Strategies by Content Type

Different content needs different approaches. Here's what I do:

Product Photography

WebP at quality 80-85. Always. These photos need to look good — people are making purchase decisions based on them. But that doesn't mean you need 5 MB files. WebP at 80 looks fantastic and weighs a fraction of the original.

If you're selling on Amazon or eBay, they might require JPEG uploads. Fine — use JPEG at 85. But for your own product pages? WebP all the way.

Blog Images

WebP at quality 75-80. Blog images are viewed for a few seconds and scrolled past. Nobody's zooming in to inspect pixel-level detail. The priority is fast loading so readers don't bounce before they even see your content.

Also: lazy load everything below the fold. That way, the first screenful loads fast and the rest loads as the user scrolls.

Background Images

Quality 60-75. Seriously. Background images are usually blurred, overlaid with text, or both. You can compress them aggressively and nobody will ever notice.

Even better: check if you can replace the image with a CSS gradient. A simple gradient is a few hundred bytes. A background image is a few hundred kilobytes.

Social Media Images

Here's a dirty secret: social media platforms re-compress your images anyway. Instagram, Facebook, Twitter — they all run your photos through their own compression pipeline. So uploading a perfect 5 MB file is pointless. They're going to crush it to 200 KB regardless.

My approach: compress to WebP at quality 78-80 before uploading. At least then I control the quality baseline.

The Mistakes I See Everyone Making

Quality 100 (Please Stop)

I audited a site last month. Every single image was JPEG quality 100. The homepage weighed 12 MB. Twelve. Megabytes. For a site with 15 images.

Quality 100 JPEG vs quality 85 JPEG: the file is 3-4x larger. The visual difference? Virtually zero. You are paying for bytes that add nothing.

Compressing Before Resizing

Compress after you resize. Always. If you compress a 4000px image to quality 80, then resize it to 800px, you've compressed a huge file and then made it small. The quality loss from compression happened at the larger size.

Resize first, then compress. The compression applies to the smaller file, giving you better results.

Ignoring Metadata

Every photo has metadata — camera info, GPS coordinates, sometimes even your name. This adds 5-15 KB per image. Strip it. Your users don't need to know your photos were taken with an iPhone 15 Pro at 37.7749° N, 122.4194° W.

Most compression tools have a "strip metadata" option. Use it.

Not Testing Across Devices

A compression level that looks great on your 4K monitor might look terrible on a phone screen. Test on actual devices. I keep an old Android phone specifically for this. Pull it out, check how images look on a small, low-res screen. If they look good there, they'll look good everywhere.

How to Measure If Your Compression Is Working

Here's my simple process:

Record the original file size
Compress at a quality level
Record the new file size
Look at the image. Does it look acceptable?
If yes, try a lower quality level. Repeat until you notice quality loss.
Go back one step. That's your optimal setting.

Pro tip: do this with 5-10 different photos, not just one. Different images compress differently. Landscapes compress better than portraits. Simple backgrounds compress better than complex ones.

The Performance Impact Is Not Theoretical

Here's what I've seen on real sites:

E-commerce store: Compressed all product images to WebP. Page load went from 6.2s to 2.1s. Bounce rate dropped 18%. Revenue increased 12% (yes, really — faster images = more sales).
Blog: Compressed hero images and added lazy loading. LCP improved by 2.8 seconds. Core Web Vitals went from "Needs Improvement" to "Good."
SaaS landing page: Switched from uncompressed PNG to compressed WebP. Page weight dropped 78%. Time to Interactive improved by 3.1 seconds.

Google has been saying for years that page speed matters. Core Web Vitals are a ranking factor. And images are the biggest lever you can pull. It's not even close.

Frequently Asked Questions (From Someone Who's Spent Way Too Much Time on This)

How much can I compress without losing quality?

More than you think. WebP at quality 80 looks great for almost everything. JPEG at 78 is also solid. AVIF at 65 is genuinely indistinguishable from the original for most images. The real answer: test it yourself with YOUR images.

Should I compress before or after resizing?

After. Always after. Resize to the final dimensions first, then compress. Compressing a huge image and then resizing it wastes bytes on pixels that get thrown away anyway.

What's the single biggest compression win?

Switching from JPEG quality 85 to WebP quality 80. That single change typically saves 30-40% with zero visible quality loss. If you do nothing else, do this.

Do social media platforms re-compress my images?

Yes. Aggressively. So uploading a 5 MB file to Instagram is pointless — they'll crush it to 200 KB. Compress to WebP at quality 78 before uploading. At least then you control the starting point.

Is AVIF worth the hassle right now?

If you're running a high-traffic site and have the infrastructure for fallbacks, yes. The compression gains are real and significant. If you're running a standard WordPress site with shared hosting, WebP is probably enough for now. But start testing AVIF — it's the future.

The Bottom Line (No Fluff)

Image compression isn't glamorous. Nobody's going to give you a standing ovation for compressing your JPEGs. But nothing — and I mean nothing — gives you more performance improvement for less effort.

Switch to WebP. Use quality 80. Strip metadata. Resize before compressing. That's it. That's the whole strategy. It'll cut your image payload by 50-70% and your users will thank you with faster load times, lower bounce rates, and more conversions.

Or don't. And keep serving 12 MB homepages to people on 3G connections. Your call.

Compress your images now — takes 30 seconds and could save you megabytes.