That 12-megapixel photo straight off your phone is around 4 MB and 4,032 pixels wide. The blog column it's headed into is maybe 700 pixels wide. The browser downloads the whole 4 MB, scales it down on the fly, and throws away most of those pixels before your visitor sees anything. You paid the full download cost for an image five times larger than the page could ever display.
That gap is where almost all image bloat lives, and it's why "compressing images" is only half the job.
Images are the heaviest thing on most pages
On a typical article or landing page, images are 50-70% of the total bytes. Text, CSS, and even most JavaScript are tiny next to a few unoptimized photos. So when a page feels slow, images are the first place to look.
Speed isn't cosmetic. Google's own data has long shown bounce rate climbing sharply as load time grows — a page that takes 5 seconds instead of 1 loses a real chunk of visitors before it renders. Since 2021, Google also uses Core Web Vitals as a ranking input, and the big image on your page is usually your Largest Contentful Paint (LCP) — the element that decides when the page "looks loaded." A heavy hero image drags that number straight down.
The lever nobody pulls: resize the actual pixels
Most people open a compressor, drag the quality slider, and call it done. That helps. But the bigger win is dimensions.
Compression squeezes the file. Resizing removes pixels you were never going to display. Here's the same photo through both:
- Start: 4,032 x 3,024 px, ~3.8 MB JPEG
- Resize to 1,600 px wide (plenty for a full-width image): area drops to about 16% of the original → roughly 600 KB, before touching quality at all
- Then compress at quality 80: ~180 KB
That's 3.8 MB down to under 200 KB — about a 95% cut — and in a 700-1,200 px column it looks identical. The resize did most of the work; compression cleaned up the rest.
Rule of thumb: figure out the widest your image will ever display (check the column width, then roughly double it for high-DPI "retina" screens), and resize to that. Don't ship a 4,000 px image into an 800 px slot.
Lossy vs lossless, and where the damage hides
Lossless compression (what PNG does, or optimizing an existing PNG) shrinks the file without changing a single pixel — it just stores the same data more efficiently. Lossy compression (JPEG, WebP, AVIF) throws away detail your eye is unlikely to notice, and that's where the real savings come from.
The quality slider is where people either save a ton or wreck the image. For photos, quality 75-85 is usually indistinguishable from the original. Drop below ~60 and the tells show up: blocky squares in smooth areas, and a shimmer of "mosquito noise" around hard edges. Flat gradients — a clear sky, a solid-color background — break down first.
So 80 is a sane default for photos. Text and screenshots are different: their hard edges and thin lines show JPEG ringing badly even at high quality, which is why screenshots belong in PNG or a high-quality WebP, not a low-quality JPEG.
Pick the format that matches the image
- Photos → JPEG or WebP. WebP is typically 25-35% smaller than JPEG at the same visible quality and works in every current browser (Safari joined in 2020). AVIF is smaller still and now widely supported, at the cost of slower encoding.
- Logos, icons, line art, screenshots, anything with transparency or hard edges → PNG, or lossless WebP. Saving a screenshot as JPEG is a classic mistake — it bloats the file and blurs the text at the same time.
- Animation → not GIF. A short GIF can run several MB; the same clip as WebP or a muted looping video is a fraction of that.
If you have a big PNG photo, converting it to JPEG or WebP is often the single largest saving available — a photograph stored as PNG can be 5-10x bigger than it needs to be.
Compress once, keep the master
JPEG and WebP lossy compression is generational. Every time you re-save a lossy file, the encoder runs its "throw away detail" pass again — on top of detail that was already thrown away. Do it a few times and edges go muddy, gradients get blotchy, and there's no undo.
So: keep the original high-resolution file as your master, and always export web copies from that master. Never take an already-compressed 180 KB JPEG and run it through a compressor a second time to shave "a few more KB." If you need a different size later, go back to the original.
One more free win: strip metadata. A phone photo carries EXIF data — camera settings, timestamps, and often GPS coordinates — that can add tens of KB and quietly leak where the photo was taken. Most compressors drop it, which is both smaller and more private.
You can do the resize, format change, and compression right in the browser with everyboringtool's Image Compressor — the file never leaves your device, which matters when you're handling client photos, people's faces, or anything you'd rather not upload to a random server.
When this isn't the right approach
Compression isn't always the lever worth pulling:
- The image is already small. An 8 KB icon or a 30 KB optimized logo has nothing left to give. Squeezing it saves bytes that don't matter and risks visible damage. Spend the effort on the 2 MB hero instead.
- You need pixel-perfect masters. Print files, images you'll keep editing, or portfolios where fine detail is the whole point — don't run lossy compression on the working copy. Compress the web export, not the source.
- You're shipping hundreds of images. By hand, that doesn't scale. A build step (sharp, imagemin, or the Squoosh CLI) belongs in your pipeline and can generate responsive sizes automatically. A one-at-a-time tool is for the handful you're placing manually.
- The last few KB on a hero. For your LCP image, correct dimensions, a modern format, and a responsive
srcsetmatter far more than shaving another 5 KB off the file.
The honest version fits in one line: resize to the real display size first, convert photos to WebP or JPEG, compress once at quality ~80 from the original, and keep your master. Do that and a 4 MB photo becomes a 200 KB one that looks the same — drop it into a compressor, check it at 100% zoom, and if you can't see the difference, neither can your visitors.