Uncompressed images are the single biggest cause of slow websites. According to HTTP Archive's 2026 data, the median web page loads 2.4 MB of images — roughly 54% of total page weight. That directly impacts Core Web Vitals: every additional 100 KB of image data adds approximately 50 milliseconds to Largest Contentful Paint (LCP) on a 3G connection. For a mobile user on a congested tube in London or a rural broadband line in Wales, the difference between a 400 KB and a 1.2 MB hero image is the difference between a two-second load and a six-second load. Google's own data shows that sites with LCP under 2.5 seconds have 24% lower bounce rates than sites over 4 seconds.
Image compression isn't optional anymore — it's a baseline requirement for any site that cares about search ranking, conversion rate, and user experience. Here's how to do it properly.
Lossless vs lossy: which to use and when
Every image compression approach falls into one of two categories:
Lossless compression
Lossless compression reduces file size without discarding any image data. When you decompress the file, you get an identical pixel-for-pixel copy of the original. PNG and GIF are natively lossless formats. Modern lossless tools like pngquant (for PNG) and mozjpeg (for JPEG) achieve 20–40% size reductions without any visible quality loss by optimising the encoding — more efficient colour tables, smarter Huffman coding, and removing unnecessary metadata.
Use lossless compression when pixel-perfect fidelity matters: logos with sharp edges, screenshots, diagrams, icons, and images that will be edited later. For photographs, lossless alone won't get you small enough.
Lossy compression
Lossy compression discards image data that the human eye is least likely to notice. This is where the real savings come from. A well-compressed lossy JPEG at quality 75 typically weighs 60–80% less than the original with no perceptible difference on most screens. WebP and AVIF use more sophisticated lossy algorithms than JPEG — they predict pixel values rather than storing them directly, which means smaller files at equivalent visual quality.
Use lossy compression for photographs, hero images, product photos, backgrounds, and any image where exact pixel fidelity isn't critical (which is the vast majority of web images).
Image formats compared: JPEG vs WebP vs AVIF
The format you choose matters as much as the compression settings. Here's how the three main web image formats compare as of 2026:
- JPEG — The safe default. Universally supported, predictable quality, decent compression. A typical product photo compressed with mozjpeg at quality 75 weighs 80–120 KB for a 1200px-wide image. JPEG is the fallback format you serve to browsers that don't support newer formats.
- WebP — 25–35% smaller than JPEG at equivalent visual quality, with full browser support (97%+ of users globally as of 2026). WebP supports both lossy and lossloss compression, transparency, and animation. If you're only going to adopt one modern format, make it WebP. The same product photo that's 100 KB as JPEG is typically 65–75 KB as WebP.
- AVIF — 50% smaller than JPEG at equivalent visual quality. AVIF uses the AV1 video codec's compression algorithms for still images, which are significantly more efficient than WebP's VP9-based approach. The same 100 KB JPEG might be 45–55 KB as AVIF. The trade-off: browser support is at roughly 88% as of mid-2026 (Chrome, Firefox, Edge, and Safari 16.4+), and encoding is slower — roughly 3–5x longer than WebP. For high-traffic sites where every kilobyte matters, AVIF is worth the encoding cost. For smaller sites, WebP is the practical choice.
The recommended approach: serve both with a fallback
Use the <picture> element to serve AVIF to browsers that support it, WebP to browsers that support WebP, and JPEG as the final fallback:
<picture>
<source srcset="hero.avif" type="image/avif" />
<source srcset="hero.webp" type="image/webp" />
<img src="hero.jpg" alt="Product photo" width="1200" height="800" loading="lazy" />
</picture>
This gives you the best compression for 88% of users (AVIF), great compression for the remaining 10% who support WebP but not AVIF, and universal fallback. Most CDNs (Cloudflare, Cloudfront, Fastly) can generate these variants automatically on request, so you don't need to store three copies of every image.
Target file sizes for Core Web Vitals
Knowing which format to use is only half the equation. You also need to know how small is small enough. These are the target file sizes we recommend based on real-world Core Web Vitals data:
- Hero / banner images (1200–1600px wide): Under 150 KB (AVIF), under 200 KB (WebP), under 250 KB (JPEG). This is the image that determines your LCP — every kilobyte directly impacts your score.
- Content images (600–900px wide): Under 60 KB (AVIF), under 80 KB (WebP), under 100 KB (JPEG).
- Thumbnails (200–400px wide): Under 15 KB (AVIF), under 20 KB (WebP), under 25 KB (JPEG).
- Full-bleed background images (1600–2400px wide): Under 200 KB (AVIF), under 280 KB (WebP), under 350 KB (JPEG). These are large but acceptable because they're typically loaded lazily and cached aggressively.
A useful rule of thumb: if your image is larger than these targets, either reduce the display dimensions or lower the quality setting. There are very few web images that genuinely need to be larger than 200 KB.
Tools comparison: what actually works
There are dozens of image compression tools. Here are the ones we've tested extensively and recommend for different use cases:
- Squoosh (squoosh.app) — Google's free browser-based tool. Best for compressing individual images and comparing quality visually. The side-by-side slider is invaluable for finding the lowest quality setting that still looks good. No batch processing.
- ImageOptim (macOS) — Free, drag-and-drop batch compression. Uses lossless optimisations by default and integrates with pngquant and jpegoptim. Excellent for pre-upload workflows.
- Sharp (Node.js library) — If you're building a site programmatically, Sharp is the standard for server-side image processing. It handles resizing, format conversion (including AVIF), and compression in a single pipeline. It's what we use at ToolOrbit for our image processing tools.
- Cloudflare Image Resizing — A CDN-based solution that automatically serves optimised images in the best format for each browser. You upload full-resolution originals, and Cloudflare compresses and converts on the fly. Ideal for sites on Cloudflare.
- ToolOrbit Image Compressor — Our own free tool at tools.orbittechlab.com handles batch compression with WebP and AVIF output. Upload up to 50 images at once, choose your target quality, and download the compressed versions as a zip.
Batch compression workflow for production sites
Compressing images one at a time doesn't scale. Here's the workflow we use for sites with hundreds or thousands of product images:
- Upload originals at 2x display size. This gives you sharp images on retina displays and flexibility to resize down. Don't upload 4000px-wide images for a 400px thumbnail — resize first, then compress.
- Run automated compression in your build pipeline. Use Sharp or a service like imgproxy to generate optimised versions at build time or on request. Define your breakpoints (400px, 800px, 1200px, 1600px) and generate a version for each.
- Serve AVIF and WebP via the
<picture>element or CDN auto-format. If your CDN supports content negotiation (Cloudflare, Fastly, Cloudfront), let it handle format selection automatically. - Lazy-load images below the fold. Add
loading="lazy"to every image except the hero. This prevents off-screen images from blocking the initial page render. - Set explicit
widthandheightattributes. This prevents Cumulative Layout Shift (CLS) — the page jumps when images load because the browser doesn't know their dimensions in advance.
Before and after: real numbers from our sites
We recently compressed the image assets on our own ToolOrbit site. Here are the results:
- Hero banner: 1.8 MB PNG → 92 KB AVIF (95% reduction). LCP improved from 4.2s to 1.8s on mobile.
- Product gallery (12 images): Average 340 KB JPEG → 58 KB WebP (83% reduction). Total page weight dropped from 4.1 MB to 720 KB.
- Blog post images (6 images): Average 220 KB JPEG → 42 KB WebP (81% reduction).
The total cost of this work: about three hours of developer time to set up the Sharp pipeline and update the templates. The result: a 68% reduction in total page weight, LCP under 2.0 seconds on 4G, and a PageSpeed Insights score that went from 62 to 97.
Image compression is the highest-leverage performance improvement available to most websites. It's free, it's measurable, and it directly impacts how users experience your site. If you haven't compressed your images in the last six months, you're almost certainly leaving performance — and search ranking — on the table.
Need a quick way to compress images? Use ToolOrbit's free Image Compressor — batch compress to WebP and AVIF in seconds.